lockstep

Why do startups forget their own decisions?

Because early-stage memory is people, not records. Small teams run on transactive memory (knowing who knows what), and it works until someone leaves, the team doubles, or six months pass. Decisions made at speed rarely get written down, so the company re-decides them later, sometimes differently, usually expensively.

By Naman Jain

Every founder has lived this meeting: forty minutes into a debate, someone says "wait, didn't we already decide this in March?" Nobody's sure. Nobody can find it. The team decides again, slightly differently this time, and two systems now embody two versions of the same call.

Why it happens

The psychologist Daniel Wegner called the mechanism transactive memory: small groups don't share knowledge, they share an index of who knows what. One founder holds pricing history, an early engineer holds the architecture calls, and everyone knows whom to ask. For a team of eight in one room, this is genuinely efficient, which is exactly why nothing gets written down.

Then the assumptions break. Someone leaves, and their partition of the company's memory leaves with them: the decisions, and the reasons behind them, which are the part you can't reverse-engineer from the code or the deck. The team doubles, and new people can't query a memory system they're not indexed into. Or simply: six months pass, and human recall of a fast decision made under pressure degrades into confident fiction.

Startups are also uniquely biased against recording. Speed is the culture; writing feels like tax. Pivots invalidate old decisions silently, so even people who were present aren't sure which calls still stand. And decisions happen everywhere (a Slack thread, a call, a whiteboard), so there's no single stream to reconstruct even in principle.

The cost isn't nostalgia. It's re-litigation: re-running settled debates from scratch, re-exploring alternatives that were already rejected for reasons that still hold, and shipping contradictions when two halves of the team remember the same decision differently. That last one is decision drift, and it compounds as the team grows.

What actually works

Write four lines at decision time. The verdict as one imperative sentence, the reason, the rejected alternatives, who agreed. One minute, while the reasoning is warm: memory of why decays much faster than memory of what. The format, and the filter for what's worth logging, is in our decision log guide.

Record the rejected alternatives especially. This is the field that kills re-litigation. "Considered usage-based pricing, rejected because our billing can't meter it yet" turns next quarter's forty-minute debate into a thirty-second check of whether the constraint still holds.

Give temporary decisions a review date. "Just for the pilot" without a date becomes permanent by default. A date and an owner turn forgetting into a scheduled event instead of a silent one.

Supersede, never delete. When a pivot invalidates a decision, write the successor entry and point it at the original. The trail of what governed the work, and when, is what keeps the record trustworthy after three pivots.

Backfill on collision. Every "didn't we already decide this?" is the system telling you exactly which entry is missing, at the cheapest moment to write it: the people who remember are already in the room.

Where Lockstep fits

Lockstep exists because the writing-it-down step is the one that startup speed always sacrifices. For product and engineering decisions, it does the capture automatically, from Slack and Notion where the decisions actually happen, and the owner approves each record in one click, so the company's memory stops depending on who's still employed. Design-partner stage, Apache-2.0. See how it works.

Related questions

Is re-litigating old decisions always bad?
No. Revisiting a decision because the constraint behind it changed is healthy. The waste is re-litigating blind: nobody remembers why the call was made or what was already tried, so the team re-runs the whole debate from scratch and sometimes lands on an alternative that was rejected for reasons that still hold.
Do we really need a decision log at eight people?
Eight people is the cheapest you'll ever get the habit. You have few decisions, everyone knows the context, and writing four lines per real decision costs minutes a week. At thirty people you'll need the log and also face a two-year backlog of unwritten context that no one can reconstruct.
What kinds of decisions do startups forget first?
The deliberately temporary ones ('just for the pilot') that quietly become permanent, and the rejected alternatives: six months later someone proposes the thing that was already tried and ruled out, and nobody can remember why it lost.

Keep reading