4 ms·

I my experience, measurable goals is a pipe dream. It promotes menial tasks like "take a 2 day course in React". "Clean my desk twice a week" "write 10 unit te

I my experience, measurable goals is a pipe dream. It promotes menial tasks like "take a 2 day course in React". "Clean my desk twice a week" "write 10 unit tests" over "spending 100% of my time creating value for customers"

Jensson 2y ago
A measurable goal can be "Deliver feature X" etc, how is that not value for customers? But yeah OKR are usually done at higher level than individuals, I didn't write any OKRs just the people above me. In general it is something managers should do, the lowest level employees shouldn't have to. I can agree that individuals being forced to write OKRs is a bad thing, but managers being forced to write OKRs is a good thing. At higher level OKRs looks like "attract X more customers" or "reduce customer churn by Y%" etc, to achieve those they instruct people like you to create customer value, at your individual level such goals aren't as easy to write since they are the result of contributions from many parts. Edit: But if you can come up with good measurable goals for you as an individual since you have enough individual freedom to do so, then yeah writing that down is good. But if you don't have any long term project and don't have control to plan what you work on then writing down an OKR is just hazing, you need to be responsible for the things your OKR measures, if you lack long term responsibilities then you shouldn't write down any OKRs.
- fifilura 2y ago
  What I mean that it gravitates toward menial tasks. They will have an edge. "Deliver product X" most of the time depends on so much more than my or the teams performance. Maybe it is not even a priority anymore?
  - Jensson 2y ago
    > "Deliver product X" most of the time depends on so much more than my or the teams performance. Maybe it is not even a priority anymore? Don't you have an OKR tree? If it isn't just your teams responsibility then just put it at a higher level in the org, and then the individual teams will have OKRs saying they should contribute to such efforts. If you have too rapid pace of individual features, then an OKR can be to reduce latency when other functions need help from you to increase collaboration among teams etc, if that is a bottleneck to delivering features. If a team you depend on often respond "we don't have time helping you, wait a week!", then that team should get an OKR to reduce that time since those delays are costing you a lot. Such delays are easily measurable so becomes excellent OKRs. Other good OKRs could be to reduce time to review code etc, to help speed up coding iterations and make job more fun, waiting for a response isn't fun. We typically got code reviews in much less than an hour, for smaller things often within minutes, that is much better than waiting a day on it. Edit: If your managers isn't doing these things then they are just incompetent, such an org will be dysfunctional regardless what you do, the OKR just makes that dysfunction more visible but they would work like shit regardless. OKRs really do help managers fix such organizations, as you can see from my examples above, those would really help you deliver features to customers in time.
    - fifilura 2y ago
      Those are all examples of menial tasks IMO. So the organization/company that delivers on those - Wins?
      - Jensson 2y ago
        Yes, ensuring all parts do their job effectively so that nobody gets bottlenecked is the core to organizational efficiency. And those bottlenecks and organizational dysfunctions are extremely frustrating when you try to do your job, so it is good for employee happiness as well.
        fifilura 2y ago
        I disagree. Delivering on the core functionality is the most important task.
        Jensson 2y ago
        Depends on the team. If your team has multiple roles then your OKR should match how much you should spend on each, ignoring an important aspect of your role in the OKRs doesn't help anyone. I worked at a core library team at a big company, we had both OKR to improve the library and OKR to help people with issues in a reasonable amount of time. Both are important. Anyway, in the end that isn't your decision to made, you were hired for a reason so a level or two above you should decide what is the most important here. So you disagreeing doesn't change that. It is common for teams such as yours to prioritize the wrongs things, OKRs helps show such dysfunctions and makes it easy to fix. If you really are causing problems by deprioritizing customer requests then a higher level manager would go in and tell you to put that back on.
- fifilura 2y ago
  One way to create a "measurable goal" is to focus on what you can control. In our case this meant improving the platform, far away from chaotic customers. Lo and behold, the result was down-prioritizing customer delivery.
  - Jensson 2y ago
    You don't have higher level management? Those are there to organize collaboration between your teams and them giving you OKRs and setting shared OKRs is an excellent way to do that, teams setting their own OKRs to be very greedy goals to suit the teams themselves just means the higher level managers aren't doing their job.
    - fifilura 2y ago
      Yeah, probably company politics. But this is also real. What happened here was 1) that the techy guys convinced higher management that this is essential for success. (Replacing a fully functional CI/CD tool with another CI/CD tool) 2) The OKR deadline suddely got very close so instead of investigating how to do this step by step, it was decided they do it all at once without any detailed investigation how it affects all services. And without planning. 3) The customer feature teams of course did all the heavy lifting since it was their services that were affected. 4) 1.5 years later customer feature teams are still not done replacing the 150k lines of legacy CI/CD code with code for the new tool. At what point do you hit the brakes?
      - Jensson 2y ago
        I agree in that case the dysfunctions stems from the other company, that is much harder to work with since you don't share the same organization so don't have a joint manager. In that case your manager has to decide, and seems they decided to ignore the customer in this case which is probably reasonable. Anyway, not sure why that was due to OKR. Maybe the decision was rushed due to OKR deadlines as you say, maybe it would have been rushed anyway, but at least OKR makes these problems more visible and makes it easier to work with them. OKR in general makes it much easier for managers to do their job, and you really want your managers to do their job properly.
azlev 2y ago
Well, I'm sorry for your experience. Now in a manager chair I have both experiences, setting bad OKRs and good OKRs. The performance and communication improvements when you get it right are astonishing. Unfortunately, I'm not consistent yet. But when you find a manager/ place where people get it right, you'll love it.

Jensson 2y ago

A measurable goal can be "Deliver feature X" etc, how is that not value for customers? But yeah OKR are usually done at higher level than individuals, I didn't write any OKRs just the people above me. In general it is something managers should do, the lowest level employees shouldn't have to. I can agree that individuals being forced to write OKRs is a bad thing, but managers being forced to write OKRs is a good thing. At higher level OKRs looks like "attract X more customers" or "reduce customer churn by Y%" etc, to achieve those they instruct people like you to create customer value, at your individual level such goals aren't as easy to write since they are the result of contributions from many parts. Edit: But if you can come up with good measurable goals for you as an individual since you have enough individual freedom to do so, then yeah writing that down is good. But if you don't have any long term project and don't have control to plan what you work on then writing down an OKR is just hazing, you need to be responsible for the things your OKR measures, if you lack long term responsibilities then you shouldn't write down any OKRs.

fifilura 2y ago
What I mean that it gravitates toward menial tasks. They will have an edge. "Deliver product X" most of the time depends on so much more than my or the teams performance. Maybe it is not even a priority anymore?
- Jensson 2y ago
  > "Deliver product X" most of the time depends on so much more than my or the teams performance. Maybe it is not even a priority anymore? Don't you have an OKR tree? If it isn't just your teams responsibility then just put it at a higher level in the org, and then the individual teams will have OKRs saying they should contribute to such efforts. If you have too rapid pace of individual features, then an OKR can be to reduce latency when other functions need help from you to increase collaboration among teams etc, if that is a bottleneck to delivering features. If a team you depend on often respond "we don't have time helping you, wait a week!", then that team should get an OKR to reduce that time since those delays are costing you a lot. Such delays are easily measurable so becomes excellent OKRs. Other good OKRs could be to reduce time to review code etc, to help speed up coding iterations and make job more fun, waiting for a response isn't fun. We typically got code reviews in much less than an hour, for smaller things often within minutes, that is much better than waiting a day on it. Edit: If your managers isn't doing these things then they are just incompetent, such an org will be dysfunctional regardless what you do, the OKR just makes that dysfunction more visible but they would work like shit regardless. OKRs really do help managers fix such organizations, as you can see from my examples above, those would really help you deliver features to customers in time.
  - fifilura 2y ago
    Those are all examples of menial tasks IMO. So the organization/company that delivers on those - Wins?
    - Jensson 2y ago
      Yes, ensuring all parts do their job effectively so that nobody gets bottlenecked is the core to organizational efficiency. And those bottlenecks and organizational dysfunctions are extremely frustrating when you try to do your job, so it is good for employee happiness as well.
      - fifilura 2y ago
        I disagree. Delivering on the core functionality is the most important task.
        Jensson 2y ago
        Depends on the team. If your team has multiple roles then your OKR should match how much you should spend on each, ignoring an important aspect of your role in the OKRs doesn't help anyone. I worked at a core library team at a big company, we had both OKR to improve the library and OKR to help people with issues in a reasonable amount of time. Both are important. Anyway, in the end that isn't your decision to made, you were hired for a reason so a level or two above you should decide what is the most important here. So you disagreeing doesn't change that. It is common for teams such as yours to prioritize the wrongs things, OKRs helps show such dysfunctions and makes it easy to fix. If you really are causing problems by deprioritizing customer requests then a higher level manager would go in and tell you to put that back on.
fifilura 2y ago
One way to create a "measurable goal" is to focus on what you can control. In our case this meant improving the platform, far away from chaotic customers. Lo and behold, the result was down-prioritizing customer delivery.
- Jensson 2y ago
  You don't have higher level management? Those are there to organize collaboration between your teams and them giving you OKRs and setting shared OKRs is an excellent way to do that, teams setting their own OKRs to be very greedy goals to suit the teams themselves just means the higher level managers aren't doing their job.
  - fifilura 2y ago
    Yeah, probably company politics. But this is also real. What happened here was 1) that the techy guys convinced higher management that this is essential for success. (Replacing a fully functional CI/CD tool with another CI/CD tool) 2) The OKR deadline suddely got very close so instead of investigating how to do this step by step, it was decided they do it all at once without any detailed investigation how it affects all services. And without planning. 3) The customer feature teams of course did all the heavy lifting since it was their services that were affected. 4) 1.5 years later customer feature teams are still not done replacing the 150k lines of legacy CI/CD code with code for the new tool. At what point do you hit the brakes?
    - Jensson 2y ago
      I agree in that case the dysfunctions stems from the other company, that is much harder to work with since you don't share the same organization so don't have a joint manager. In that case your manager has to decide, and seems they decided to ignore the customer in this case which is probably reasonable. Anyway, not sure why that was due to OKR. Maybe the decision was rushed due to OKR deadlines as you say, maybe it would have been rushed anyway, but at least OKR makes these problems more visible and makes it easier to work with them. OKR in general makes it much easier for managers to do their job, and you really want your managers to do their job properly.

azlev 2y ago

Well, I'm sorry for your experience. Now in a manager chair I have both experiences, setting bad OKRs and good OKRs. The performance and communication improvements when you get it right are astonishing. Unfortunately, I'm not consistent yet. But when you find a manager/ place where people get it right, you'll love it.