Three weeks into Q1, a founder I work with opened the team's OKR doc and found 11 objectives. Two of them contradicted each other. Nobody had opened the file since week one. That's not an OKR problem — that's what happens when you copy a template from a company with 400 employees and paste it onto a team of nine.
Setting quarterly OKRs for a startup team isn't a formatting exercise. It's a bet on what the next 90 days are actually for. Get it right and the quarter has a spine. Get it wrong and you've built a document nobody reads and a ritual everybody resents. Below is the process I've landed on after running this with small teams across several quarters, including the ones where it fell apart.
Key takeaways
- Cap the quarter at one company objective and three per team — startups die from too many priorities, not too few.
- Run a dated cadence: framing week, freeze, weekly check-in, mid-cycle review, grading. The calendar does more work than the template.
- Freeze your key results, not your objective. Change the "how" freely; changing the "what" needs a written reason.
- Derive quarterly OKRs from the annual ones by picking one annual objective per quarter, not by splitting every annual KR into three.
- Score at the end, and score honestly. A quarter where everything hit 1.0 usually means you aimed too low.
Quarterly OKRs for startup teams: a 90-day operating system, not a planning document
The 90-day window is the whole point. Twelve months is long enough to carry a fantasy; a week is too short to move a real metric. Ninety days is roughly the distance between "we believe this" and "we know this" — long enough to run an experiment to completion, short enough that you can't hide behind "next year."
What most startup teams get wrong is treating the OKR doc as a deliverable. It isn't. It's the artifact left behind by a conversation about tradeoffs. If the conversation didn't happen, the document is decoration.
Why startup OKRs can't be a copy-paste from a large company
In a big org, OKRs mostly coordinate: they stop team A from building something team B already built. In a startup of 8 to 30 people, coordination is the cheap part — everyone sits in the same room or the same call. The expensive part is saying no.
So the OKR set has to do a different job. It has to make the tradeoff explicit and public: this quarter we are chasing retention, which means we are deliberately not chasing new logos. Writing that down is uncomfortable. It's also the entire value.
How to get from annual OKRs to quarterly ones without drowning
I've seen the cascade done badly more times than well. The bad version: take the annual objective, split each key result into four, assign one slice per quarter. It looks tidy. It produces quarters where you're chasing 40% of a metric with no theory of how the 40% gets built.
Do this instead:
- List your annual objectives. Should be two, maybe three.
- For each quarter, pick one annual objective as the primary. Not a slice of all of them — one.
- Write fresh quarterly key results that describe what would have to be true at day 90 for that annual objective to stay plausible.
- Note in one line what you're deferring. "Pricing rework moves to Q3." Write it down so nobody re-litigates it in week six.
The deferral line is the part people skip, and it's the part that prevents the mid-quarter drift I'll get to below.
The quarter has a calendar, and the calendar is the method
Here's the gap I keep running into: plenty of advice tells you to "review OKRs weekly" and stops there. Nobody tells you what actually happens on which week, so the first check-in gets moved, then cancelled, then quietly forgotten by week four.
Fix the dates before the quarter starts. This is what has worked for small teams:
| When | What happens | Who owns it |
|---|---|---|
| Week 0 (last week of prior quarter) | Drafting session. Each team brings a proposed objective plus three key results, written before the meeting, not during it. | Team leads |
| Day 1–2 of the quarter | Publish and freeze. Doc goes live with an owner per KR and a baseline number for each. | Founder / ops |
| Every Monday, 20 min | Check-in. Each KR gets a one-line status: on track, at risk, blocked. No slides. | Rotating facilitator |
| Week 6 | Mid-cycle review. Are the key results still the right ones? Decide whether to swap, and write why. | Team leads + founder |
| Last two days | Grading, then a short retro on the process itself. | Everyone |
Two things about this table matter more than the rest. First, the drafting session happens before the quarter starts, so day one is execution, not negotiation. Second, the mid-cycle review is a scheduled slot, not an emergency. When the review is on the calendar from the start, changing a key result stops feeling like a failure and starts feeling like maintenance.
What exactly should you freeze, and what stays loose?
Freeze the key results and their baselines. Keep the objective and the tactics loose.
The reasoning: a key result without a fixed baseline number is unmeasurable, and unmeasurable key results get graded by vibes at the end of the quarter. But the tactics — the experiments, the campaigns, the specific features — those should change constantly. If your key result is "increase weekly active teams from 120 to 180" and by week three you realize the referral loop is dead, you should kill it on a Tuesday and try something else. That's not moving the goalposts. That's working.
How do you handle a priority shift without demoralizing the team?
Real talk: in a startup, priorities will shift. A big customer shows up, a competitor ships something, a channel dries up. Pretending otherwise is how you get an OKR process people quietly sabotage.
What I use is a simple rule with two doors:
- Change the tactic: no permission needed, no meeting. Just tell the weekly check-in.
- Change a key result: allowed at the mid-cycle review, or in an emergency session with the founder. Requires one written sentence: what changed, and why the old KR is no longer the right measure.
- Change the objective: once per quarter, maximum. If you're doing it more, the objective was wrong when you wrote it, and that's a diagnosis worth sitting with.
That last point is where I'd push back on the common advice to stay maximally flexible. Unlimited flexibility isn't agility, it's the absence of a decision. Teams don't get demoralized because a key result changed once with a reason written down. They get demoralized when the target moves every fortnight and nobody explains why.
Writing OKRs a startup team will actually use
A useful test before you publish: can a new hire read each key result and tell you, without asking, whether it's on track? If not, rewrite it.
Outcome, not output — and the one exception
Almost every bad startup OKR I've seen is an output dressed as an outcome. "Ship the new onboarding flow." That's a task. "Reduce time-to-first-value from 6 days to 2" is a key result — it forces you to discover whether shipping the flow actually helps.
The exception: for a team doing genuinely early exploration — say, a first attempt at a new segment — a learning key result is legitimate. "Run 12 customer interviews and produce a written position on whether segment X is worth a Q2 bet." That's measurable, it produces a decision, and pretending you can forecast a conversion rate on an unbuilt product would be worse.
How many OKRs should a small startup team have?
One objective per team, three key results underneath it. Company-wide, that usually means one top-level objective and three to five team-level ones.
I've tested higher numbers. One quarter we ran five objectives for a team of six people. The result: every objective got about 20% of the attention it needed, nothing crossed the finish line, and the retro was grim. Since then I've treated a fourth key result as a signal that something needs to be cut, not added.
How should you score at the end of the quarter?
Score each key result from 0 to 1 against the baseline you froze on day two. Then read the pattern, not the average:
- All 1.0: you aimed too low. Raise the bar next quarter.
- Around 0.6–0.7 across the board: healthy. Stretch goals that mostly land.
- Under 0.4 on everything: either the quarter was chaos, or the key results weren't measurable in the first place. Check which before you blame the team.
- One at 1.0, two at 0.2: the classic sign that the team quietly picked a favorite and let the rest rot. Worth a direct conversation.
And grade the process too. Did the weekly check-ins actually happen? Did anyone change a key result without writing down why? Two questions, five minutes, and it's the difference between an OKR habit and an OKR artifact.
What I got wrong the first few times
My early mistake was writing OKRs for the team instead of with them. I'd draft something clean and logical over a weekend, present it on Monday, and wonder why engagement was flat. Of course it was — nobody had any stake in the numbers.
The second mistake was subtler: I let the mid-cycle review slide when things got busy. Miss it once and the doc becomes historical fiction. The teams that keep their OKRs alive are the ones where the review is a fixed appointment, boring and unmissable, like a dentist visit.
Which is really the whole argument. Quarterly OKRs for a startup team don't work because the template is good. They work because they force a small group of people to agree, out loud and in writing, on what the next 90 days are for — and then to look at that agreement every week until it's either done or honestly abandoned. The document is just the receipt.
So the question worth sitting with isn't "are our OKRs well written." It's sharper: if you deleted the doc tomorrow, would anyone on the team notice by Friday? If the answer is no, you don't have a formatting problem to fix. You have a conversation you've been avoiding.
