Google Didn't Adopt OKRs to Fix Problems – They Adopted Them to Focus Strength

It’s 1999. Mountain View, California. Google has around 40 employees, a search engine that outperforms everything else on the market, and a team of brilliant minds. The company works. People deliver. The culture is defined by ownership, technical excellence, and an almost radical degree of autonomy.

Around a ping-pong table that doubles as a conference table sit Larry Page, Sergey Brin, Marissa Mayer, Susan Wojcicki, and Salar Kamangar. Standing in front of them is John Doerr – venture capitalist at Kleiner Perkins and a fresh investor in Google – with a PowerPoint presentation. He’s brought a framework he learned in the 1970s from Andy Grove at Intel. Grove, legendary CEO and management thinker, had built on Peter Drucker’s Management by Objectives to develop his own system called iMBOs (Intel Management by Objectives) – a disciplined method for creating clarity around goals and measurable progress in a complex semiconductor company. Doerr refined this approach and gave it a new name: Objectives and Key Results. OKRs.

A detail that’s easy to overlook: Intel, too, was not a struggling company when this system was introduced. It was a market leader. High-performing. Powerful. Grove didn’t invent OKRs to get Intel back on track – he created them to keep an already functioning organization focused in a rapidly changing market. The pattern repeats at Google.

The question worth asking: Why? Why does a company that’s clearly working need a new system for goals?

The answer to that question is the key to whether OKRs will work in any given organization – or become an expensive disappointment.

The Problem Google Actually Had

In 1999, Google did not have a dominant delivery problem. The challenge wasn’t unstable processes or overloaded teams that didn’t know what to do next. The engineering culture was strong, and the organization’s execution capability was remarkably high compared to most companies.

What Google had was an alignment problem – and it was becoming clear that this problem would grow exponentially with scale. The central question wasn’t “Can we deliver?” but rather: “Are we delivering the right things?”

The scenario is typical for fast-growing organizations: dozens of highly autonomous teams, each brilliant on its own, each with its own ideas, priorities, and convictions about what matters most. The consequences are predictable:

• Teams work in different directions without realizing it.
• Work gets duplicated because no one can see what others are doing.
• Local optimizations emerge that don’t serve the overall result.
• There’s no shared answer to the question: What are we actually working toward – and how does it all connect?

The work was there. The results were there. But no one could say with certainty whether those results were the right ones – whether they contributed to the outcome that mattered for Google as a whole.

This is not a trivial problem. And it gets bigger with every new team, every new product, every new initiative. Fragmentation is the natural enemy of fast-growing organizations.

What Google Deliberately Did Not Want

This is where it gets interesting. The obvious solution for lack of alignment would be: more control. More top-down direction. A few executives sit down, define the goals, and everyone else executes.

Google consciously decided against this. Larry Page and Sergey Brin didn’t want a classic hierarchy where goals are dictated from above. No bureaucratic planning processes. No centralized micromanagement.

Why? Because they understood that this very autonomy – the freedom of teams to make their own decisions – was one of Google’s greatest competitive advantages. Introducing control to force alignment often destroys exactly what makes a company strong.

The real challenge was more nuanced than it initially sounds:

How do you create alignment in a decentralized, fast-growing system – without central control?

Why OKRs Were the Answer

OKRs addressed exactly this problem. Nothing more, nothing less. Their core is radically simple: Objectives define which result is being pursued – the desired outcome. Key Results measure whether that result actually materializes. OKRs thus focus not on output (What did we build? How much did we deliver?) but on impact (Did what we did achieve the intended effect?).

Transparency: All goals are made visible. Every team, every leader can see what others are working on – and more importantly: what they’re working toward. No more black boxes, no more silos.

Alignment: Company-level Objectives provide a frame. Teams derive their own OKRs from it – they’re not dictated, they’re derived. This is a crucial distinction: the frame comes from the top, the execution from the bottom.

Autonomy: Teams define for themselves how they contribute to overarching goals. They choose their own Key Results, their own paths. Ownership remains intact.

Rhythm without bureaucracy: Quarterly cycles create regular reflection without falling into rigid annual planning.

And a detail that’s often overlooked: Google deliberately did not tie OKRs directly to bonus or performance review systems. OKRs feed into the broader context of performance assessment, but achieving or missing individual Key Results does not determine salary or promotion. Why? Because ambitious goals only work when missing them doesn’t carry a direct penalty. Google’s famous expectation that for ambitious, so-called aspirational OKRs, a 60–70% achievement rate already counts as success, only works in a system that rewards ambition rather than punishing it.

This is a point where many companies fail when introducing OKRs – but more on that shortly.

What OKRs Did Not Have to Solve at Google

Just as important as the question of what OKRs solved at Google is the question of what they didn’t have to solve.

Google already had:

• Functioning delivery. Teams shipped. Products were built, tested, and rolled out.
• High ownership. Teams operated independently and took ownership of their results.
• High execution capability. The organization could get things done – and fast.
• A strong engineering culture. Quality, technical excellence, and craftsmanship were deeply embedded.

OKRs were not introduced to create capability. They were introduced to align existing capability.

Or put more sharply: Google didn’t need OKRs to become high-performing. They needed OKRs to focus their already existing high performance.

That is the decisive point. And it’s overlooked almost everywhere.

The Elephant in the Room: Why OKRs Don’t Work in Many Companies

Now let’s make the leap from 1999 to today. Into the reality of companies adopting OKRs.

An important framing first: this is not about copying Google. The conditions – talent density, capital, market position – are fundamentally different in most organizations. But the pattern behind Google’s OKR adoption is universal: OKRs work where a functioning system needs direction.

And another thing: executives and leaders who want to introduce OKRs rarely do so out of naivety. The search for a system that creates focus, transparency, and alignment is entirely understandable – especially when you sense that the organization is losing momentum. The question is simply whether OKRs are the right tool for the actual problem.

I regularly encounter organizations that start with OKRs – not because they have an alignment problem, but because they hope OKRs will solve entirely different problems:

• Overload. Teams are working on too many things simultaneously. The hope: OKRs will force focus.
• Lack of prioritization. Everything is important, nothing takes precedence. The hope: OKRs will create clarity.
• Unstable processes. Projects don’t get finished, releases are unreliable. The hope: OKRs will bring structure.
• Unclear responsibilities. Nobody knows who decides what. The hope: OKRs will define accountability.

These are real problems. But they’re not alignment problems. They are problems of delivery capability – that is, the ability of an organization to reliably complete work: prioritized, with limited parallelism, and within stable cycle times. And OKRs are not a primary tool for lacking delivery capability – they can make deficits visible, but they cannot create the operational foundation needed to actually achieve goals.

What happens when you layer OKRs onto a fragile system? You get beautifully formulated Objectives that no one achieves. You get Key Results that are red at the end of the quarter – not because the goal was wrong, but because the organization wasn’t able to work toward it. You get frustration, OKR fatigue, and ultimately the statement: “OKRs don’t work for us.”

But the OKRs did work. They did exactly what they were designed to do: they made visible that the organization has a problem. Just not the problem that OKRs can solve.

The Contrast That Explains Everything

The difference between Google’s OKR adoption and what happens in many companies today can be distilled into four dimensions:

OKRs are an amplifier. They amplify what’s already there. In a functioning system, they amplify focus, transparency, and alignment. In a dysfunctional system, they amplify visibility – specifically, the visibility of dysfunction.

That’s not a bad thing. But it’s not what most companies hope for when they introduce OKRs.

What This Means in Practice

I’m not saying OKRs are bad. On the contrary – in the right situation, they’re an excellent tool. But the right situation has prerequisites:

First: The organization must be able to deliver. When the basic mechanics of collaboration don’t work – when projects don’t get completed, when releases are unstable, when teams are in permanent firefighting mode – OKRs won’t fix that. What’s needed first are different interventions: WIP limits to make overload visible and reduce it. Clear decision rights so teams don’t get stuck in coordination loops. Stable delivery cycles that create reliability before ambitious goals are layered on top. Putting OKRs on a fragile system is like buying a heart rate monitor for a beginner runner – the measuring device isn’t the problem.

Second: OKRs must not be directly tied to compensation or promotion. As long as achieving or missing OKRs has direct consequences for salary or career, teams will set conservative goals. Then OKRs lose exactly what makes them powerful: ambition.

Third: The frame comes from above, the execution from below. OKRs are neither pure top-down nor pure bottom-up. They’re a conversation between leadership and teams. Using OKRs as pure targets from above is just performance management in new clothes. Running them purely bottom-up produces alignment by accident.

If Not OKRs – Then What?

When the honest diagnosis is that the organization has a problem with delivery capability, the follow-up question is: Where do we start?

Two complementary perspectives are worth exploring here: Lean Portfolio Management – the active governance of which initiatives get funded and started – and Flow of Work orientation – the question of how work actually moves through the organization.

OKRs answer: Are we delivering the right things? – the outcome question. Flow orientation answers the question before that: Can we reliably deliver at all? – the delivery capability question. Both perspectives complement each other, but the sequence matters.

Making overload visible. Most organizations don’t have a prioritization problem – they have a de-prioritization problem. Everything gets started, nothing gets consistently finished. WIP limits at the portfolio level make visible how many initiatives are actually running in parallel. Flow metrics like throughput and cycle time show that more parallel work doesn’t lead to more results – it leads to longer lead times and more context switching. OKRs can’t solve this problem because they set goals but don’t control the volume of work.

Actively managing the flow of resources. Lean Portfolio Management creates a layer between strategic intent and operational execution. Which initiatives get funded, which don’t? Which get stopped when conditions change? A company can formulate perfect OKRs and still run 15 strategic initiatives in parallel that cannibalize each other’s capacity. OKRs define goals – but they don’t control how much work gets pushed into the system simultaneously.

Stabilizing delivery before setting direction. When work gets stuck in queues, when handoffs between teams create wait times, when there are no reliable delivery cycles, even the best Objectives won’t help. Flow metrics – throughput, WIP, cycle time, work item age – make these bottlenecks visible and manageable. They don’t show what should be delivered, but whether the system is capable of delivering at all.

The logic is simple: first establish delivery capability, then sharpen direction. Or put differently: first make sure the ship is seaworthy – then set the compass.

The Real Question

Before a company thinks about OKRs, an honest assessment is worthwhile:

Do we have a problem of alignment – or a problem of delivery capability?

When teams are working in different directions even though each one functions well on its own: OKRs can help.

When teams are unable to reliably complete their current work: OKRs won’t solve that. They’ll only make it more visible.

Google introduced OKRs to create direction. Many companies introduce OKRs to solve problems that have nothing to do with direction.

The difference sounds subtle. But it determines whether OKRs become a game changer – or the next framework that ends up in the drawer after two quarters.

A Final Thought

Andy Grove reportedly once said at Intel that there’s no point optimizing the compass when the ship has a hole in the hull. OKRs are an excellent compass. But they don’t repair hulls. Those who recognize this can put both in the right order – and that’s exactly when OKRs become the powerful tool they were designed to be.

The question is not whether OKRs work. The question is whether the system is ready to use them.