Founding Team Operating Model

1. When This Strand Applies

The rest of these documents describe a sprint-based operating model: a two-week cadence, refinement a sprint ahead, planning on the Monday, a demo on the Friday. That model is right from roughly one squad upwards, and Team Structure describes how to compress it as headcount falls.

Below about five people, compression stops being enough. A team of three does not have a planning problem, a capacity-forecasting problem, or a cross-squad dependency problem. It has a finishing problem: too many things started, not enough shipped, and nobody outside the team able to tell which is which. Sprint ceremony does not solve that. It mostly adds overhead to a team whose entire working memory fits in one conversation.

This strand is the same operating model with a queue instead of a cadence. Work moves continuously from backlog to done, pulled one item at a time, limited by work in progress rather than by a sprint boundary. The discipline moves from “what did we commit to for the next two weeks?” to “what is the next most important thing, and why is there more than one thing in flight?”

	Sprint model	This strand
Team size	5+ (one squad or more)	1–4
Unit of commitment	The sprint	The card
What limits work	Sprint capacity	WIP limits
Planning	Sprint planning, every two weeks	Ordering the queue, continuously
Forecasting	Velocity and sprint history	Cycle time and throughput
Ceremony	Planning, refinement, mid-sprint check, demo, retro	One weekly queue review, one monthly retro
Where status lives	The sprint board plus the ceremonies	The board, exclusively

What is identical in both: work is tiered before it starts. Someone owns the problem and someone owns the solution, and they are not the same person. Changes that carry real risk get a second pair of eyes, by a written standard rather than by how the author feels on the day. Decisions get written down. Trunk-based development behind feature flags, with CI as the gate. A named person is accountable for production at 2am. None of that is sprint machinery, and none of it gets cheaper to skip because the team is small.

What this strand is not is permission to work without process. A board with three lists and no definition of ready is a shared to-do list. It will feel faster for about six weeks, and then nobody will be able to say what is in flight, what is blocked, why the thing that shipped is not what was asked for, or where the decision to build it that way was taken. Lighter ceremony, same discipline.

Nor is it a rulebook to be obeyed when it is unhelpful. Most of what follows exists to stop drift rather than to stop judgment, and the document says plainly where the pragmatic exception lives: not everything needs a second pair of eyes, and nobody should sit idle on a blocked card while useful work waits. What is not negotiable is that the exception is taken deliberately, on purpose, and left visible on the board. A rule bent with a reason written next to it is this model working. A rule bent silently, repeatedly, is how a team ends up with nine things in flight, none reviewed, and no idea when that happened.

2. The Board

This strand assumes Slipdock as the orchestration layer. Not because the ideas need it (flow is older than any tool) but because at this size the board is not a reporting artefact. It is where the work is actually dispatched, to people and to agents, and that only works if the board is precise enough to execute from. The mechanics below are Slipdock’s, and the vocabulary (lists with a category, epics with subcards, flags, dependencies, automations, a wiki alongside) is used deliberately.

One Board Per Stream

One root board for the product. Not one per person, not one per quarter. If there is genuinely a second stream of work with its own stakeholders and its own order of priority (a services business alongside the product, say), that is a second board, and it is also the first sign you are outgrowing this strand.

Lists

A list’s meaning comes from its category (todo, doing, done, dropped), not its name. The default set:

List	Category	What it means
Intake	`todo`	Raw and untriaged. Anything anyone thought of, asked for, or complained about. Not work yet.
Backlog	`todo`	Triaged, tiered, ordered. Will probably be done, is not next.
Next	`todo`	Ready. Shaped well enough that whoever (or whatever) takes the top card can start without asking a question.
Doing	`doing`	In flight, with a named owner.
Review	`doing`	Finished by its author, waiting on a second pair of eyes. Still in flight. Not every card passes through it: see what does not need review.
Done	`done`	In production, verified, flag on.
Dropped	`dropped`	Deliberately not doing, with the reason on the card.

At one or two people, merge Intake into Backlog and keep the other five. Review is the one list people try to drop and the one that must not go, even though plenty of cards will bypass it: it is where “somebody other than the author confirms it works” physically lives for the work that needs it.

Next is the plan. There is no other plan. The order of that list is the answer to “what are you working on?” for anyone who asks, including a board member, including yourself on a Monday morning.

Epics and Subcards

A top-level card is an epic: an outcome, named as an outcome (“Self-serve onboarding”, not “add signup form”). It carries the priority, the due date if there is one, the tier, and the discussion. It is never worked directly.

A subcard is a task: one sitting, one owner, one sentence to describe. This is what moves across the board and what gets closed. A step too small to deserve a card is a checklist item on one.

Two levels is the norm. Three means the epic is really a programme, which happens, and which at four people should make you suspicious. Four levels means the board is being used as a to-do list and wants flattening.

The mapping to product tiers is direct:

Tier	Shape on the board
Tier 1: Feature	A single card. No epic, no ceremony.
Tier 2: Enhancement	An epic with subcards, each one independently shippable behind a flag.
Tier 3: Initiative	A one-pager in the wiki first, a go/no-go decision recorded, then one or more epics. At this size a Tier 3 is a company decision, not a board item, and it should never appear as a single card called “the new platform”.

WIP Limits

This is the control that replaces sprint commitment. It limits work in flight rather than work per fortnight, and exactly one line of it is absolute.

	Value	Kind
Everything you are working on is claimed	No exceptions	The rule. If something is running and no card in a `doing` list has your name on it, the work is invisible and every number below is fiction.
In your own hands	1 at a time	A fact about attention, not a policy. You cannot hold two implementations in one head. Steering two sessions is a different thing, and it is the row below.
Supervised alongside it	1 to 2	Roughly where most people’s reading quality falls off. Run three if the work genuinely allows it, claim all three, and watch review latency and escapes: they notice over-parallelisation before you do.
In flight per person	3, soft	Everything you hold: in hand, supervised, blocked, awaiting review. A trigger for a comment and a look at the weekly review, not a gate.
Doing + Review, team	2 × people	Review is work in flight. Treating it as free is how a queue of unreviewed work builds up behind a team that feels busy.
Next	2 × people	A ready list longer than that is shaping done too early, and it goes stale.

Set wip_limit on Next and on Doing at the team figures, so the board shows the pressure on a day when nobody is in the mood to be disciplined. The per-person numbers cannot be list settings. They live on the operating page and get looked at weekly.

Why none of the per-person numbers are hard. A limit somebody can only obey by not recording what they are doing is worse than no limit at all: it buys a tidy board at the cost of a true one, and everything in this strand rests on the board being true. Two Claude Code sessions running against two cards is two claimed cards in a doing list, which is not a breach of anything. It is the board being accurate, which is the whole point of having one. The honest answer always goes on the board, and if the honest answer keeps breaking a number, the number was wrong. Change it at the review, in writing, rather than working around it.

What does the policing, then. Not the ceiling. Four things, none of which reward hiding work:

The sentence test below: a comment saying why you are holding what you are holding.
The preference order: finish, unblock someone else, help finish, then start.
The weekly review, which looks for anything held in parallel with no stated reason and puts it back in Next.
Aging WIP and review latency, which are where over-parallelisation shows up as a number rather than as an opinion, usually a week before anyone would have admitted it.

So the rule is not “one thing at a time”. It is that every extra thing in flight is a decision someone took for a reason, the reason is on the board, and nothing is ever off the board to keep a count looking respectable.

Deliberate Parallelism

Four reasons to be holding more than one card. All of them legitimate, all of them written on the card at the moment you take the second one:

Reason	What it looks like
Genuinely blocked	The first card carries `blocked` or `waiting` and a comment naming what will clear it and who can clear it. Plenty of blockages cannot be cleared by the person who has time on their hands, and sitting idle in sympathy helps nobody. Take the next thing from Next.
Something urgent arrived	A customer-affecting bug or an incident displaces whatever is in hand, immediately, without asking. The displaced card gets one comment saying where it got to, and it either stays put for today or goes back to Next.
An agent is working one of them	One person can supervise a dispatched card while working their own, or steer two sessions at once. This is real parallelism and the reason a founding team covers the ground it does. Each session gets its own claimed card, with its own commentary. The constraint is your attention when the work comes back, not your hands.
Waiting on the machine	A long CI run, a migration being babysat, a build you are watching. Short waits, and the card stays yours.

The test is a sentence. If you can say in a comment why you are holding two cards, you are fine. If you cannot, you are drifting, and the honest move is to put one back in Next rather than keep both warm.

What is not a reason: this one is more interesting; I will just start it while I think about the other; it is nearly done anyway. Nearly done is unreviewed, unshipped and unfinished.

When the ceiling is reached, the answer is never to hide a card to stay under it. In order of preference: finish something, unblock someone else, help finish, then start. If the honest answer is still four, claim four and say why. And when a card is put down for a while, say so on it: a card nobody can tell is parked is worse than a card nobody has started.

Flags and Dependencies

Flags are the fast vocabulary for why a card is not moving: blocked (waiting on another card), waiting (waiting on a person: a decision, a credential, an approval), review (needs a human eye before it counts), flagged (something is wrong with this card).

A flag on its own is noise. Every flag gets a comment naming exactly what is being waited for and who can end the wait. When one card genuinely waits on another, record the dependency rather than describing it in prose. Then blocked is computed, the card drops out of what anyone can pick up, and nobody has to remember.

A blocked card you will come back to this week can stay in Doing, as long as the flag and the comment are on it. One that is waiting on something with no date stops pretending to be in flight and goes back to Next. The thing the board must never show is a card in a doing list with nothing newer on it than the move.

The Wiki Beside the Board

Flexing down makes written context more important, not less: it is the only redundancy a three-person team has. Keep it next to the work rather than in a documents folder nobody opens:

ADRs for decisions with consequences someone will have to live with. One page, the options, the choice, the date.
Runbooks for anything that will be done at 2am by whoever is on call, which at this size is the person who built it, half asleep.
One-pagers for Tier 3 decisions, written before the decision, timestamped.
The operating page: your WIP limits, your definition of ready, your definition of done, which changes always get reviewed and which may be self-certified, who holds what. One page, linked from the board, so that the fifth person to join reads it instead of absorbing it.

Link the page from the card. A decision nobody can find was not recorded.

What the Board Must Always Answer

Without a meeting, without asking anyone, in under a minute:

What is being worked on right now, and by whom? Including what an agent is working on, and on whose behalf.
What is next, and in what order?
What is stuck, on what, and who can unstick it?
What shipped since the last time I looked?
What have we deliberately decided not to do?

If the board cannot answer those five, the ceremony you dropped will come back as a standup, because nobody trusts the board.

3. How Work Enters

At this size the roles have collapsed, but the entry points have not. Someone still owns what, someone still owns how, and nobody goes straight to whoever is writing the code.

Source	Entry point	Ordered by
Founder / product idea	Intake	Owner of What
Customer conversation or support request	Intake, with the customer’s words on the card	Owner of What
Sales or commercial commitment	Intake, flagged, with the date that was promised	Owner of What, who also owns saying no
Engineering-initiated (tech debt, reliability, tooling)	Backlog directly	Owner of How, within a standing allocation
Production incident	Doing, immediately, displacing whatever is there	Severity
Agent-discovered work (found mid-task)	Subcard under the epic it serves	Owner of What, at the next triage

Rules:

Only the Owner of What orders Next. Anyone may add to Intake; nobody else promotes.
An engineering allocation of 15–25%, as in the full model, stays ring-fenced and needs no product approval. At four people this is the only thing standing between you and a codebase you are afraid of by month nine.
A commitment made to a customer is a card with a date on it, or it did not happen.
Nothing goes to a person directly. If a request arrives in a DM, the answer is a card, every time, including when the requester is the founder.
Work discovered mid-task becomes a subcard under the epic it serves, never folded silently into the card in hand, and never a new top-level card.

Triage

Fifteen minutes, daily or every other day, Owner of What, alone. This is the only ritual that replaces refinement, and it is the one that keeps the board honest.

Each Intake card gets one of four outcomes: dropped with a reason, parked in the Backlog in order, shaped into Next, or turned into (or attached to) an epic. Nothing stays in Intake overnight twice.

AI usage: an agent does the first pass: deduplicating against existing cards, grouping support tickets into patterns, drafting a problem statement and acceptance criteria, proposing a tier and size. The judgment that follows is the human work: is this real, is it now, and what are we giving up by doing it. Expect to rewrite half of what the draft says and to keep the half that saved you the blank page. The AI Use Case Catalogue covers the intake and triage cases in detail.

4. The Flow

Each transition on the board is a standard, not a drag. Write them down once, on the operating page, and hold them.

Backlog → Next: Definition of Ready

A card enters Next when it could be executed by someone who was not in the conversation. That is the test, and it is also exactly what makes a card dispatchable to an agent.

Problem in two or three sentences, and the evidence it is real
Acceptance criteria a reviewer can check without interpretation
Tier and size band (sizing rules apply unchanged)
Non-goals: what this card deliberately does not do
Where it lands: repo, service, the files or area involved
How it is verified: the test command, the staging URL, the thing to click
Who accepts it: named, and never the author; or marked self-certifying if the card falls in the agreed exception class below

Anything Tier 2 or larger also carries the implementation-plan conversation, which at this size is a ten-minute chat and three bullet points on the card, not a document. It still happens, and it still happens before code.

Next → Doing: Pull, Don’t Assign

Work is pulled from the top, not handed out. Claim the card before the first edit anywhere else: move it to Doing, put your name on it, and comment the plan in two lines. An unclaimed card being worked on is invisible work.

Taking a card that is not at the top is fine when you can say why in the comment: a dependency you can clear while you are in that code, a customer waiting, your own expertise, the top card blocked on somebody else. Doing it silently and repeatedly is how priority order quietly becomes preference order.

An urgent bug does not queue. Whoever sees it takes it, displaces what they were holding with a one-line comment, and tells the other owner afterwards rather than asking first. Needing permission to fix something that is on fire is a worse failure than a disrupted plan.

Doing: While the Work Is Live

Every decision, surprise or dead end becomes a comment. Short, specific, written for whoever reads it in a month: what you chose, what you rejected, where it landed. This is the part everyone values and the part everyone skips.
Anything longer than a sitting gets interim comments at its milestones, with percent_complete moved alongside, so the board reads true without anyone opening the card.
A card untouched for three days gets a comment saying why, or it goes back to Next. Parked deliberately is fine; parked silently is not.
A card that turns out to be three cards gets a sub-board and gets split. Doing three things under one title is how a two-day estimate becomes two weeks with nothing to show.
If the shape changed, say so in a comment. Do not rewrite the title and description to match what you actually did. That is the record of what was asked for.

Doing → Review: Definition of Done (By the Author)

Code committed to main behind a flag, CI green, tests written, deployed to staging, acceptance criteria self-checked, checklist ticked, and a closing comment naming what changed, where, and the commit or PR link. Then the review flag and the Review list, unless the card is in the self-certified class below, in which case it goes straight to Done with its route named on the card.

Review → Done: Definition of Done (By the Team)

Someone other than the author has confirmed it does what the card said, in the environment the card named. Flag on in production. Monitoring looked at once, deliberately. The card marked completed and moved to Done: the list is where people look, the flag is what rollups and reports count, and you set both.

Review is proportionate, and the list of what needs it is written down in advance. Not every change earns a second pair of eyes, and pretending otherwise at this size produces one of two outcomes: a queue of trivia waiting on attention, or a rule everybody quietly stops obeying. The full model already takes this position with pull requests, where review is required for a named set of changes rather than for everything. Same principle here, and roughly the same list.

Always reviewed, whatever its size:

Anything touching authentication, payments or personal data
Schema changes and data migrations
Shared or public interfaces, meaning anything another system or another team builds against
Anything hard to reverse, or where the blast radius is wider than the feature itself
A new user-facing flow, where “it works” and “it is right” are different questions
Work by someone new to the codebase, for as long as the coaching is worth more than the delay
Anything the author is uncertain about. Self-declared doubt is the cheapest quality signal available, and it should never be met with “you decide”.

Self-certified, straight to Done, given green CI and a change that is behind a flag or trivially revertible:

Copy, content and configuration changes
Internal tooling, scripts and developer experience
A contained bug fix with a test that reproduces the bug
Small feature work inside an established pattern, where the acceptance criteria are objective and the author has checked them

The mechanics are one line on the card: which route it took and why. “Self-certified: copy change, criteria checked” takes five seconds to write and is what makes the exception auditable later. A card that skipped review silently is indistinguishable from a card that skipped it carelessly.

Two things stop the exception eating the rule. First, the route is decided when the card is shaped, not when the author is tired and wants to ship. The definition of ready names the accepter, or says the card is self-certifying. Second, escapes shrink the class: if something self-certified reaches a customer broken, that category goes back under review and stays there until it has earned its way out. That is a measurement, not an argument, which is why it works between two people who like each other.

Agent-authored work is not self-certified. It does not need to be: the human who dispatched it and reads what came back is the second pair of eyes. The route only applies to work a person wrote themselves.

At one person, the always-reviewed list is the part worth paying for: a peer founder, an advisor on retainer, a contractor for two hours a week on the customer-facing paths. The self-certified class is what makes a solo founder viable in the first place, and the always-reviewed list is what stops that being an excuse. An agent reviewing an agent’s work is a useful filter and is not a second pair of eyes.

Done → Dropped, and the Backlog Graveyard

Review the Backlog monthly and drop, visibly, with a reason. A backlog nobody has pruned in six months is not a plan, it is a guilt pile, and it makes the board useless for question 5 above. Dropped is a dropped list, not a delete: the reason is the valuable part.

5. Cadence Without Sprints

Ceremony compresses to the board plus three meetings. Everything else is asynchronous, on the cards.

Sprint-model ceremony	What replaces it here
Sprint planning	Nothing. The order of Next is the plan, and it is maintained continuously.
Refinement	Shaping on the card, asynchronously, by the Owner of What. Contested items go to the weekly review.
Daily standup	The board. Aging and stale-card automations do the chasing.
Mid-sprint check	The board.
Sprint demo	Ship it and post the link where the team talks. A twenty-minute monthly walkthrough for anyone outside the team.
Retrospective	Monthly, 45 minutes, whole team.
Architecture review	Ad hoc, with the external technical voice the small-team model assumes.
Quarterly planning	Kept, unchanged. Half a day.

The three meetings that survive:

Meeting	When	Who	Output
Queue review	Weekly, 30 mins	Owner of What + Owner of How	Next re-ordered and agreed; blockers named with an owner; anything held in parallel without a stated reason put back; anything contested resolved
Flow and retro	Monthly, 45 mins	Whole team, no observers	One process change, written down; the flow numbers looked at together
Direction	Quarterly, half a day	Whole team, plus the external voice	Where the next quarter goes, and what is being dropped to go there

Plus the one that is not a meeting about work: a 1:1 per person per fortnight, owned by the named person accountable for growth and wellbeing. At four people it feels unnecessary. It is the first thing to vanish and the last thing you can afford to lose.

Async by default. The queue review is 30 minutes because the board was kept current all week. If it needs an hour, the board was not current, and the meeting is treating the symptom.

6. The Board as the Human/Agent Interface

This is what makes a team of one to four credible at a scope that used to need eight, and it is the reason the board has to be precise rather than merely tidy. The board is not a tracker that someone updates after the fact. It is the dispatch layer: the single queue that people and agents both pull from, both comment on, and both close work out of.

A Card Is a Work Order

A card that meets the definition of ready is already an agent brief. That is not a coincidence: it is why the standard is worth holding. The two additions that make it directly executable:

The entry point. The repo, the branch convention, the files or area, the command that runs the tests.
The boundary. What the agent must not touch, and what it must stop and ask about rather than decide. Schema changes, anything touching auth, payment or PII, anything that changes a public interface.

If a card cannot be written to that standard, it is not ready for an agent, and usually it is not ready for a person either. The honest response is to shape it, or to spike it as an explicitly time-boxed card with “produce a plan” as its acceptance criterion.

The Protocol

The same protocol for people and agents, which is the point:

Claim: move to Doing, assign, comment the plan, before the first edit anywhere else.
Narrate: a comment at every decision, dead end and milestone; percent_complete moved with it.
Escalate rather than improvise: hit the boundary, hit an ambiguity, hit a failing test you did not expect: waiting or blocked, a comment naming exactly what is needed, and stop. A wrong decision quietly taken costs more than an hour of waiting.
Finish: commit (one commit or PR per card, naming the card), closing comment with the link and what was verified, completed, Review.
Never self-accept: an agent moves work to Review. A human moves it to Done.

That last line is the whole governance model. Everything an agent produces passes a human gate, and the gate is a list on the board rather than a good intention.

A Separate Lane, When It Helps

Every running session has a claimed card. One session, one card, with your name on it; two sessions, two cards. Nothing is dispatched against a card that is still sitting in Next, and no card is left unclaimed to keep a count down.

Once more than a card or two at a time is being worked by agents, give them their own doing list: With Agent, between Next and Review. The gain is that the board answers “what is a person doing?” and “what is being produced for me to review?” as two different questions, which stops a review queue from hiding inside a busy-looking Doing column. It also gives you something to hang automation on: a rule on cards entering that list can dispatch the run itself, via a webhook action to whatever you use to launch agents.

What Agents Must Not Do

Written down once, on the operating page, because these are the failures that erode trust in the board:

Not re-order Next, change priorities, or promote their own discovered work. Discovered work becomes a subcard and waits for triage.
Not close an epic with open subcards, and not mark a card done over an unticked checklist.
Not rewrite a card’s title or description to match what was actually built.
Not tidy. Reordering, renaming, archiving stale cards, pruning the backlog: all reasonable, none of it theirs to do unasked.
Not move their own work to Done.
Not work on a board, or in an area, they were not pointed at.

Automation, Not Chasing

At this size nobody has the attention to police the board, so the board polices itself. The rules worth having on day one:

Rule	Trigger → action
Stale in flight	Card in Doing untouched for 3 days → comment, notify the assignee
Abandoned	Card in Doing untouched for 7 days → move back to Next with a comment saying why
Review is waiting	Card enters Review → notify the person named as accepting it
Review is rotting	Card in Review for 2 days → notify, and escalate to the Owner of How at 4
Unready card promoted	Card enters Next without acceptance criteria → `flagged`, and tell the Owner of What
Shipped	Card completed → post to the team channel, so “what shipped” needs no meeting
Dispatch	Card enters With Agent → `webhook` to start the run

Rules keep running after you have gone, so adding one is a change to how the board behaves, not a way of doing today’s task. Prefer written-out specs over described-in-prose ones, and run a new rule by hand once to see what it does before trusting it.

Where the Humans Stay

The leverage is real and it is specifically breadth: one person covering feature work, test automation, infrastructure and documentation to a standard that used to need three. What it does not supply is judgment, and these stay human at any level of tooling:

Deciding what is worth building, and what to drop to build it
Shaping a problem into something with a boundary and a definition of done
Accepting work: the second pair of eyes, and the decision that it is genuinely done
Trade-offs with consequences: schema, interfaces, anything that is hard to reverse
Knowing which defaults can be broken, and asking before breaking them

Agent-Era Anti-Patterns

The unreviewed queue. Work produced faster than it can be accepted. Review is in your WIP ceiling precisely to make this visible; when the ceiling is hit, the answer is to review, not to dispatch more. Self-certifying your way out of a review backlog is how the exception class stops meaning anything.
Cards too vague to dispatch, dispatched anyway. You get something plausible that solves a problem nobody had. The cost lands at review, which is the most expensive place for it to land.
Acceptance by vibe. “It looks right” is not a definition of done. If the card’s criteria cannot be checked, the card was not ready.
The silent agent. A card in flight with no comment newer than the claim. Nobody can tell whether it is alive, and the context of the work is lost even when it succeeds.
Trusting the summary over the diff. Read what changed on anything you would have reviewed if a person wrote it.

7. Flow Metrics

Velocity does not exist here, and should not be reinvented. Five numbers, looked at monthly, and each one has a response rather than a target to admire. Collect them from the board; do not ask people for status.

Metric	What it tells you	Response when it goes bad
Cycle time (Next → Done, median and spread)	How long work actually takes once started. The spread matters more than the median.	A long tail means cards are too big or review is slow. Split or fix the gate.
Throughput (cards to Done per week)	What the team genuinely delivers. The only honest basis for a forecast.	Falling with WIP steady means cards are growing; falling with WIP rising means too much started.
Aging WIP (age of the oldest card in flight)	The leading indicator. Everything else is a lagging one, and this is also what catches over-parallelisation.	Anything older than twice your median cycle time is the subject of the next queue review.
Blocked time (share of in-flight time flagged)	How much of the delay is you, and how much is other people.	Consistently high on `waiting` is an external-dependency problem to manage, not a productivity problem.
Review latency (Review → Done)	Whether the second pair of eyes is real.	Rising latency means the gate is becoming theatre. Fix it before it quietly gets skipped.

For forecasting, use throughput and the spread of cycle time, and quote a range rather than a date: “most cards like this finish in three to eight days” is both true and useful, which “we estimate four days” is not. Keep the same delivery and reliability metrics that are about the system rather than the cadence: deployment frequency, change failure rate, time to restore. Those do not change with team size.

Anything not on that list is decoration until it changes a decision. Measuring more at four people is a way of feeling like a bigger company.

8. Responsibility at This Size

Light ceremony with unclear ownership is not a lighter process, it is an absence of one. The test from Team Structure applies exactly: can everyone name the single person accountable for each of these?

Responsibility	Holder	Where it shows on the board
What gets built next	Owner of What	The order of Next
A card being ready	Owner of What drafts; Owner of How confirms it is feasible	The definition of ready
How it gets built	Owner of How	The implementation-plan comment
It does what it should	A named accepter, never the author; or the author under the written self-certification rule	Review → Done, or the route named on the card
Production out of hours	A named rotation, even of two	The runbook in the wiki
Flow health	Owner of How	The monthly numbers
Growth and wellbeing of the people	One named person	The fortnightly 1:1
The escalation backstop	Someone outside the team, named in advance	The operating page

The two owners are not one person. Even at two people, and especially at one. The daily disagreement between the person who owns the problem and the person who owns the solution is the most valuable thing in the whole model, and the collapse to resist is exactly this one. Where it genuinely cannot be avoided: write the problem and the acceptance criteria down before thinking about the solution, timestamp them on the card, and name someone outside the work whose standing job is to challenge scope before it enters Next. The card is the only thing preventing retrospective justification.

At one person, say which hat you are wearing. Triage is the What hat. Pulling from Next is the How hat. Doing both in the same fifteen minutes is how a board becomes a record of what was interesting.

9. Keep, Compress, Drop

Keep, unchanged	Compress	Drop until you need it
Trunk-based development behind feature flags	Refinement into asynchronous shaping on the card	Sprint planning and sprint commitment
CI as the gate; commit to production in under 30 minutes	The implementation plan into a ten-minute chat and three bullets	Velocity, story points, any form of estimation theatre
A second pair of eyes on everything on the always-reviewed list	Review to self-certification for the agreed low-risk classes	Demo as a scheduled event
Tiering before work starts	1:1s to fortnightly, never less	Cross-squad dependency and arbitration process
Written decisions (ADRs) and runbooks	Metrics to the five that change a decision	Formal competency frameworks and promotion chains
The engineering allocation percentage	Architecture review to ad hoc with an external voice	A separate platform intake queue
Incident review for anything customer-facing		Role titles beyond the two owners

The failure mode is not keeping too much process. It is quietly dropping the written artefacts (problem statements, implementation plans, ADRs, closing comments) because everyone already knows. At three people you do. At nine, with two of the original three gone, you do not, and the board is all that is left.

10. Anti-Patterns

Kanban as a synonym for “no process”. Three lists, no definition of ready, no WIP limit, no review. It is a to-do list wearing a method’s name, and it fails at about the point the team doubles.
Undeliberate WIP. Not two things at once, which is often the right call, but two things at once with no reason written anywhere. It compounds quietly: three becomes six, the board still looks productive, and nothing has shipped in a fortnight.
Working off the board to stay inside a limit. The most damaging anti-pattern in the document, because it disables all the others. When a number and the truth disagree, the number gives way. An unclaimed session, a card worked in Next, a second task folded into the card you already hold: all of them trade a true board for a tidy one.
The exception class that only grows. Every change turns out to be small enough to self-certify. The escape rule is the only thing that stops this, so apply it the first time rather than the third.
Shaping in Doing. Pulling a card and then working out what it means. The time is spent either way; spent in Doing it is spent with the clock running and with an agent or a person idling on an ambiguity.
The board that lies. Cards not moved, agents not commenting, a card in doing for a fortnight. One week of this and the team reinvents standup, because nobody trusts the board. Everything in this strand rests on the board being true.
Priority by recency. Whoever asked most recently, or most loudly, goes to the top. The order of Next is a decision with a reason, and the reason belongs in a comment.
The backlog graveyard. Hundreds of cards, none dropped, so the board can no longer say what you are not doing.
Tidying instead of finishing. Reordering, re-labelling and grooming are the most satisfying unproductive work available to a small team.
Dropping review on the always-reviewed list because everyone is senior. Seniority is the reason that review takes ten minutes rather than an hour. It is not the reason to skip it on the auth change.
Calling it a founding-team model when it is actually under-resourcing. Flexing down means fewer, more senior people covering the same responsibilities to the same standard. If the standard is slipping, the honest response is to cut scope, not to quietly cut quality.

11. Graduating to the Sprint Model

This strand is a shape for a size, not a philosophy to defend. Move when a trigger fires, not when the headcount budget allows.

Trigger	Move
A fifth and sixth person join	Stay on flow, add a weekly commitment: a named handful at the top of Next for the week
A seventh person, or a second distinct product area with its own stakeholders	Adopt the sprint model properly, as one squad
External commitments need dates further out than your cycle-time spread supports	A planning cadence, because forecasting from throughput alone stops convincing people
More than about six people pulling from one board	Two boards, which means two squads, which means the full process
The queue review runs long every week	Refinement as its own session, ahead of the work
Review is consistently the bottleneck	A named quality owner, before any other hire

How to migrate when the time comes: keep the board, keep the lists, keep the definitions of ready and done, keep the WIP limits. Add a sprint boundary around the top of Next and a planning session to set it. That is genuinely the whole change, which is the point of running the same operating model at both sizes. What you must not do is arrive at seven people still insisting that ceremony is overhead. It was overhead at three. At seven it is how two people stop building the same thing twice.

12. Setting It Up

A first pass, in order, in about an hour:

One board, named for the product. Lists: Intake, Backlog, Next, Doing, With Agent, Review, Done, Dropped, each with its category set, because the category is what everything reads.
WIP limits on Next and Doing at the team figures, from the table in section 2. The per-person numbers are an agreement rather than a list setting, so they go on the operating page, along with the line that outranks them: everything anyone is working on is claimed, and a number never justifies leaving work off the board.
The operating page in the wiki: your two owners, the definition of ready, the definition of done, what agents may not do, who the external backstop is. Link it from the board.
Four automations: stale at 3 days, abandoned at 7, review waiting, shipped-to-channel.
Everything currently in flight, onto the board. Then enforce the WIP limit, which will mean moving most of it back to Next. That first enforcement is uncomfortable and is the moment the model starts working.
The three meetings in the calendar, plus the 1:1s. Thirty minutes weekly, 45 monthly, half a day quarterly.
One epic, shaped properly to the definition of ready, as the worked example everyone copies. The standard the board ends up holding is the standard of its first ten cards.

Guides

Cheatsheets