The OKR trap at pre-seed

A founder I work with showed me her OKR doc. Fourteen objectives across six weeks. Four had been updated yesterday, six the previous Friday, the rest were silently aging. The team had a standup, a weekly review, a monthly OKR retro, and a quarterly OKR reset. The team was sprinting at four directions and shipping in zero.

When I asked her what the company was doing this quarter, she gave me a fluent two-minute answer that did not name a single thing the team had shipped. When I asked her what the team thought the company was doing, two of them said something different from her, two said something different from each other, and one said "honestly, I'm just trying to keep the website up."

The OKR system was not the problem. The OKR system was a tool from a different shape of company being applied to a shape of company that does not yet have its own shape.

Why OKRs work at scale

OKRs were built for Google in the late 1990s. The shape of the problem was that Google had ten thousand smart engineers, hundreds of competing priorities, and a coordination cost between teams that was rising faster than the team could absorb. OKRs solve a coordination problem. They are an org-design artefact.

At ten thousand engineers, OKRs let two distant teams know they are working on the same objective, give the executive a way to surface conflict early, and create a quarterly forcing function that aligns budget, hiring, and roadmap. The cost of running the OKR system, which is real, is dwarfed by the cost of the coordination chaos it prevents.

At ten engineers, the coordination problem does not exist. There are no distant teams; there is the standup. The cost of running the OKR system is no longer dwarfed by anything. It just shows up as friction.

The four patterns of OKR misuse at pre-seed

When founders import OKRs into a company that is too small to need them, the misuse falls into four patterns. The patterns are easy to recognise once you can name them.

1. Proxy goals

An OKR like "increase brand awareness by 30%" is not an objective. It is a proxy for an objective the team has not yet articulated. At pre-seed, every proxy goal is a sign that the underlying bet is not yet legible enough to commit to. The team will sprint at the proxy and then discover, three months later, that the proxy did not move the thing the proxy was a proxy for.

The fix is to delete the proxy and write down the bet underneath it. Sometimes the bet does not survive being written down, which is the most useful possible outcome.

2. Vanity metrics

OKRs that name follower counts, signups, page views, or any metric whose scaling is loosely coupled to revenue or retention will quietly drift the team toward optimising the metric rather than the company. The team will hit the OKR and the company will be no closer to the next milestone.

The pre-seed test for whether a metric is vanity is simple. Ask whether the founder would still ship the work if the metric were not being measured. If yes, the work is real and the metric is decoration. If no, the metric is steering the work, and the work is probably wrong.

3. Distributed accountability

An OKR with three or more owners has zero owners. At pre-seed, the founder owns everything the company has not yet successfully delegated. Pretending otherwise creates a thin layer of process that obscures the founder accountability without removing it. The founder still gets the call when the OKR slips. The team just gets to feel the slip first.

The fix is one owner per work item, full stop. Co-ownership is a scale-stage tool. At pre-seed, it is delegation theatre.

4. Quarterly cadence over weekly cadence

The OKR's quarterly rhythm makes sense at scale because three months is the unit of time over which a thousand-person org can plausibly turn the wheel. At pre-seed, three months is two pivots and a feature ship. By the time the quarterly retro lands, the OKRs are about a company that no longer exists.

The fix is to drop the quarterly cadence and replace it with a weekly one. One thing the company is committing to ship this week. One thing the company is committing to decide this week. Read out on Friday. Then the next week.

What to use instead at pre-seed

At pre-seed, you have one OKR. It is the bet. Prove it or kill it. Everything else is detail.

Replace the OKR document with three artefacts.

• A one-line bet. "By July, we will know whether mid-market dental practices will pay $79/month for the appointment-reminder workflow." One sentence. Pinned to the team channel. Re-read at the start of every weekly review.
• A kill-criteria template, written before the work starts. The threshold below which the bet is killed, the date the threshold is read, the action that follows. The kill-criteria is what gives the bet teeth.
• A weekly close-out artefact. Three lines per person on Friday: what shipped, what slipped, what I learned. The artefact replaces the OKR retro and the standup status update at once.

When to introduce OKRs (and when to skip them)

OKRs become useful around fifteen to twenty people, when the founder can no longer be in every conversation and two distant teams are about to start working on adjacent problems without a shared frame. At ten people, the standup carries the load. At twenty, OKRs are a useful coordination layer. Below ten, they are friction wearing the costume of discipline.

There is no virtue in adopting OKRs early. The companies that ship best in the first two years almost never use them. The companies that ship best after the first hundred people almost always do. Both are right; the question is which company you are.

The companion template

The kill-criteria template on the resources page is the artefact that replaces the OKR system at pre-seed. Bet, metric, threshold, date, action. One page per initiative. The discipline is in writing down the kill criteria before the work starts; the rest of the system follows from it.

OKRs solve the problem of coordination across teams that cannot see each other. At pre-seed, the team can see each other. The OKR is not a smaller version of the system; it is a different artefact for a different problem.