OKRs Aren’t Enough
OKRs have a good track record. The framework has been used at Intel, Google, Amazon, and hundreds of other companies to connect strategy to execution at scale. If you’ve read Measure What Matters by John Doerr, you understand why: objectives give teams a qualitative direction, key results give them a measurable way to know if they got there, and the whole system cascades down through an org in a way that keeps everyone pointed at the same goals.
But for companies in the 50 to 250 employee range, pure OKRs have a consistent failure mode. They define what you want to achieve and how you’ll measure it. They don’t always make clear what you’re actually going to do. And in a smaller organization, that missing piece tends to be the difference between a planning exercise and a plan that gets executed.
The Problem With Objectives and Key Results Alone
The OKR framework was designed for large organizations where the cascade is the point. At Google, you can set a high-level objective — beat a competitor on a specific capability, for example — and then challenge hundreds of teams to define their own OKRs in service of that objective. The top-down goal sets the direction. The bottom-up planning figures out how to get there. At that scale, that model works because there are enough teams, enough resources, and enough managerial layers to turn ambiguous objectives into concrete work.
In a company with 100 or 150 employees, the dynamic is different. There are fewer people, fewer resources, and a much smaller margin for planning that doesn’t connect directly to execution. Pete Caputa, CEO of Databox, puts it plainly: in a small or midsize org, 70 to 80 percent of your resources are going to do what they did last year. Serving clients, building product, running operations. The portion of capacity actually available for new initiatives is small. And if you’re going to use that capacity well, you need more than an objective and a key result. You need to know exactly what you’re going to do.
What the Initiative Layer Adds
The OGI framework — Objectives, Goals, Initiatives — adds a third element that most OKR implementations leave out. The initiative is the specific project or body of work that the team will execute in a given quarter to move toward the objective.
It sounds like a small addition, but it changes the planning conversation significantly. An objective tells you what you’re trying to accomplish. A goal tells you how you’ll know if you got there. An initiative tells you what you’re actually doing about it.
For example, an objective might be to leverage AI more effectively in your product. The goal might be measured by the number of users engaging with AI features and the frequency of that engagement. But without an initiative, you still don’t know what the team is building, who’s working on it, or what the scope looks like. The initiative fills that space. It might be: build and launch an AI-powered reporting summary feature for the top 20 percent of active users by the end of the quarter.
Now you have something you can resource, scope, assign, and track. You know what done looks like. You know what team members you need to pull from different parts of the org. And you have a clear enough definition of the work that you can evaluate mid-quarter whether it’s on track, whether the scope needs to change, and whether this is still the right thing to be spending time on.
Why Narrowing the List Matters
One of the hardest parts of this framework isn’t adding the initiative layer. It’s limiting the number of initiatives to the ones that actually matter.
Most leadership teams, when given the chance to define what they want to accomplish, will produce a list that’s too long. Everything feels important. Every function has something they want to build or fix or improve. And because each item on the list seems reasonable in isolation, it’s easy to convince yourself that all of it is doable.
It usually isn’t. Caputa’s guidance for companies in the 50 to 250 employee range is to keep the initiative list at three to five items. Not ten. Not eight. Three to five, across the entire organization, for a given quarter or planning period.
That constraint forces real prioritization. It requires leadership to have honest conversations about what actually moves the business and what can wait. It surfaces resource conflicts that would otherwise get papered over with optimistic assumptions. And it produces a shorter list that people can actually remember, align around, and make progress on.
Reevaluating Every Quarter
The other thing the OGI framework builds in is a regular evaluation cycle for the initiatives themselves. Objectives and goals tend to be relatively stable across a year. Initiatives should be questioned every quarter.
Is this still the right initiative? Has something changed in the market, the data, or the business that makes a different initiative more valuable? Should this be killed, merged with something else, scoped differently, or doubled down on based on what you’re seeing?
This isn’t a sign that the planning failed. It’s the point. The framework is designed to give you a common focus and then build in the regular checkpoints to make sure that focus is still correctly aimed. A team that’s executing against an initiative that no longer makes sense is wasting exactly the kind of scarce capacity that the framework is designed to protect.
Where OKRs and Data Connect
The OGI framework doesn’t replace the need for good data. It depends on it.
Setting realistic goals requires knowing where the business actually is. Forecasting what’s achievable in a quarter requires historical data on what similar initiatives have produced. Evaluating whether an initiative is on track mid-quarter requires the kind of leading indicator visibility that the inputs-outputs-outcomes framework provides.
For companies that have both in place, the combination is powerful. Strategy shapes the objectives. Data informs the goals. Initiatives define the work. And the metrics tell you early whether the work is producing the results you expected.
For companies that have one but not the other, the planning process tends to either lose touch with reality or lose touch with execution. The data without the framework produces analysis that doesn’t connect to action. The framework without the data produces plans that aren’t grounded in what’s actually possible.
Getting both right is the work. But it starts with recognizing that objectives and key results, on their own, leave a step out.
Listen to the full podcast episode here.