OKRs for small teams, without the ceremony

OKRs have a reputation problem among small teams, and it is largely deserved — but not for the reason people usually give. The objection is normally "we are too small for that much process". The real issue is that almost all the available advice was written by and for large organisations, where the framework is solving a coordination problem that a fifteen-person team simply does not have.

Strip away the parts that exist to coordinate a thousand people and something genuinely useful remains. This guide is about what that is.

What OKRs are actually for

An objective is the outcome you want, stated in a way that a human finds motivating. A key result is how you will know you got there, stated as a number you can check without arguing about it.

That is the whole idea, and the reason it works is that each half fixes the other's weakness. "Make the product feel fast" is motivating and unmeasurable — reasonable people will disagree at the end of the quarter about whether it happened. "Reduce p95 page load to under two seconds" is measurable and, on its own, faintly depressing. Together they say what you are doing and how you will settle the question.

Everything else — cascading trees, weighted scoring, confidence percentages, quarterly grading rituals — is coordination machinery for organisations where the person setting the goal and the person doing the work have never met. If your whole team fits in one room, you can skip essentially all of it.

Skip these

Cascading. In large companies, each level of the hierarchy derives its OKRs from the level above. At fifteen people you have one level. Write three to five company objectives and let anyone's work link to any of them.

Scoring and grading. The 0.0–1.0 scoring ritual, and the folklore about 0.7 being the ideal score, exist to stop people sandbagging targets in an environment where OKRs are informally tied to performance reviews. If you are not doing that — and you should not be — you do not need the counter-measure. Look at whether the number moved.

Individual OKRs. These reliably become a to-do list with extra steps, and they push people toward work they can claim credit for over work the team needs. Keep objectives at company or team level.

Confidence percentages. Asking someone to state weekly confidence in hitting a target produces a number that reflects mood and social pressure more than reality. Look at the underlying key result instead.

Write key results people can check

This is where small teams most often go wrong, and there are two opposite failure modes.

The first is the unmeasurable key result: "improve onboarding", "ship a great mobile experience". These are objectives wearing a key result's clothing, and at quarter end you will have a conversation rather than an answer.

The second is more insidious: the technically measurable but meaningless key result. "Ship 12 features" is a number you can check, and it is also a number that will make your team ship twelve small features instead of three important ones. Once you attach significance to a count, you have created an incentive to produce the count.

A key result worth writing has four properties:

That last one prevents most end-of-quarter arguments. Decide before you start that the number comes from a specific dashboard, and the debate about whose figure is correct never happens.

Weak: Improve customer onboarding Better: Increase 7-day activation from 34% to 50% (source: product analytics)

Weak: Reduce support load Better: Cut tickets per 100 active accounts from 18 to 12 (source: helpdesk monthly export)

Three objectives, maximum

The most common failure among small teams is having eight objectives. This feels ambitious and functions as having none, because eight priorities is a statement that you have not decided.

For a team of fifteen, three is usually right. One is often better than you would think — if there is genuinely one thing that matters this quarter, saying so is more useful than manufacturing two companions for it.

The test is subtractive. For each objective ask: if we hit every other objective and missed this one, would the quarter have been a success? If yes, it is not an objective. It is a project, and it can live as ordinary work.

Connect them to the work, or do not bother

Here is the part that determines whether the exercise survives past week three.

The standard failure is structural, not motivational. Objectives live in a document. Work lives in a task tool. Keeping them in sync is a manual job with no natural trigger, so it gets done in week one, skipped in week four, and reconstructed in a panic before the quarterly review — at which point the percentages are invented and everybody quietly knows it.

There are two ways out.

Reduce the linking cost to near zero. If connecting a task to an objective is a single tag applied once, at the moment the task is created, people will do it. If it requires opening a separate system and updating a progress field, they will not, and no amount of reminding will change that. This is the model TIBLR uses: tag the task once and objective progress follows from completing the work.

Review it somewhere you already are. A separate monthly OKR review meeting competes for calendar space and loses. Put objective progress in front of the team during a meeting that already exists — your weekly sync is the obvious candidate — and the check takes thirty seconds and actually happens.

The most useful signal is an objective with no work against it

If you take one thing from this guide, take this.

At any point in the quarter, look at each objective and ask what work is currently linked to it. An objective with nothing underneath is not behind schedule — it has been abandoned, and nobody has said so out loud. That is enormously valuable to know in week five and useless to discover in week twelve.

It is also a much better question than "what percentage complete are we?", because it has an unambiguous answer and it points directly at what to do next.

A reasonable quarter

• Week 0 — Agree two or three objectives. Write two or three key results each, with baseline, target, unit, and source.
• Weeks 1–12 — Link tasks to objectives as they are created. Glance at progress during your existing weekly sync. Notice objectives with no active work and either resource them or drop them.
• Week 12 — Look at whether the numbers moved. Write down what you learned. Do not grade anyone.

That is the whole practice. It fits in a page because at your size it should.

---

TIBLR keeps objectives and key results attached to the tasks that move them, so progress is a by-product of the work. Free to use.