Your organisation has grown to about 40 services with independent teams. Would you introduce a central first-line on-call tier that triages pages and escalates to service teams, or keep paging each service's own team directly? Argue the tradeoff.

## The two models **Direct paging ("you build it, you run it").** Each service's alerts route to the owning team's escalation policy. The people who wrote the code get woken by it. **Central first-line tier.** A dedicated rotation — historically an NOC, today more often a platform or production-engineering on-call — receives pages first, triages against a runbook, mitigates what it can, and escalates to the owning team when it cannot. Both exist in serious organisations. The interview is not looking for a doctrine; it is looking for whether you can price each one. ## What direct paging buys - **Time to mitigate.** The owner needs no handoff, knows what shipped yesterday, and can act on their own systems without asking permission. - **The feedback loop.** This is the real argument. When the team that ships the code holds the pager, unreliability has a personal cost to exactly the people who can remove it. Noisy alerts get pruned, flaky retries get fixed, and "we'll clean it up later" becomes "I am not doing that again next Tuesday." - **Ownership clarity.** Everyone knows who has it, always. ## What direct paging costs - **Coverage.** A rotation needs enough people to be sustainable — commonly cited as six or more so nobody carries the pager more than roughly one week in six. A four-person team paging 24/7 is a burnout schedule, and a follow-the-sun equivalent needs staff in multiple regions. - **Duplication.** Forty teams each build the same on-call muscle, and forty pagers means the same cross-cutting incident can wake many people at once. - **Uneven maturity.** Some teams will be excellent at it and some will not, and their customers experience the difference. ## What a first-line tier buys - **Coverage without staffing every team for nights.** One rotation of specialists covers the hours that dozens of small teams cannot. - **A home for cross-cutting signals.** Edge health, network, shared capacity, region-level failure — alerts where no single service is the owner and the correct first responder is someone with a whole-system view. - **An owner of last resort.** Unmatched alerts and orphaned services have somewhere to land, loudly, rather than firing into a void. - **Consistency.** One rotation with drilled process, tested runbooks and a known way to run an incident, which is genuinely better than forty ad-hoc versions. ## What it costs — and this is the part candidates miss - **A triage hop on every incident.** Minutes spent by someone reading a runbook before the person who knows the answer is even aware. For a tier-1 outage that latency is the dominant cost. - **Broken feedback.** The team shipping the code stops feeling the consequences. Alert noise nobody suffers from is alert noise nobody prunes; a service that pages twice a night becomes someone else's problem indefinitely. This is the failure that quietly kills reliability programmes. - **A runbook maintenance treadmill.** The tier can only act on what is written down, and the writing is done by teams who no longer feel the pain of it being stale. - **A career and morale hazard.** A rotation whose job is to route pages it cannot fix is corrosive work; retention there is often poor, which makes the tier's quality unstable. ## The hybrid I would actually build 1. Service-specific alerts route **direct to owning teams**. This is the default and the majority of pages. 2. A **central tier owns cross-cutting signals** — edge, network, shared infrastructure, region-wide capacity — plus the catch-all for unrouted alerts, and acts as incident-command support for large multi-team incidents. 3. A **hard rule with teeth: the central tier does not absorb recurring service-specific pages.** If a service pages the central tier repeatedly, the alert routes back to the owning team with the recurrence data attached. Absorbed pain is unfixed pain, and this rule is the whole defence of the model. 4. **Team-size problems get solved as team-size problems.** If a team is too small to hold a pager sustainably, merge rotations across two or three related teams so people are still paged for systems they know, rather than pushing the burden to strangers. ## How I would decide, and how I would know it was working Evidence beats preference. I would look at where minutes actually go in postmortem timelines: if time-to-mitigate is dominated by triage latency, the central tier is hurting; if it is dominated by nobody being awake in a region, coverage is the binding constraint. I would watch what share of pages the first-line tier resolves without escalating — a low share means it is an expensive relay — and I would watch per-team page volume trends, because a healthy model shows them falling as teams fix what wakes them. A central tier whose own page volume grows year over year is not scaling the org; it is laundering unreliability, and that is the point at which I would push routing back to owners.