Skip to content

Platform Team Bottleneck Test

Capacity diagnostic / bottleneck test — instantiates Organization–Artifact Topology Alignment

Checks whether a shared platform or broker team has become the chokepoint every other team must queue behind, by comparing its throughput capacity against the coordination load routed through it.

When many teams depend on one shared team — a platform group, an integration team, a central DBA or "architecture" gatekeeper — that node can quietly become the constraint the whole organization runs against. Platform Team Bottleneck Test is the targeted diagnostic that checks whether it has. Its defining move is to treat one specific team as a capacity node and put two numbers next to each other: how much coordination and change-throughput the team can actually service, and how much every other team is routing through it. A verdict falls out — the platform is comfortably within capacity, or it is the chokepoint that explains why everyone else is waiting. Unlike a broad, always-on overhead monitor, this is a pointed, answer-a-question test aimed at a single node.

Example

At a streaming-media company, feature teams keep missing dates and all of them point at the same place: the central video-encoding platform team that owns the shared pipeline every product must call to ship anything. The bottleneck test sizes it. On the capacity side, it models the platform team's real throughput — how many onboarding requests, pipeline changes, and support escalations it can clear in a sprint given its headcount and how much of that time is already eaten by run-the-business toil (≈70%, leaving little for new work). On the load side, it counts what is being routed through the team: eleven downstream teams, each needing platform work to release, with a request queue that has grown for six straight sprints. Put together, demand runs roughly twice serviceable capacity, and the median request waits about three weeks. The test's output isn't "the platform team is bad" — it's a sized constraint: this node is the bottleneck; either its capacity rises, or the load routed through it must fall. That reframes the fix as widening the throat (staffing, self-service, a thinner platform) rather than blaming the feature teams for slipping.

How it works

The distinctive move is a capacity-versus-load comparison on one node, not a general health scan:

  • Model serviceable capacity. Estimate how much coordination and change the shared team can actually deliver per period, net of the toil and support that already consumes it — not its nominal headcount.
  • Measure the load routed through it. Count the teams that must transact with it to make progress, the request/queue volume, and the wait times those requests incur.
  • Compare and rule. Set load against capacity and return a verdict with a margin: within capacity, near saturation, or over — and, if over, which relief lever (more capacity, less load, self-service) moves the number.

Tuning parameters

  • Capacity denominator — whether "capacity" counts nominal headcount or only the fraction genuinely free for downstream work after toil. The honest denominator is almost always the smaller one.
  • Load window — the period over which requests and waits are counted. Too short and a temporary spike reads as a structural bottleneck; too long and a worsening trend gets averaged away.
  • Queue vs. flow framing — measuring the standing backlog versus the wait each request experiences. Backlog understates pain when work is silently dropped rather than queued.
  • Saturation threshold — how close to capacity counts as "bottleneck," since a shared team run at 100% has no slack for variance and stalls long before it is nominally full.
  • Relief-lever attribution — how much of the gap the test attributes to capacity versus load, which steers whether the answer is "grow the team" or "stop routing everything through it."

When it helps, and when it misleads

Its strength is that it replaces a blame narrative ("the platform team is slow") with a sized constraint that points at a lever, and it catches the specific failure mode where an org has centralized a function into a team that everyone must queue behind. The underlying math is Brooks's-Law-shaped: coordination that funnels through one node concentrates the cost of every pairwise interaction into a single throat.[1]

It misleads when a genuine spike is read as a structural bottleneck, or when the queue is measured but silently-dropped work is not, understating the real load. It can also mistake a cognitive-load problem — a platform trying to own too much surface — for a mere headcount shortage, sending an org to hire when it should narrow the platform's scope. And run backwards, it becomes ammunition to justify a reorganization already chosen. The discipline is to measure over a window long enough to separate spike from trend, to count dropped as well as queued demand, and to test whether the relief is more capacity or less load before acting.

How it implements the components

The test realizes the measurement face of the archetype — sizing one node and the load on it, not mapping the whole topology:

  • platform_or_broker_capacity_model — its core construct: a model of the shared team's serviceable throughput, net of the toil that already consumes it.
  • coordination_overhead_metric — the load reading routed through that node: how many teams, requests, and waits are concentrated on it.

It does not continuously monitor overhead across the whole organization — that broad, standing view is the Coordination-Overhead Dashboard, where this test is a pointed one-off — and it neither redraws the platform's boundaries nor its ownership; those are Ownership Boundary Refactor and the artifact-side refactors.

References

[1] Brooks's Law — "adding manpower to a late software project makes it later" — rests on pairwise communication channels growing as n(n−1)/2 (Fred Brooks, The Mythical Man-Month). A shared team every other team must coordinate with concentrates that growth into a single node, which is exactly the bottleneck this test sizes. ↩