25  Operating Principles for a Team of Few

Everything in this book was written from, and for, a constraint that is becoming the norm: serious regulated software built by a team you could seat at one table. A small team cannot out-work large ones; it can only out-decide them. This chapter is about the operating system — not code, but habits — that lets few people run a trust product without becoming its bottleneck.

25.1 Decide in writing

Small teams drown not in work but in undecided work. The countermeasure is cheap: every consequential decision — a contract change, a rebuild instead of an absorption, a scope cut — gets a short record: context, options, choice, consequence. Not a wiki graveyard; a numbered sequence a newcomer can read in an hour to understand why the system is shaped as it is. The test of a decision record is whether, eighteen months later, it still explains the shape — and whether the team can tell when reality has outrun it and a new record is due.

25.2 Let the system remember

A team of few cannot afford knowledge that lives only in heads. The habit that pays highest interest: every hard-won operational fact — the quirk of a data feed, the reason a port is pinned, the signature of a failure mode — lands in a durable file at the moment it is learned, structured so the next agent (human or machine) can act on it. The grimmer version of the same habit: every incident produces a one-paragraph entry — symptom, root cause, fix — indexed so the next incident is a lookup rather than a rediscovery. Teams that do this compound; teams that do not re-solve their third-biggest problem annually.

25.3 Ship on a cadence, verify on every ship

Small teams must release constantly — big-bang releases are where trust products go to die, because each release becomes a qualifiable event too heavy to repeat. The trust layer itself is the enabler here: when every render verifies against locked references, frequent shipping is safer than rare shipping, because drift is caught at the gate instead of accumulating in secret. Cadence then becomes a quality instrument: something ships every week, and the comparison machinery is the review that never gets tired.

25.4 User-centric is a scheduling policy, not a poster

“User-centric” becomes real when it decides the calendar: the next unit of work is whatever unblocks an actual user’s actual task, traced to a specific person if you can name one. Features that serve no nameable user wait. This is doubly true for a trust product, whose users are skeptics by profession — every unit of friction removed for one QA reviewer is a story that reviewer will retell internally better than any marketing page.

25.5 Keep the identity narrow

The final habit is the hardest: decline adjacent glory. New analysis types, new therapeutic areas, new dashboards — the adjacent opportunities are endless, and each one dilutes the one thing a small team can hold: the narrow claim, held absolutely. “We industrialize the evidence behind clinical outputs” is a sentence a market can remember and a team of few can be true to. The moment the team’s answer to “what do you do?” needs a slide, the moat has started filling in.

None of these habits are heroic. That is the point. In regulated software, heroics are a smell — evidence that structure failed somewhere upstream. The quiet team with contracts, records, gates, and a narrow promise will, over any horizon that matters, outlast the brilliant one without them.

The test. The last one is reflexive: could a competent stranger take over this book’s system tomorrow, guided only by what the system and its records say about themselves? If yes, the team is free to build what only they can build. If no, the team is the system — and teams are mortal.