Shared-Team Queue

Centralising a scarce skill looks like an efficiency: four people who understand the data model review every schema change, so conventions hold and mistakes are caught. The arrangement is also a queue, and queues do not degrade gracefully.

As utilisation approaches capacity, waiting time rises steeply rather than proportionally. A team busy half the time returns work in days; the same team at 90% utilisation takes several times longer with far more variance. The organisation experiences this as slowness and the central team experiences it as working flat out, and both descriptions are accurate, which is why the conversation usually goes badly.

Why it matters

The waiting time is the least of it. The behavioural responses are what destroy the value the centralisation was created to produce:

• Batching. Teams learn that submission is expensive, so they submit larger, less frequent, riskier changes, which raises the failure rate per change.
• Avoidance. A JSON blob in an existing column, a table created "temporarily" outside the model, a copy of the data in a service. The governance benefit evaporates quietly while the bottleneck remains, which is the worst of both arrangements.
• Planning distortion. Roadmaps are shaped around when the central team can take the work, so architectural sequencing becomes a capacity calendar.

Implementation patterns

• Publish the queue's lead time as a metric the whole organisation sees, with its distribution rather than its mean. The tail is the experience people actually have.
• Split by risk, by rule. A fast path for low-risk changes, defined by criteria rather than judgement, so most work does not enter the queue at all.
• Move from doing to enabling: the central team owns standards, tooling and automated checks, and reviews only what the checks flag. Scarce expertise stops being a queue and becomes a multiplier.
• Measure the avoidance behaviour — shadow tables, unmanaged copies, workarounds — as the honest indicator of whether the model is working.
• Keep an explicit capacity headroom target, because a central team planned to 100% utilisation is planned to have unbounded lead times.

Industry example

The data-governance version of this is the most common, and the same shape appears in security review boards, architecture review boards, DBA teams, release management and centralised cloud provisioning. The Team Topologies framing, published in 2019, names the healthy alternative directly: an enabling team whose output is other teams' capability, rather than a queue whose output is approvals. Platform engineering's self-service movement is the same correction applied to infrastructure.

Failure scenarios

• Silent saturation, where lead time drifts from days to weeks over two quarters with no decision having been taken.
• The escalation lane, created to relieve pressure, which becomes the only lane, so the queue is now sorted by political weight.
• Quality erosion under pressure, as the central team, blamed for delay, starts approving quickly, which removes the benefit while keeping the cost.
• Key-person concentration, where one reviewer handles most of the work and their leave is an organisational outage.

Trade-offs

Centralisation buys consistency, enforceable governance and concentrated expertise; it pays in lead time, variance and the avoidance behaviour that lead time causes. Decentralisation inverts all four. The middle path — standards, tooling and automated checks with local execution — buys most of the consistency and gives up the guarantee that a human expert saw everything, which is a real loss and usually the right trade above a handful of consumer teams.

When not to use it

When the cost of an error greatly exceeds the cost of waiting, and volume is low enough that the queue never saturates. Financial ledgers, clinical data models, regulatory submissions: the bottleneck is the point, and the wait is the cheapest part of the control. The failure is applying that posture to everything, so routine changes inherit a control designed for the dangerous 5% of work.

Interview question

Q: Product teams complain that the central data team takes three weeks for a schema change. The data team is fully occupied and adding people is not funded this year. What do you propose?

What a strong answer covers: measuring the lead-time distribution and the arrival rate before proposing anything · splitting low-risk changes onto an automated path defined by rule · moving the team's output from approvals to standards, templates and checks · quantifying the avoidance already happening as evidence · rejecting the reflex fix of an escalation lane · and being explicit that some categories should stay in the queue because their error cost justifies it.

Quick check

Quiz: Why does a central team at 90% utilisation feel dramatically slower than at 50%? Because waiting time in a queue rises sharply as utilisation approaches capacity, and variance rises with it, so the experience is both slower and less predictable.

Flashcard: What is the honest indicator that a central control is failing? — The volume of work routing around it: shadow tables, unmanaged copies and local workarounds.