If all of this is true, why do companies have so many challenges with OKRs? Why do they treat them as yet another zombie process that no one particularly believes in or thinks about, yet continue "checking the box" quarter after quarter?
Thank John for those great insights. I really appreciate the deep dive under the surface of processes toward the hidden domain of actual behavior.
One question I would ask: is that really a problem for teams to do stuff that, on the surface, doesn't look like directly contributing to the OKR? I don't find that a contradiction. Even the best Swiss clock is broken if all the gears are turning in the same direction.
My company is now 8y old and have seen a growth in stages. At some point, I got 3 different groups with different needs and maturity:
- the newest group was still trying to figure out their purpose, or more exactly how to execute to achieve it.
- the second group has found it, and was trying to improve and organize themselves for faster growth.
- the oldest group has achieved a plateau and was trying to figure out how to get to the next stage.
Those three groups were born under the same vision, but their needs and so the tools they need were different. Trying to impose them a single one, or worse, expecting all of them to execute the same way was a terrible idea, but one I had to fight against strongly while they were collaborating.
I think a better acceptance of the different needs and processes of each group is necessary for any project big enough to have to be split between different teams. What we need to figure out is a common interface allowing those groups to collaborate while respecting their own ways to execute for it. Simplicity is key here, but also some distanciation toward the actual implementation. Something very similar to the encapsulation principle in software design.
One additional challenge across this are cross-domain processes. The main example that comes to mind is performance evaluation. I'm not sure how, given the difference of domains and maturity of each teams/projects, one can consider a single detailed framework to fit everyone, even in the name of fairness. Yet, no one will consider to evaluate the HR representative upon the same criteria as an engineer, but why this could not apply for two engineers working on wildly different projects, on different teams? The fairness, anyway, will always be subjective, and only us, as empathetic beings, can create it, not some blind calculating process.
Briefly, I really think that any attempt to have one deep and detail system apply to everyone across the board is doomed to fail under its own rigidity. Complex systems need to stay flexible and dynamic and customized to the challenges at their location. That would make them even more complex, and for sure, we need to figure out good abstraction to understand them and provide for their needs, but this is our actual challenge as leadership.
I love this point. This is why I picked the OKR example. In *theory*, it could provide a lightweight "api" between teams and other teams. The format is standard. The contents are not. But once you mix in other things.... one the institutionalization happens, etc. ... you start to run into trouble. I have more to say on your comment, and not enough time, but writing to thank you.
Great post, John! Love how you explain the "zombie processes" problem with OKRs. It’s crazy how what should bring focus just becomes a checkbox in big companies. The disconnect between goals and reality is real. You’ve got me thinking 🤔. Thanks for sharing! 👏
Thank John for those great insights. I really appreciate the deep dive under the surface of processes toward the hidden domain of actual behavior.
One question I would ask: is that really a problem for teams to do stuff that, on the surface, doesn't look like directly contributing to the OKR? I don't find that a contradiction. Even the best Swiss clock is broken if all the gears are turning in the same direction.
My company is now 8y old and have seen a growth in stages. At some point, I got 3 different groups with different needs and maturity:
- the newest group was still trying to figure out their purpose, or more exactly how to execute to achieve it.
- the second group has found it, and was trying to improve and organize themselves for faster growth.
- the oldest group has achieved a plateau and was trying to figure out how to get to the next stage.
Those three groups were born under the same vision, but their needs and so the tools they need were different. Trying to impose them a single one, or worse, expecting all of them to execute the same way was a terrible idea, but one I had to fight against strongly while they were collaborating.
I think a better acceptance of the different needs and processes of each group is necessary for any project big enough to have to be split between different teams. What we need to figure out is a common interface allowing those groups to collaborate while respecting their own ways to execute for it. Simplicity is key here, but also some distanciation toward the actual implementation. Something very similar to the encapsulation principle in software design.
One additional challenge across this are cross-domain processes. The main example that comes to mind is performance evaluation. I'm not sure how, given the difference of domains and maturity of each teams/projects, one can consider a single detailed framework to fit everyone, even in the name of fairness. Yet, no one will consider to evaluate the HR representative upon the same criteria as an engineer, but why this could not apply for two engineers working on wildly different projects, on different teams? The fairness, anyway, will always be subjective, and only us, as empathetic beings, can create it, not some blind calculating process.
Briefly, I really think that any attempt to have one deep and detail system apply to everyone across the board is doomed to fail under its own rigidity. Complex systems need to stay flexible and dynamic and customized to the challenges at their location. That would make them even more complex, and for sure, we need to figure out good abstraction to understand them and provide for their needs, but this is our actual challenge as leadership.
I love this point. This is why I picked the OKR example. In *theory*, it could provide a lightweight "api" between teams and other teams. The format is standard. The contents are not. But once you mix in other things.... one the institutionalization happens, etc. ... you start to run into trouble. I have more to say on your comment, and not enough time, but writing to thank you.
Great post, John! Love how you explain the "zombie processes" problem with OKRs. It’s crazy how what should bring focus just becomes a checkbox in big companies. The disconnect between goals and reality is real. You’ve got me thinking 🤔. Thanks for sharing! 👏
I’ve noticed how OKRs have evolved into KPIs to hit and really resonated with this piece. I'll be reflecting more on the purpose of OKRs.