4 ms·

This seems oddly badly argued. Take the criticism of 70%, the author essentially poses the question "What do you mean by 70%" and goes on to illustrate an examp

This seems oddly badly argued. Take the criticism of 70%, the author essentially poses the question "What do you mean by 70%" and goes on to illustrate an example of where it is extremely obvious what it means. It's almost a malicious compliance attitude towards OKRs. Ok so the objective was to migrate, we got to 70%, well I guess then we're just going to stop doing any more work on it and cause an obviously preventable bad situation. Of course the goal is 100% migration, and if you get to 70% migration you've done well but not hit your stretch goal, of course you're then going to still spend time doing it. The real question is what is the alternative to OKRs? Is the author literally just advocating for not setting objectives? How do you propose to align what the engineers are doing with what the company needs? Are we suggesting we don't create metrics to measure our progress towards those objectives? Yes, there is some overhead in creating ways to measure the results, but the alternative - not measuring the results - is terrible!

scott_w 3y ago
> It's almost a malicious compliance attitude towards OKRs. Ok so the objective was to migrate, we got to 70%, well I guess then we're just going to stop doing any more work on it and cause an obviously preventable bad situation. This is a misunderstanding of 70%. The idea is 100% should be a very high standard e.g. increase revenue by $3bn this year, such that even if you hit 70% you'd be happy. I don't think it's specifically about stopping people slacking off and more about pushing people to think differently about the problems they need to tackle. For some things, this is really helpful (such as increasing revenue, customers, etc.) In these cases, if you reach the end of the quarter and stop doing the things that were aiming for that stretch goal, everyone should still be pretty happy with what they achieved. It falls over when you want to do something concrete (like migrating users). It's not a stretch goal at all, it's just the requirements! The 70% target simply doesn't apply in the slightest to this type of work. It's not an argument against setting objectives, just pointing out that OKRs—as taught—doesn't work for this type of work.
- magicalhippo 3y ago
  So the 70% is to 100% as ten is to eleven[1]. [1]: https://www.youtube.com/watch?v=uMSV4OteqBE https://www.youtube.com/watch?v=uMSV4OteqBE
PeterisP 3y ago
Especially since for the migration example you can trivially set the ambitious goal by measuring not the % of users migrated (since you need all of them) but measuring the time or cost of doing so; e.g. set an OKR to finish it in X days or under Y person-hours or Z dollars of cost, and pick the values of X/Y/Z so that they're not "safe" but rather the values where you expect a 70% likelihood of meeting that goal.

scott_w 3y ago

> It's almost a malicious compliance attitude towards OKRs. Ok so the objective was to migrate, we got to 70%, well I guess then we're just going to stop doing any more work on it and cause an obviously preventable bad situation. This is a misunderstanding of 70%. The idea is 100% should be a very high standard e.g. increase revenue by $3bn this year, such that even if you hit 70% you'd be happy. I don't think it's specifically about stopping people slacking off and more about pushing people to think differently about the problems they need to tackle. For some things, this is really helpful (such as increasing revenue, customers, etc.) In these cases, if you reach the end of the quarter and stop doing the things that were aiming for that stretch goal, everyone should still be pretty happy with what they achieved. It falls over when you want to do something concrete (like migrating users). It's not a stretch goal at all, it's just the requirements! The 70% target simply doesn't apply in the slightest to this type of work. It's not an argument against setting objectives, just pointing out that OKRs—as taught—doesn't work for this type of work.

magicalhippo 3y ago
So the 70% is to 100% as ten is to eleven[1]. [1]: https://www.youtube.com/watch?v=uMSV4OteqBE https://www.youtube.com/watch?v=uMSV4OteqBE

PeterisP 3y ago

Especially since for the migration example you can trivially set the ambitious goal by measuring not the % of users migrated (since you need all of them) but measuring the time or cost of doing so; e.g. set an OKR to finish it in X days or under Y person-hours or Z dollars of cost, and pick the values of X/Y/Z so that they're not "safe" but rather the values where you expect a 70% likelihood of meeting that goal.