30 Apr 2026 8 min read

OKR Maturity: Just Enough to Get Things Done

Your OKR ambition should be constrained by your organisational maturity. Most companies ignore that and copy the wrong model.

I remember sitting in an all hands and watching the product manager hear the quarterly OKRs for the first time.

Not in a planning session or a working group where they'd helped shape them but in the whole company all hands. Some of the objectives were specific and clearly written by someone trying to course-correct something, but they were disconnected from what the PMs already knew from months of customer conversations. The insight was there, the objective wasn't feasible, and so we went around in a circle wondering why the insights weren't used when the OKRs were written.

What struck me wasn't that the OKRs were written badly, they were actually good. What struck me was the ambition of the process - the structure, the cascading objectives, the quarterly cadence relative to where the company actually was. It was a company running a scale-up OKR system before it had the maturity to support one.

That's the problem I saw. Not that OKRs are broken, but that companies adopt a version of OKRs that their org isn't mature enough to support. Sometimes they copy what Google does, or what they read in a book, or what their last company did without asking whether their organisation can actually support that right now.

Every stage of company growth has a ceiling on OKR complexity, if you try to push past it the system collapses under its own weight however, if you stay within it, the OKRs do exactly what they're supposed to: help people make decisions.

What OKRs are actually for

Before getting into stages, it's worth explaining.

OKRs - Objectives and Key Results are a coordination mechanism. An Objective is a qualitative description of what you want to achieve. Key Results are measurable outcomes that tell you whether you got there. That's it.

They don't tell you how to build a product or manage a team. They exist so that people can make decisions without asking permission so that when something new comes in, anyone on the team can work out whether it connects to what matters most right now. That's a useful check, not whether they're written down, not whether you reviewed them last quarter but whether people are actually using them know to prioritise.

Take these examples OKRs:

From the above you can tell OKRs can get pretty complicated which can make you feel like you need everything to get things done, but you really don’t need everything - let's tour on what OKRs look like at each stage of maturity.

Pre-seed: No OKRs

What your org can absorb: shared context, honest weekly check-ins, not much more.

At pre-seed you're a small group of maybe two to five people working on a problem you think is worth solving. Formal OKRs at this stage cost more than they give back. When everyone in the room already knows what you're trying to achieve, you don't need a framework to hold it.

What you need is a weekly habit: what are we trying to learn this week, did we learn it, what do we do next. The reason this works at pre-seed is that the coordination problem isn't execution alignment yet, it's shared learning. You're still trying to find out if you're solving the right problem. OKRs are an execution tool, and you can't align execution before you know what you're executing toward

What good looks like: no OKRs. A shared doc with three things you're trying to prove this month and an honest weekly conversation about whether you're proving them.

If you're writing quarterly objectives when you're not sure you'll still be working on the same problem in six weeks, you're optimising for the wrong thing.

Seed: One objective, three key results

What your org can absorb: a single shared priority, simply stated, visible to everyone.

As the team grows past a handful of people (about 5-15 people), shared context stops being automatic. People are working on different things and there's a real risk of optimising locally without realising you're pulling in different directions. This is when lightweight OKRs earn their place.

The ceiling here is low and deliberately so. One objective, three key results at most written down somewhere everyone can see to be revisited monthly. The purpose is alignment because you want anyone on the team to be able to answer without asking: what does the company care about most right now, and does what I'm working on connect to it?

What good looks like:

Objective: Find 10 customers who can't live without the product

KR1: 10 users complete the core workflow end to end without support KR2: 5 of those users come back unprompted within 7 days KR3: At least 3 tell us they'd be disappointed if the product disappeared

Notice what this gives a PM or engineer to work with. If someone proposes a new feature, the question is immediate: does this help users complete the core workflow and come back within 7 days? If yes, it's worth discussing. If not, it can wait. The OKR creates useful tension which is the whole point.

The process to get here should take an afternoon. If it's taking longer, you're already overcomplicating it.

Series A: Two to three objectives, commercially anchored

What your org can absorb: a small number of objectives that connect directly to commercial outcomes, set with the people closest to the work.

Series A is where OKRs become genuinely necessary and where most companies get them wrong.

You have funding, investors, expectations, and more people than you can fit in one room. The teams are forming, functions are separating, and "everyone knows the goal" is no longer true. At this maturity level OKRs stop being a nice-to-have and start being the thing that holds strategy together across teams.

Unfortunately, this is also where the copying starts, someone's read the Google playbook and suddenly you have cascading objectives across six teams, a dedicated tool, and a quarterly review process where the people closest to the work had no hand in writing any of it.

From my own experience, the OKRs that worked were always anchored to something real and near for example, a deal to close or a customer milestone with a number attached. This gave the team a baseline that everyone knew what winning looked like and could make decisions accordingly.

In terms of bets, they aren't a trap - bets are necessary at Series A. You've got the funding so you're supposed to be taking calculated risks on where the grow. The problem is making bets without the key results to know if they're paying off. I've seen this first hand, a bet with a pilot attached and a real customer with a defined outcome worked because there was something concrete to point to at the end of the quarter. The bets that didn't work were the ones that had an objective but no key results "expand into [specific niche vertical]" with no key results. The objective was specific enough, but nobody had asked the harder questions: why this vertical, what does winning look like here, how do we know in 90 days if it's worth continuing? Without that it ran on hot air. It showed up in meetings with no work attached, then got stuck in a reprioritisation loop.

The other thing that breaks at this stage is OKRs written without the people who understand the customer. PMs are having the customer conversations so they know which problems are urgent, which promises are being made in sales calls that the product can't keep. Without that in the room, OKRs get set against leadership's assumptions rather than customer reality so by the time they're presented at an all hands, they're already partially wrong.

What good looks like:

Objective: Double our mid-market customer base this quarter

KR1: Close 6 new contracts with companies between 50–200 employees KR2: All new customers have a defined onboarding plan and hit their first milestone within 14 days of signing KR3: 3 customers agree to be references or case studies

Same as the seed stage OKR, one objective, three key results.

But the benefits are clear. To a PM: a clear basis for prioritisation, to work on things that helps close or retain mid-market customers and work that doesn't should wait. To an engineering team: the ability to push back on scope with evidence - this adds three weeks and doesn't move any of these numbers.

Start with two to three objectives maximum. Anyone telling you a Series A company needs five cross-functional objective tracks hasn't yet thought seriously about how much organisational bandwidth that actually requires.

Scale-up: Fewer than you think, closer to the work than you'd expect

What your org can absorb: a mature goal-setting process but only if it stays connected to real work and real decisions.

OKRs don't disappear at scale - they multiply. They're well-formatted, reviewed quarterly, presented at all hands and yet nobody's using them to make decisions. Teams write their OKRs after they've already decided what they're building and quarterly reviews become a performance. The distance between top-level objectives and actual day-to-day work is so large that the connection is theoretical.

The signal to watch for: if your team can't tell you off the top of their heads what their current key results are, the OKRs aren't doing anything. They exist, but they're not part of how the team thinks.

What good looks like:

Objective: Make the product ready to win and keep enterprise customers

KR1: Close 3 enterprise contracts at £100k+ ARR KR2: Enterprise onboarding completed without custom engineering work for each new customer KR3: SOC 2 certification achieved or audit initiated this quarter

The difference at this stage isn't the format, it's the connection since these OKRs have to live inside the actual planning process, not alongside it. Engineering managers and PMs need to be involved in setting them, not just receiving them and someone senior has to be willing to say what's not an objective this quarter which is always the harder conversation.

The constraint principle

Here's what I actually think the problem is, underneath all of it.

Companies don't fail at OKRs because the framework is wrong. They fail because they don't respect the constraints their organisational maturity imposes.

Whatever your headcount, if your teams can't yet execute reliably against one objective, adding four more won't help. This is where ambition quickly turns to chaos with a goal-setting layer on top. The organisation doesn't have the coordination muscle, the trust, or the shared language to carry that weight yet. So the OKRs float. They get written, reviewed, and quietly ignored.

The constraint isn't a limitation. It's the thing that makes OKRs actually work. One objective forces prioritisation. Commercial anchoring forces honesty. Involving the people closest to the work forces the goals to reflect reality.

Start with less than feels right. Be more specific than feels comfortable. And before you add another objective, ask whether your organisation has actually demonstrated it can execute against the ones it already has.

The test

One question worth asking regularly, at any stage:

Can anyone on my team tell me, without hesitating, what we are not doing this quarter and why?

If the answer is yes, your OKRs are doing their job. If nobody can answer it, you haven't constrained enough.

TL;DR

OKRs aren't broken, most companies just adopt a version their organisation isn't mature enough to support.
Pre-seed doesn't need them, seed needs one objective, Series A needs two to three anchored to something real, scale-up needs fewer than you think.
Bets are fine at Series A, bets with no key results aren't, they run on hot air.
The constraint isn't a limitation, it's what makes OKRs actually work.
If your team can't tell you what you're not doing this quarter and why, you haven't constrained enough.