Dear CIO,

I have been skeptical of OKRs for a long time. This does not mean I think organizations should operate without goals, or that measurement is not important. In fact, I think people deserve to know what matters, why it matters, and how their work contributes to it, but my skepticism starts somewhere more specific. I am not convinced that turning strategy into a hierarchy of objectives and measurable key results is, by itself, an effective management system. The part that gives me pause is that so many thoughtful people disagree.

John Doerr makes a compelling case in Measure What Matters. Andy Grove built the precursor to OKRs at Intel. Google adopted them early and has become the textbook example of successful implementation. That is not to mention plenty of other organizations that point to OKRs as the reason they gained focus, alignment, and accountability. When enough smart people arrive at an opposite conclusion, it is worth asking whether your own assumptions deserve another look. This is the question I have been wrestling with: 

Am I wrong about OKRs?

Best Regards,
John, Your Enterprise AI Advisor

Goals and metrics matter, but they are not a substitute for systems thinking.

Most histories of OKRs begin with Peter Drucker's idea of Management by Objectives (MBO) in the 1950s. Drucker believed employees should understand the purpose behind their work instead of simply following instructions from above, so objectives were meant to connect individual effort to organizational purpose. Later, Andy Grove further refined that thinking at Intel by separating the objectives from measurable outcomes. The objective described what the organization wanted to accomplish. The key results provided evidence that it had actually happened.

Then came John Doerr, who learned the approach while working at Intel under Grove, and introduced the framework to Google's founders in 1999. Doerr introduced OKRs as a system of creating focus, alignment, and disciplined execution. Ever since, Google has been one of the most frequently cited examples of successful OKR adoption. In 2018, Doerr brought the method to a much wider audience with Measure What Matters. The book describes OKRs as a simple but powerful goal-setting system:

The objective defines what is to be achieved.

The key results describe how achievement will be measured.

His central claim is that OKRs help organizations focus on what matters most, align teams around common priorities, track progress, and encourage ambitious thinking. He supports the argument with stories from Intel, Google, the Gates Foundation, Bono’s ONE organization, and numerous other technology companies. These are not trivial claims. If true, they solve problems that almost every organization struggles with.

One thing I appreciate about Doerr's argument is that it starts with a real problem. Most organizations have far too many. Leadership announces that customer experience, innovation, agility, AI, and cost reduction are important. Everything is presented as a priority until the word loses its meaning, and OKRs force leaders to answer harder questions, such as what we are actually trying to accomplish and how to recognize progress.

Conversations such as these are valuable regardless of whether an organization ultimately embraces OKRs. At their best, they replace vague executive language with something concrete enough that people can actually work toward it. In fact, I think this is where the strongest argument for OKRs really lives. They improve the quality of the conversations organizations have about those goals.

Take, for instance, when developing OKRs: writing an objective requires a specific level of clarity, and writing key results forces leadership to define what evidence it will accept. Then, when publishing, those priorities can make disagreements visible instead of allowing them to remain hidden beneath PowerPoint slides and strategy documents. Sometimes the discussion reveals important discoveries around strategy and measurement.

Regardless of the power of OKRs, my concern starts when they stop being a communication tool and become the management system itself. For instance, let’s say an organization creates a key result of reducing customer-reported incidents by 30%. While it might be clear and measurable, it does not tell us why the incidents are happening in the first place. There is no indication of how stable the process itself is or what a possible constraint may be. This key result only tells an organization where it would like to end up instead of how to get there. It provides a destination without offering a theory for how the organization expects to arrive there.

That is where my thinking starts to diverge from the OKR philosophy and begins to sound much more like Deming. Deming was opposed to managing people by numerical objectives without first providing a method for achieving them. This is a distinction I think is easy to overlook. A numerical objective can communicate what management wants, but it cannot substitute for knowledge of the system producing the result. Without that understanding, organizations often mistake measurement for improvement, and they can become very good at describing the outcome they hope to achieve while remaining uncertain about the changes most likely to produce it.

There is another challenge that naturally follows. Once a measure becomes highly visible, it rarely remains just a measure. To his credit, John Doerr cautions against tying OKRs directly to compensation or performance evaluations. However, even when no one explicitly tells them to, numbers have a way of changing people's behavior. Imagine a support organization measured on ticket resolution time. One team might improve the metric by closing tickets before the underlying issue has actually been resolved. Other times, a software team might increase deployment frequency simply by releasing smaller, less meaningful changes, or a reliability team could reduce reported incidents by quietly redefining what qualifies as an incident. None of these actions necessarily improve the customer experience, yet every dashboard appears greener than before.

This is one of the reasons I am cautious about building an entire management system around measurable results. People naturally optimize the measures they are given, especially when those measures become symbols of success. The organization may become increasingly effective at improving the metric while learning very little about whether the system itself is actually getting better.

One possible response from advocates of OKRs is that these are not failures of the framework itself but examples of poor implementation. Properly designed OKRs are meant to be few in number, focused on outcomes rather than activities, separated from compensation, and used to encourage learning instead of judgment. I think that is a fair defense, but many of the problems I have described emerge when organizations reduce OKRs to scorecards or performance contracts rather than treating them as tools for strategic alignment and discussion.

Even so, the defense raises a question I continue to wrestle with: are those conditions what make OKRs successful, or are they evidence of a well-managed organization regardless of whether it uses OKRs? Organizations built on trust, clear purpose, systems thinking, and a culture of experimentation would likely benefit from many different management frameworks. In that sense, OKRs may do an excellent job of expressing good management, but I am less convinced they are what creates it.

There is another reason I hesitate to place too much emphasis on key results alone. Many of the outcomes organizations care about, like customer satisfaction, reliability, retention, or product quality, are produced by systems that span multiple teams and departments. Those same outcomes, though, are often assigned to a single group as though it alone controls the result. This creates pressure without necessarily providing the authority or understanding needed to influence the system producing the outcome.

When that happens, people often respond in predictable ways. They focus on improving the metric that is visible to leadership rather than the broader system that produces it. Sometimes that means redefining measures, narrowing what gets counted, or emphasizing work that is easiest to quantify. More often, it simply encourages local optimization. A team may improve its own numbers while the performance of the overall organization remains largely unchanged. This is another reason I believe understanding the system itself must come before setting numerical targets.

This is also where I find Goldratt's thinking especially helpful. While OKRs begin by asking, What results do we want to achieve? Goldratt begins with a different question: What is preventing the system from achieving more of its goal right now?

Those may sound similar, but they lead organizations down very different paths. An organization can have dozens of well-written objectives, complete alignment across departments, and carefully measured key results, yet still overlook the single constraint limiting the performance of the entire system. In that situation, improving several local measures may do very little to improve overall performance. Teams remain busy, dashboards remain healthy, and progress appears visible, while the real bottleneck remains largely untouched.

That is why I increasingly think the center of gravity should shift away from objectives themselves and toward understanding the system. Before asking how much we want a number to improve, we should first ask what is preventing improvement in the first place. The answers to those questions are often much more valuable than the targets we eventually choose.

None of this means I think organizations should abandon objectives or stop measuring results. Both have an important role to play, but I simply would not place them at the center of the management system. Instead, I would begin with a clear aim, identify the primary constraint limiting performance, develop a theory for why that constraint exists, and then design experiments to test whether proposed changes actually improve the system. Here measurement still matters, but it serves a different purpose. Rather than judging whether a team hit a predetermined number, it helps determine whether our theory was correct and whether we are learning something useful.

If we go back to the previous example of reducing critical incidents by 30%, the aim would be to create a more reliable customer experience. The constraint could be that deployment verification is currently limiting the ability to release safely, so the theory that is developed could be that reducing deployment batch size and improving pre-production verification should decrease escaped defects without slowing delivery. To test this theory, the organization could try changes with two product groups through a series of small experiments, and the organization could study incident frequency, severity, recovery time, deployment rate, and process behavior over time. Finally, they could implement guardrails such as watching for slower delivery, underreporting, additional manual review, and work transferred to other teams.

Viewed this way, OKRs can still have value. They communicate priorities, encourage difficult conversations, and make strategic assumptions more visible. Those are meaningful contributions. I just do not believe they should be mistaken for the management system itself.

I am still not entirely sure. Reading Measure What Matters has made me appreciate why so many successful organizations have embraced OKRs. John Doerr is addressing real problems, and many of his observations about focus, alignment, and accountability are persuasive. If nothing else, the framework forces leaders to have conversations they might otherwise avoid. I also think my skepticism has become more focused. I realized that my concern has never been about having objectives or measuring progress, but rather about confusing a target with a method. Organizations do not improve because they become better at describing the results they want. They improve because they develop a deeper understanding of the systems that produce those results.

For now, I still see OKRs as a valuable communication tool because they force conversations organizations often need to have. I'm simply not convinced they are, by themselves, an operating system for management. However, I believe it is more important to determine whether an organization has a theory and a method for changing the system, or does it simply have a clearer description of the results it hopes to see?