If setting an OKR is meant to focus the team and maximize effort towards solving those problems, this approach is counterproductive because it completely fails to measure the effort exerted towards a goal.
You could have a 1.0 OKR and you could have 2 cases. 1. Set it too easy, didn’t have to do much to achieve it 2. Set a hard goal and produce a Herculean effort to achieve it
The latter case isn’t accounted for. It’s is glaringly obvious but the dull manager types don’t seem to want to acknowledge the difference or the fact that the latter behavior, if incentivized, leads to better and more predictable outcomes.
Instead, the effort is met with a blanket: “Too easy, didn’t set a hard enough goal”.
This incentivizes people to set easier goals that they can meet comfortably and slack of 20% of the time so that it doesn’t look like the goal they set was too easy.
If every OKR got 1.0 it meant we could comfortably take on more work next half, below 0.8 and we would plan to do a little less next half.
In theory it would have been fine to score OKRs above 1.0 for stretch goals for the same effect, but the software didn't work that way.
I know the argument is that by being more ambitious and achieving 70%, you are setting ambitious goals. But then the goals are never met. The work doesn't finish. The projects falter. The users are unhappy. Engineers leave.
Hmm. If you are supposed to not meet all your OKRs, then that guarantees you will have a record of unmeet OKRs, which can be used as ammunition to deny promotion or even fire someone.
So that encourages a sort of favoritism, where the people you want to promote anyway have their missed OKRs overlooked, while the rest of the pack aren't meeting their OKRs.
Their whole management process encourages people to chase after impossible goals, and literally discourages people from getting things done.