An organisation centralises all schema changes through one data team of four, serving fourteen product teams. The arrangement is defended as efficient. What is gained, what is paid, and when does the bill arrive?

What is gained, honestly

• Consistency: one group applies the same conventions, so the schema does not fragment into fourteen dialects.
• Scarce expertise applied where it matters. Four people who genuinely understand the data model review every change, which catches the mistakes that are expensive to undo.
• A single place for governance: lineage, classification and access control are enforceable because everything passes one desk.

These are real, and they are the reason the arrangement exists. The question is what they cost.

What is paid, and the mechanism

A shared team is a queue, and queues do not degrade linearly. As utilisation approaches capacity, waiting time rises sharply: a team busy 50% of the time returns work quickly, and the same team at 90% has a waiting time several times longer, with far more variance. The organisation experiences that as "the data team is slow", and the data team experiences it as working flat out, and both are accurate.

The second-order effects are worse than the wait:

• Batching. Product teams learn the queue is slow and submit larger, riskier changes less often, which raises the failure rate per change.
• Avoidance. Teams route around the queue: a JSON blob in an existing column, a new table "temporarily" outside the model, a read replica copied into a service. The governance benefit quietly evaporates while the queue remains.
• Planning distortion. Roadmaps are built around when the data team can take the work, which moves architectural sequencing decisions into a capacity calendar.

When the bill arrives

At the point where demand crosses roughly 70-80% of the team's capacity, which is usually a consequence of the organisation growing rather than of any decision. Nothing is announced; lead times drift from days to weeks over a couple of quarters, and the first visible symptom is usually the avoidance behaviour rather than the queue itself.

How to keep the option to reverse

The useful move is not "centralise" or "decentralise" but changing what the central team produces. Shift from reviewing every change to owning the standards, the tooling and the automated checks, with product teams making their own changes inside guardrails, and the central team reviewing only what the checks flag. The expertise stays scarce and stops being a queue.

Practical markers: publish the queue's lead time as a metric the organisation sees · keep a fast path for low-risk changes, defined by rule rather than by judgement · measure the avoidance behaviour, because it is the honest indicator of whether the model is working.

When this critique is wrong

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