The systems behind work that scales

Growth does not break a team by adding work; it breaks the shared context that made informal coordination possible, and the remedy is deliberate systems rather than more effort.

A small team runs on shared context. Everyone hears the same conversations, awkward cases are settled by turning around in a chair, and the process lives in the heads of the people doing the work. That is efficient, and it holds until it does not.

The failure is gradual. A new starter cannot find out how a refund gets approved. Two people handle the same request differently. Work arrives by email, chat, a form and a phone call, and none of those places knows about the others. Nothing is obviously broken, yet more of the day goes on coordination and less on the work.

Where growth breaks a team

The pressure points are predictable and arrive in roughly the same order whatever the industry. Recognising them early is most of the work.

Growing teams tend to come apart along these seams:

1. Intake fragments across channels, so no single place shows everything waiting to be done.
2. Handovers become lossy, because the context behind a decision never leaves the person who made it.
3. Exceptions get handled case by case until the exception is most of the work.
4. Status is obtained by interruption, since nothing in the system reports it on its own.
5. Onboarding slows as the unwritten rules start to outnumber the written ones.

Each of these is a systems problem rather than a performance problem, which is why hiring against them rarely helps for long.

One route in, one queue

The highest-value change available to most teams is to give work a single front door. Every request, however it arrives, becomes a record in one queue with a requester, a type, a state and an owner.

That does not mean forcing people into a form they resent. Email, chat and phone can stay open, provided each of them creates the same kind of record behind the scenes. The channel is a matter of preference; the queue is the system of record.

Once the work sits in one place, the useful properties follow. Prioritisation becomes possible because the whole backlog is visible. Load becomes measurable. Covering an absent colleague stops depending on whose inbox holds the thread.

Written defaults over tribal knowledge

Documentation fails when it tries to describe everything. What scales is a short written default for each recurring decision: the normal answer, the conditions under which it does not apply, and who decides then.

A default of that shape is cheap to write and easy to correct. It also turns a disagreement into a visible edit rather than an argument repeated privately across three threads.

Keep those defaults next to the work. A procedure filed in a wiki nobody opens has no effect; the same words attached to the queue or the checklist get read when they are needed.

Measurement that survives growth

Measuring individual output is a reliable way to make a system worse. Measure the work instead: where it waits, where it goes backwards, and where it leaves the team altogether.

• Time in each state: the waiting between steps usually dwarfs the time spent doing the work.
• Rework rate: items that return to an earlier state point at a gap in the intake, not at carelessness.
• Queue age: the oldest item waiting matters more than the average, which hides what is going stale.
• Exception volume: a rising share of cases needing a decision means the written default no longer matches reality.
• Handover count: every extra pair of hands adds delay and another chance to lose the thread.

Systems that grow with the team

None of this needs building at once, and a team that tries ends up with a heavy process fitted to the work it had last year. Take the seam that hurts most, put one system in place, and let the next bottleneck show itself.

The aim is not to remove judgement from the work. It is to spend that judgement on the cases that deserve it, instead of on rediscovering how the ordinary ones are meant to go.

• operations