The six moves that keep a small team shipping without breaking things.
Fast-moving small teams are not small teams that work longer hours. They are small teams that have decided, on purpose, what not to do. The speed is a downstream effect of a short list of decisions made upfront and then defended — not a virtue that some groups happen to have and others do not.
Here are the six decisions we default to when we start a new engagement. Not because they are fashionable, not because a consultant put them in a slide deck, but because we have watched them survive contact with real projects at three, four, and six engineers. If a claim in the list below sounds ideological, rewrite it in your head as "this is the version we would be willing to defend to a skeptical senior engineer in a conversation" — that is the bar.
One backlog, ruthlessly pruned.
One list, not three. Not a roadmap document plus a Jira project plus a Notion wiki of "someday" items — one surface that the whole team looks at and that a new joiner can read in fifteen minutes. The cost of fragmentation is not the overhead of updating three tools. The cost is that nobody ever sees the whole picture, so nothing ever actually closes.
The list gets pruned weekly. Anything that has not moved in a month either gets done this week or gets killed. We have never had a sprint ruined by a ticket we deleted. We have routinely had sprints ruined by the compounding weight of tickets nobody was going to do but nobody was willing to close either.
A backlog with 400 open items has no backlog. It has a graveyard and an untended garden.
- Age > 30 days and no movement: killed.
- No owner: killed.
- No named user or use-case: killed.
- Opened by someone no longer on the project: killed unless rescued.
Stage the rollout, don't stage the code.
Main is always releasable. Long-lived branches are where quality goes to die — they accumulate context that nobody remembers, drift away from the shape of the codebase, and eventually produce a merge day that nobody wants to be on call for. If a change is too big to put behind a flag and ship today, the change is too big.
Concretely, this means every non-trivial feature goes behind an environment-variable gate, rolls out in steps, and carries its own rollback plan in the commit message. We would rather ship ten one-line flag toggles than one 2,000-line merge. The work that matters is the staging of the rollout, not the staging of the source.
- Feature-Flags behind an env var, default off.
- Dark launch: code on, users off, telemetry on.
- Sampled rollout (1%, 10%, 50%, 100%) with explicit exit criteria at each step.
- Auto-rollback on error-rate regression without waiting for a human to approve it.
Weekly demos, not weekly updates.
The demo is the medium. A written status update is a downgrade — it reads well, it takes an hour to write, and it hides the truth that nothing is actually working on a screen yet. If there is nothing to demo this week, that is the information. Say it, out loud, to the whole team. The discomfort is the signal.
We have had weeks where the demo was "we deleted 600 lines of dead code and closed three bugs; here is the diff." Those are good weeks. They do not photograph well for a stakeholder slide deck, but they are the weeks after which the next feature ships on a codebase that is actually easier to work in. A team that can demo a deletion with a straight face is a team that is going to ship.
Buy the tools that replace a person, skip the tools that replace a meeting.
Observability, CI runners, error trackers, log search, a fast local dev loop — worth every euro. These tools compress a role: the person who would otherwise spend a morning grepping production logs, the person who would otherwise wait forty minutes for a test run, the person who would otherwise find out about a regression from a customer. Pay for them, pay to upgrade them, do not apologize for the line item.
Another project-tracking tool, another Slack integration that posts status to a channel, another dashboard that aggregates the four dashboards you already have — not. These tools do not replace a person. They replace a ritual, and the ritual was cheap. The invoice is not.
The best tools compress a role. The worst tools compress a ritual.
Write ADRs, not design docs.
An Architecture Decision Record is five to fifteen lines and captures why. A design doc is eight pages and captures how the problem looked at 4pm on a Thursday when we were tired. Six months later, the ADR is still readable and still tells you the trade-off; the design doc is a museum piece that disagrees with the code it was supposed to describe.
We keep ADRs in the repo, next to the code they constrain, under four fixed headings. Four headings, not twelve. The discipline is in the brevity: if you cannot say why you made a decision in a paragraph, you have not finished making the decision.
- Context — what forced the decision, in one paragraph.
- Decision — what we chose, in one sentence.
- Consequences — what this makes easier and what it makes harder.
- Revisit when — the concrete condition that would flip this.
Two-person reviews on everything that touches production.
Two reviewers, not four. Two is the minimum that catches the class of mistake a single pair of eyes misses. Four dilutes responsibility — everyone assumes somebody else is reading carefully, and nobody is. The worst code reviews we have seen were on Pull Requests with six approvals and a bug that shipped the following Monday.
The review has to be a real review. Pair programming counts — two people, one keyboard, one decision trail. A rubber-duck thread in Slack where someone walked through the change before opening the Pull Request counts. A GitHub comment that reads "LGTM" twelve seconds after the Pull Request opened does not count, has never counted, and the team that pretends it does will find out which production incident it caused.
These six decisions are not hacks. They do not produce a heroic sprint that makes the team look good for a quarter. They compound. A small team that runs this way at two years out-ships a larger team that did not commit to any of it, because every week the discipline buys another week of clean runway instead of another week of debt.
Speed in a small team is a discipline, not a talent.