I've only experienced OKRs at one company, and I felt a sort of a weird disconnect between OKRs and actual work/performance. On the one hand, OKRs were presumably critically important, but on the other, they weren't directly tied to individual performance. I still have trouble wrapping my head around that.
And I found those ratings (0, .4, .7, 1.0 for hitting a stretch goal) just a sort of weird self delusion, like setting your watch 15 minutes early to ensure you'll be on time. You can fool yourself a little, but eventually it stops working, and so, for example, .7 become the de facto "real" target.
Secondarily, I found that as a team lead, to the extent that OKRs were stressed, any non-OKR related work became highly disincentivized. Refactor? Write more integration tests? Hell no, not if it doesn't directly impact OKRs. We had stories in the backlog that really should have been done because they would have helped other teams and yielded a positive return, but anything non-OKR was just dropped on the floor.
Third, they didn't really provide any value to the team that I could discern. We didn't have to look at our objectives every day to know what to do. We had typical releases/epics, etc... to do, and on a day to day basis, the OKRs just receded into the background. In theory, I assume that the OKRs are there to guide which releases/epics/stories, etc... you do, but in our case, we had a pretty clearly defined product already prior to introduction of OKRs. So the OKRs were all just sorta "OK, finish this thing we're already working on."
That said, the company was new to them and in the process of learning. Perhaps we did them wrong, or perhaps I missed the point.
And I found those ratings (0, .4, .7, 1.0 for hitting a stretch goal) just a sort of weird self delusion, like setting your watch 15 minutes early to ensure you'll be on time. You can fool yourself a little, but eventually it stops working, and so, for example, .7 become the de facto "real" target.
Secondarily, I found that as a team lead, to the extent that OKRs were stressed, any non-OKR related work became highly disincentivized. Refactor? Write more integration tests? Hell no, not if it doesn't directly impact OKRs. We had stories in the backlog that really should have been done because they would have helped other teams and yielded a positive return, but anything non-OKR was just dropped on the floor.
Third, they didn't really provide any value to the team that I could discern. We didn't have to look at our objectives every day to know what to do. We had typical releases/epics, etc... to do, and on a day to day basis, the OKRs just receded into the background. In theory, I assume that the OKRs are there to guide which releases/epics/stories, etc... you do, but in our case, we had a pretty clearly defined product already prior to introduction of OKRs. So the OKRs were all just sorta "OK, finish this thing we're already working on."
That said, the company was new to them and in the process of learning. Perhaps we did them wrong, or perhaps I missed the point.