Yeah, that's roughly about the sum of it. Other observations about OKRs that I would have liked to see included are: - The article calls out how Measure What

Yeah, that's roughly about the sum of it. Other observations about OKRs that I would have liked to see included are: - The article calls out how Measure What Matters and OKRs only work if the key results are legitimate metrics, real numbers as opposed to boolean flags: continuous system outputs. But at scale, some subteams just put their tasklists into OKRs as boolean KRs, make up a nebulous objective to cover them, and reimplement the same flawed systems that OKRs were meant to replace. - Often OKRs are scoped beneath the team level to the personal level. This is very dangerous. The unit of production is not the individual but the team. You tend to create perverse incentives when you go one level lower, “I am an amazing employee because I didn't care about my struggling colleagues and ignored them and delivered 10 times as much work as them!” - OKRs need to be understood as a management back-off to be effective, but this culture shift is relatively uncommon. If you look up the literature on setting good OKRs, you will find blog articles about SMART goalsetting or whatever, but very little about “OKRs are about treating your employees as research scientists. You are going to give them a goal to do research on, that is the objective, and you're going to open up the pocketbook and just say, how much grant money do you need to solve this objective. So that's why it's important that the objective makes the business money, you need to know how open the pocketbook is. Meanwhile, the KRs are important because research projects have a sort of inertia, by themselves they do not respect the Pareto principle to do the 20% work that drives 80% of the result. So you have to tell your researchers when it's okay to stop, they won't know that unless you tell them and they will keep tweaking to get that last 2% efficiency out of the system.” Tutorials just don't have this perspective! - OKRs probably only make sense in terms of a complex system, so required reading should probably be Donella Meadows’ Thinking in Systems. In particular, you need to understand that for something to change often everything must change. People try to do these very tiny scoped OKRs and that's kind of risky. To get a complex system to change, often you just need to hold the output at some desired level, and allow the internals to reconfigure to provide that output. Nobody talks about OKR-induced organizational chaos, but ideally you should have one or two OKRs a year that really rearrange the entire system because they happened to be located at a bottleneck and they had to twist the system around until something else became the bottleneck.