At what team size does alignment start breaking?

There's no magic number, but the mechanism is mechanical: pairwise communication paths grow as n(n-1)/2, so five people have 10 paths and twenty have 190. Somewhere past the point where everyone shares one room and one conversation (often around 10 to 20 people, or the first remote hire), ambient alignment quietly stops working.

Don't more meetings solve this?

Meetings re-broadcast context to whoever attends, once. They scale linearly with calendar time and decay immediately: the next decision made after the meeting is unshared again. A written decision record scales with readers instead of speakers, which is the property you need when the team is growing.

What's the minimum viable alignment practice for a startup?

One rule: when a decision will constrain how someone builds or plans later, the person who made it writes four lines (the call, the reason, what was rejected, who agreed) in one agreed place. Fifteen minutes a week, total. Everything heavier can wait until it hurts.

How do small teams stay aligned as they grow?

Small teams stay aligned for free: everyone hears everything. That stops around the size where communication paths outnumber people. The teams that survive growth switch from repeating context to recording it: decisions written at the moment they're made, with reasons attached, and delivered to whoever touches the work next.

At five people, alignment is free. Everyone sits in the same conversations, decisions are made in earshot, and the context of every call is ambient. Founders often think they have an alignment culture. Mostly they have an alignment geometry, and geometry doesn't scale.

Why growth breaks it

Fred Brooks did the arithmetic in The Mythical Man-Month: pairwise communication paths grow as n(n-1)/2. Five people are 10 paths. Twelve are 66. Twenty are 190. The all-hear-everything property that made the early team feel telepathic doesn't degrade gracefully. It crosses a threshold where most decisions are made out of most people's earshot, and then the misalignments start compounding quietly.

Three things hit at once. New hires arrive after the formative arguments, so they inherit conclusions without reasons; the hallway that used to carry context stops reaching them. The first remote hire or second office breaks the geometry outright. And the people who hold the most context become bottlenecks, answering the same questions on repeat while their calendar dissolves.

The instinctive fixes (more standups, more all-hands, more Slack channels) all scale the speaking. The problem is that context now needs to reach people asynchronously, later, without the original decider in the room. That's a recording problem.

What actually works

Write decisions at the moment they're made. Not meeting minutes: decisions. Four lines: the call as one imperative sentence, the reason, the alternatives rejected, who agreed. Written by the decider, in the minute after the call, while the reasoning is warm. The format and the filter are in our decision log guide, and a copyable version with filled-in examples is in the decision log template.

Filter hard. Log only what will constrain someone's future work. A log with everything in it is a log nobody reads; a short one becomes the first place people check, which is the whole game.

Pick one place and make it append-only. A doc, a folder, a tool: one URL the team trusts. If you're choosing, the decision log tools comparison covers the options, and what a single source of truth for decisions needs covers the property that matters more than the tool. Reversals get a new entry pointing at the old one. The record's value is trust, and trust dies the first time someone follows a stale entry.

Aim decisions at the people they affect. Recording without delivery just moves the problem. When a call changes what someone is building, they should hear about it before their next commit, not discover it in review. Undelivered decisions become decision drift.

Start before it hurts. The habit costs almost nothing at eight people and is brutal to retrofit at thirty, because by then the backlog of unwritten context is the culture.

What does this look like in the first week?

Small enough to survive a busy sprint:

Create the one place (a page, a channel plus a doc, a tool) and pin it.
Backfill five to ten decisions that are constraining work right now: the stack choices people keep asking about, the pricing call, anything a new hire got corrected on in review.
Agree on the closing habit: whoever made the call writes the four lines before the thread or meeting moves on.
Point every new hire at the log on day one. Their questions will show you what's missing, which is the same backfill loop described in onboarding engineers with decision context.

If the team already feels the cost (the "didn't we decide this in March?" debates), the mechanism behind it is in why startups forget their own decisions.

Where Lockstep fits

For the product and engineering half of this, where most startup decisions live, Lockstep removes the writing-it-down step that discipline never sustains: it captures decisions from Slack and Notion as they happen, the owner approves in one click, and every human and AI agent touching the code gets briefed before they build. We're at design-partner stage, Apache-2.0 if you'd rather self-host. See how it works.