Stop performing competence. Start operating.

Every time I mention EOS to someone running OKRs, I get the same response: "Oh yeah, that's just OKRs." It's the kind of thing people say when they've understood neither. Rocks and OKRs overlap — both set quarterly priorities. That's one component out of an entire operating system. Saying EOS is just OKRs is like calling a kitchen "just a stove." It tells me exactly how deep your analysis went.

This isn't a pitch. I'm not an EOS Implementer. I don't sell organisational consulting. I'm telling you to buy a £15 book and stop haemorrhaging money on people who can't solve your problem because they can't see it.

What EOS Actually Is

Rocks are the OKR-equivalent, and they're arguably better OKRs than OKRs because they strip out the scoring theatre. Done or not done. No 0.7-is-ambitious performance art, no cascade algebra, no end-of-quarter grading ritual where everyone pretends a miss was a "stretch."

But Rocks are one piece. Around them you get the Accountability Chart — separating seats from people, which is org design, not headcount management. The Level 10 meeting with a fixed agenda that physically cannot drift. A weekly Scorecard of leading indicators: green or red, no narratives. IDS — Identify, Discuss, Solve — a protocol for working problems in the room instead of deferring them to a follow-up that never happens. And the V/TO, holding vision, values, ten-year target, and marketing strategy on a single page.

OKRs
EOS
Goal framework — you supply everything else
Complete operating system — batteries included
Scoring rubrics, cascade debates, alignment theatre
Done or not done. Green or red.
You invent the meeting cadence
L10: same time, same people, same agenda, weekly
No opinion on org structure
Accountability Chart — right people, right seats
No decision protocol
IDS — decide in the room or don't raise it
Requires consultants to operationalise
The book is the entire engagement

OKRs are a framework you have to operationalise, and every company spends six months reinventing how to run them. EOS is pre-operationalised. Wickman already made the decisions. That's the feature.

I Respect OKRs. That's Why This Matters.

Andy Grove is one of my favourite authors. High Output Management is one of the sharpest books on operations ever written. OKRs, as Grove designed them — goals with measurable outcomes, honest assessment, tight feedback loops — are a genuinely good idea. Having goals and measures is generally good. There are times they blind you and your gut needs to take over, but the principle is sound.

That's not what I'm attacking. I'm attacking what happens to OKRs between Grove's brain and your company's Q3 planning session.

What I've seen, repeatedly, is OKR rollouts driven by people who are operating on third-hand knowledge. They didn't read Grove. They read a blog post by someone who read a summary of Measure What Matters by someone who attended a conference talk. By the time the method reaches the person writing it on your whiteboard, it's been through so many rounds of compression and Chinese whispers that what arrives bears no resemblance to the original. The ceremony is intact. The thinking is gone.

And nobody involved in the rollout is capable of noticing, because noticing would require them to have understood the original well enough to see what's missing. They're implementing something they've never actually understood, with total confidence, because the sound bites gave them the illusion of comprehension. That's the dangerous part. They're not uncertain — they're certain and wrong.

We've watched this exact movie before. It was called Agile. A manifesto written by seventeen engineers who understood software deeply — four value statements, twelve principles — got hollowed out by the same parasite class until "individuals and interactions over processes and tools" became a certification industry built entirely on processes and tools. OKRs are on the same path, ten years behind. The consulting circuit, the SaaS category, the conference talks, the coaches — it's the same playbook. The corpse of a good idea being puppeteered by people who never understood what it looked like alive.

The Capacity Problem

OKRs require intelligence as an input. They don't produce it. Writing a real key result means understanding the difference between a leading and lagging indicator, resisting the urge to put "ship feature X" in a KR slot, and telling the truth about what you can measure. The framework assumes all of that and supplies none of it.

This isn't a judgment problem. Judgment implies the information is there and someone fails to weigh it. What I'm describing is people who can't see the problem at all. They read "Objectives and Key Results," nod, and write an activity list with a percentage next to it. The distinction between an output and an outcome doesn't exist in their head. You can't exercise judgment about a concept you haven't formed.

This is also why sound bites are the primary transmission mechanism. "Measure what matters" compresses to a tweet. The ninety pages of context that tell you how don't. By the time the method reaches most companies, it's been through so many rounds of compression that the ceremony is all that's left.

EOS has a diagnostic for exactly this: GWC. Get it, Want it, Capacity to do it. Most people running OKRs don't get what the framework is actually asking. And capacity is the intelligence piece — the ability to decompose a system, find the root, and hold enough variables simultaneously to see how they interact. No amount of wanting fixes a capacity gap.

EOS doesn't require you to be Andy Grove to adopt it. L10 works whether your root-cause analysis is brilliant or mediocre. The Scorecard turns red regardless. Rocks get marked off-track regardless. The system degrades gracefully when the operator isn't sharp. OKRs degrade into fiction — and fiction shows up green, identical to the real thing, which is why nobody notices for years.

Surface Optimisation and the People Who Sell It

I watched a company hire consultants to improve organisational efficiency. Months of engagement. The headline recommendation: cut five minutes off meetings.

This is the diagnosis of someone who saw the symptom — people complain about meetings — and prescribed a painkiller without examining the patient. The meeting isn't too long. The meeting either shouldn't exist, has the wrong people in it, or has no structure. "Cut five minutes" addresses none of these. It's an answer that could only come from someone who has never once asked why a meeting exists.

L10 solves all three problems by design. Same time, same people, same agenda, every week. The structure prevents drift. IDS forces decisions. And if you're not contributing to the agenda, you're not in the room. Steve Jobs ran a three-hour Monday meeting at Apple and nobody called it a problem because it was the engine — right people, authority to decide, and the meeting existed to make decisions.

Now, look at who recommended "cut five minutes." These are the people driving organisational improvement in most companies. And they have a specific career trajectory.

Couldn't last as an engineer. Moved to project management. Couldn't deliver projects. Moved to "process improvement." Couldn't improve processes. Became a methodology evangelist. At each stage they got further from the actual work and closer to an abstraction layer where you can't be proven wrong because you're never accountable for output — only for adoption.

I know this paragraph will offend people. Good. These people hide behind professional courtesy and the expectation that nobody will call out their work because it's wrapped in the language of frameworks and best practices. The emperor has no clothes, and the tailor is charging day rates.

These people reach for OKRs because OKRs are native to their habitat: spreadsheets, slide decks, quarterly reviews, alignment workshops. EOS is harder to co-opt because it drags you back to reality. Numbers are green or red. Rocks are done or not done. IDS forces you to solve something before you leave the room.

And here's the recursive tragedy. If you put EOS in front of these people, the first thing it would do is expose that they are the problem. The Accountability Chart asks what the seat requires. GWC measures them against it. The honest answer is they don't belong there. So of course they don't choose EOS. They choose the framework that lets them stay.

OKRs are a survival mechanism for the wrong person in the wrong seat. EOS is a threat to them.

The Pied Pipers

OKRs are structurally incomplete. Not accidentally — structurally. The framework has enough gaps that someone has to come in and fill them. How do you cascade? Hire a consultant. How do you score? Hire a consultant. How do you align across teams? Hire a consultant. The ambiguity is the revenue model for an entire class of pied pipers leading companies on a merry dance to their banks.

And it is a dance. The music never stops because the engagement is structured so the piper can never be wrong. Rollout fails? Blame adoption. Sell a refresh. Still failing? You need a "maturity assessment." You're at level two. Level four requires another six-month engagement. The framework is unfalsifiable from the vendor's side — every failure is an implementation failure, never a "this shouldn't have been adopted" failure.

EOS refuses to play. Wickman wrote the book, published the tools, put the templates online, and said go. The V/TO is a single page. The Scorecard is a spreadsheet. The meeting agenda fits on a card. You can run the entire system without spending a penny beyond the book. The consulting industry doesn't push EOS because there's no recurring engagement in a system that actually works.

OKRs Are Java. EOS Is Go.

Go gives you one way to format code, one way to handle errors, one way to build concurrency. You didn't get generics for fifteen years because you didn't need them yet. The community argued. The language sat there being productive while they argued.

OKRs are Java. Endlessly configurable, enterprise-friendly, compatible with every consultant's slide deck. By the time you've finished deciding how to structure your framework for implementing your framework, the quarter's over. The flexibility isn't power. It's rope.

EOS is Go. Opinionated, constrained, unfashionable in the rooms where people perform sophistication, and relentlessly effective for the people who need to ship. You don't argue about meeting format. You don't invent a scoring rubric. You don't customise. You open the book. You follow the system. You run.

Simplicity is a filtering mechanism. It repels the people who need complexity to hide in and attracts the people who need to get something done. Go does this. EOS does this. It's the same design philosophy applied to different domains.

Where EOS Breaks

EOS wasn't built for large enterprises with 500+ person engineering orgs. It doesn't handle matrix structures well. It has nothing to say about technical architecture, product discovery, or R&D. The Accountability Chart gets unwieldy past a certain scale, and the assumption that every problem can be IDS'd in a weekly meeting stops holding when the problems are multi-quarter, cross-functional, and genuinely novel.

If you're running a 2,000-person division at a FTSE 100, EOS isn't your system. But you're not. You're running a 15-to-200 person company with real customers and real problems and a finite amount of time to solve them. And for that, EOS is the most honest, most complete, most immediately useful operating framework available. It respects you enough to give you the whole thing and trust you to run it.

The Entire Consulting Engagement

£15
A copy of What The Heck Is EOS?
The complete operating system for your company.
vs. the £200K you were about to spend on someone who can't see the board

Buy the book. Read it with your leadership team. Run L10 meetings. Build the Accountability Chart. Track a Scorecard. Set Rocks quarterly. Use IDS when problems surface. That's it. No coach. No workshop. No twelve-week transformation programme. A book and the honesty to use it.

The prom queen gets the attention. She always does. But you're not choosing a date to impress the room. You're choosing a system to run a company. Pick the one that works.

Everything You Need. No Consultant Required.

And if you want to understand OKRs properly — as Grove intended — read High Output Management. Not a blog post about it. Not a summary of a summary. The actual book. You'll see how far the telephone game has drifted.