OKR in Small Teams. Scarcity, Trade-offs and Focus
How to set OKRs with capacity in mind and within the constraints of small teams
This text is an experiment — an attempt to understand what happens when management frameworks built for large organizations are applied to small teams: teams with no spare resources, no buffer roles, and very little room for error.Small teams in a world of big models, frameworks, and approaches are like slightly lost fairy-tale Moomins, who have somehow wandered into Elon Musk’s world, where everything is oversized, not built for humans, all about performance, achievement, and structures and capacity you simply don’t have (and sometimes, thankfully, don’t need).
And when it comes to goal-setting and measurable results, on top of approaches that are not properly adapted for small teams, you also get the whole package of performativity culture, hustle rhetoric, motivational bloggers, and the American (sorry!) Dream thrown in.
As you may have already guessed (which is not strictly necessary when a text begins with fairy creatures and, heaven help us, Musk), we’re going to talk about OKR.
If you don’t know who Moomins are, you absolutely must get acquainted with one of Finland’s main cultural treasures), and if you don’t know who Elon Musk is… it’s fine, and don’t need to know, just spend your time with the Moomins instead.I’m sure you’re already familiar with OKR, but if not, here’s a very short introduction:
OKR (Objectives and Key Results) is one of the most popular frameworks for setting and tracking goals. So far, nothing too complicated, right?
An Objective defines what you want to achieve. It should be meaningful, concrete, and ideally inspiring. A good Objective provides direction and clarity.
Key Results are a deconstruction of the Objective. They answer the question: “How will we measure progress toward that Objective?” They must be specific, time-bound, and measurable. A Key Result is either achieved or not achieved. No other options here.
Objectives can live longer (sometimes across multiple cycles) while Key Results evolve as the work progresses. When the Key Results are achieved, the Objective is considered achieved.
In this article, I won’t go deep into how to set OKRs within the framework or explore all its variations. I’ll skip that lesson (perhaps we’ll return to it in another piece) and focus specifically on small teams.
For the most curious readers, I recommend Google’s excellent “Set goals with OKRs” guide.
OKR in Large vs Small Teams: Key Differences
If you’re subscribed to Make It Work, you know that I’m obsessed with small teams and tend to look at everything through their lens, so we simply have to start with a conversation about the difference between small and large teams in the context of setting and tracking OKRs.
1. Slack and Slackness
When thinking about OKRs, it’s important to remember one key difference:
In large organizations, OKRs broadly manage the allocation of slack.
In small teams, it manages scarcity: of attention, people, money, and technical infrastructure.
In large organizations, OKRs often serve as a mechanism for reallocating excess resources. There is usually slack that allows the organization to invest in growth.
In such a system, the core question sounds like this:
“Where should we direct it (our slack) to accelerate growth?”
OKRs serve as a way to focus ambition and resources and to align which initiatives will receive those resources.
In small teams, the situation is the opposite. Slack is minimal or entirely absent, and operational load almost always exceeds the team’s actual capacity. Here, OKRs do not distribute abundance; they are forced to protect limited attention and energy, creating necessary focus from what little exists.
2. Fewer Objectives and Key Results
If you had six departments, an R&D unit, and several strong senior leaders — go ahead, play with OKRs however you like. But in a small team, it’s irresponsible to create five Objectives, each exploding into multiple Key Results. You simply cannot afford it.
You’re already living in a permanent scarcity loop, with all the unpleasant side effects. For example, Cognitive Tunneling (when your mind focuses only on what’s right in front of you). Why add an entirely new set of priorities on top of that?
In small teams, it’s rational to choose 1–2 Objectives and 2–3 Key Results for each.
Because tracking itself costs energy, resources, and time.
Read more about scarcity effects in small teams ↓
3. Shorter Cycle
Classic OKRs typically operate on a quarterly cycle, and sometimes even a semiannual one. Even if you’re an NGO with annual funding and plans, setting annual or half-yearly OKRs is a luxury you simply can’t afford. I know those November meetings too well — when everyone is reviewing the numbers and suddenly realizes that roughly 70% of what was promised still needs to happen in the remaining two months.
Even a quarter is too long when there is no stable product, no consistent demand, no dedicated strategy function. In three months, the context, the hypothesis, the team, and the priorities can all shift.
Your cycle cannot exceed your ability to predict the environment.
Small teams are often very fast, but their collective memory is rarely institutionalized: no decision logs, no established processes, no documented prioritization principles. This means we quickly forget our actual focus.
That’s why, depending on your context, an OKR cycle — from defining the Objective and 2–3 Key Results to the final decision (continue/adjust/stop) — should last 4 to 6 weeks max. Tracking iterations should happen every 1–2 weeks.
One of the key purposes of such a cycle is to shorten the distance between intention, action, and reality (your results).
4. Capacity Gate
Even though the term Capacity Gate sounds like the name of a boring Netflix sci-fi movie hero (an orphan, half-cyborg with empathy, searching for his creator), it is actually one of the most important questions a small team can ask itself:
Do we realistically have the capacity for this OKR?
There’s no need to over-explain or over-advocate here. If you lead a small team, you already know what this means, and you probably don’t want to wander back into the sleepy valley of unachievable goals.
A proper Capacity Gate forces you to pause before committing and ask the second question:
What are we consciously giving up for the sake of this OKR?
Because in small teams, nothing new comes for free.
Every Objective consumes attention, time, and energy that must be taken from somewhere else. It is important to understand and reflect on what we are willing to give up in order to achieve our goals. We need to be intentional about it and monitor the accumulation of problems caused by trade-offs, revisiting them with each cycle.
It is a safeguard against the hidden accumulation of organizational debt.
What else to Remember When Setting OKRs in small teams
1. Avoid Activity Key Results.
If your KR sounds like “conduct,” “create,” “launch,” or “develop,” it is almost always an action, not a result.
Actions are tasks. Key Results are measurable changes that result from those actions.
Instead of “Conduct 5 interviews,” better say: “≥3 recurring problems identified within the target audience.”
Instead of “Launch a new landing page,” say: “Landing page conversion rate ≥ 8%.”
The difference is simple: activity creates the feeling of progress (and action). Outcome shows whether progress actually happened.
2. Don’t Stretch Too Much
A stretch OKR is an ambitious goal that is intentionally set above a comfortable level of achievability.
The roots of this approach (and its built-in ambition) lead back, of course, to the shiny offices of mega-corporations that “grew out of garages.”
In the Intel/Google version, Stretch means:
A goal with roughly a 60–70% probability of achievement.
If you hit 100%, the goal was too modest.
Partial achievement is not considered a failure.
Stretch is meant to stimulate growth and push teams out of inertia.
In large companies, stretch is a growth tool, an ambitious way of deploying organizational slack.
In small teams, it must be used very carefully, or replaced altogether with an exploration logic aimed at reducing uncertainty rather than maximizing performance. Otherwise, stretch OKRs can lead to chronic underachievement (and declining motivation), burnout, and even metric manipulation.
I’m not arguing against ambition. I’m just reminding us about reality.
3. Rituals without Religion
As my mother used to say, “Danil, just don’t get fanatical.”
Don’t turn OKR into a religion, a grand engine, or a heroic motivator. Especially at the setup stage.
Keep it simple:
One (or two) collective sessions of 60–90 minutes to set the OKRs
15-minute weekly review
30–45 minutes for a retrospective during or at the end of the cycle
4. Owners and the Gatekeeper
Who formulates OKRs?
At the creation stage, in a small team, developing the Objective should ideally be a collective effort. Collective discussion creates alignment and commitment.
What about Key Results?
I suggest that the owners (the people who will handle the hands-on work required to deliver these results) first formulate their own version. Then — discussion, refinement if needed, and formal agreement.
Who is responsible for OKRs afterwards?
The owner is responsible for progress toward the Key Result. Not for doing everything personally, but for driving it forward, monitoring it, escalating issues, and ensuring it does not disappear in operational noise.
Ownership must belong to the person who can meaningfully influence the outcome.
The Gatekeeper (usually the team lead) is the Objective holder.
The Gatekeeper role is to ensure:
clarity of formulation,
alignment with the Objective,
realism,
and a proper capacity check.
The Gatekeeper safeguards the system's integrity.
When You Don’t Need OKRs
OKR is not mandatory. It’s just a tool, and sometimes the most mature decision is not to use it.
You probably don’t need OKRs if:
Your team is smaller than three people, and alignment happens naturally through constant communication.
You don’t have reliable data, because Key Results without measurement quickly turn into performance theater.
There is no stable direction yet, and clarity matters more than metrics.
The team cannot sustain basic discipline. If weekly check-ins already fail, OKR won’t fix culture.
Sometimes frameworks can wait.
Choose. Adapt. Reflect.
Frameworks are not neutral. They carry the assumptions of the environments they were born in.
OKR was shaped in companies with scale, slack, and layers of structure. I keep repeating that small teams are not simply an early stage of growth — they could be a different species.
A small team may one day have the opportunity to choose growth, scale, and the evolutionary path toward becoming one of the “big players.” Or it may not. Or it may choose to remain small and continue developing on its own terms.
And in that sense, the OKR framework (like many others) needs to be rethought, adapted, and, at times, simplified.
If OKRs help you think clearly and make deliberate decisions — keep them. If it adds pressure without clarity — let it go.
Be an ambitious, reflective, and conscious small team of Moomins — choosing your own path and walking toward the goals you set. And don’t be afraid to revise them.
That is the real strength of small teams: the ability to rethink, reflect quickly, and evolve iteratively.
If you’ve read this to the end, thank you!
If you disagree, feel something important is missing, or have anything on your mind, I’d love to hear it in the comments.
Related articles ↓
I like this piece, Danil. It is a good practical adoptation of the framework. Have you tried it in this form in practice?
We abandoned OKRs altogether for a few reasons. But mainly it just became a tail that wagged the dog:
- Quarter is too long for a small team
- Difficulty of coming up with good leading indicators. It felt artificial as we don't have a good idea how these will affect things we care about.
- Most of the leadership team didn't want to "waste" time to do it properly. With OKRs, if you don't do them properly — it is better not to start.
As a result, after a few years kicking this can down the road we abandoned the whole thing. I think it can work, but it requires more focus than most small teams have and buy-in on all levels.
A practical guide showing that OKRs for small teams should prioritize focus, realistic capacity, and short cycles over ambition or scale