Diagnosing a Stuck Team with the Four States

The problem

A capable team’s throughput goes flat and stays flat, sprint after sprint. The reflex is to read the flat line as a capacity shortage and ask for more people. It is usually the opposite: the team is spending its capacity re-deriving what the work means and who owns it, and adding headcount makes that worse.

I learned this on a billing team whose throughput had been flat for five sprints. I wrote the headcount case and pushed it hard — until a standup where an engineer asked whether a PaymentSettled event meant the money had moved or just that we intended to move it. Three people gave three answers. The team wasn’t short of hands; it was short of agreement.

The model

Larson’s four states — falling behind, treading water, repaying debt, innovating — are easy to misread as a function of headcount. Mostly they track how clearly the work is bounded. A treading-water team is running hard to stay level, and you cannot add your way out of it: new people in a system nobody can describe just multiply the conversations needed to change anything. That coordination cost is invisible on a throughput chart, which is exactly why a flat line fools you into hiring.

What to do

Treat ambiguity as a missing artifact, not a personality trait. Ownership and meaning can be written down; until they are, people carry them in their heads, and heads disagree.
Map the domain. List every service, the events it owns, and a one-line definition of what each event asserts about the world.
Make ownership singular. Each event gets exactly one emitting service and a named owner. Force contested ownership to a conclusion instead of leaving it polite and unresolved.
Write contracts as code, not as a wiki page, so the event shape and its meaning live next to the aggregate that produces it and can’t drift silently.
Add one question to PR review: “does this change what an existing event means, and if so, who did you tell?”

The results

Cycle time on a typical story fell from roughly eight days to about three over the next quarter — not from anyone working faster, but from stories no longer stalling in “wait, what does this mean.” Rework fell more visibly: changes reopened because a downstream service assumed a different meaning roughly halved, and the “quick question — does this event mean…” threads mostly stopped.

The caveat: this does nothing for genuine capacity limits. A year later, with the map clear, we added one engineer and it worked — because they could read the boundaries instead of inheriting an argument. Pausing all feature work for two sprints to do the mapping also cost goodwill I had to earn back; run it as a thinner thread alongside delivery. Either way: name the boundaries before you count the people.