Three SREs, Four Teams, No Leverage

The 1:1 embedded model scales linearly and produces no leverage. Nine more hires at 1:33 engineer coverage means 12 SREs doing 70% operational work for twelve teams. That is not an SRE organization; it is twelve ops people with a reliability-themed job title, at roughly 2-3% of total engineering headcount spent on work the product teams should own. It also reproduces the current problem twelve times, including the 60% toil.

The deeper issue: embedded SREs absorb operational pain, which removes the product team's incentive to reduce it. The SRE becomes a pressure valve, and pressure valves prevent the system from being fixed.

Proposed model - a hybrid, weighted toward consulting:

1. SRE becomes a single team, not three loaners. Centralized, owning tooling, SLO practice, incident review, and production-readiness standards. This is where leverage lives: one piece of tooling serves twelve teams.
2. Product teams own their own on-call. This is non-negotiable and is the entire point. An SRE team that carries someone else's pager will always be a support function.
3. Embedded SRE capacity only for the 2-3 highest-criticality services, time-boxed (e.g., 6 months) with an exit criterion written at the start.
4. Consulting/advocacy for everyone else: SRE reviews architecture, sets SLO templates, runs game days, and advises - but does not operate.

Use the 3 approved hires to build the leverage layer, not to extend the current model. One hire on platform tooling returns more capacity than three embedded SREs.

Unused policies are almost always unused for one of three reasons, and you have to diagnose which:

1. The SLOs are not trusted, so no one believes the budget number.
2. Invoking the policy has no consequence attached - a freeze nobody enforces is a suggestion.
3. It requires a manager to make an unpopular call, and there is no cover for doing so.

Given two of four teams have SLOs, likely all three. A policy that has never been exercised has never been tested; nobody, including you, knows whether it works.

Sequence - do not start with the two teams that have nothing:

1. Start with a team that already has SLOs and a live budget. Wait for (or engineer) a real budget exhaustion. Run the decision properly: freeze, or a documented risk acceptance signed by a named product owner. Either outcome is a valid exercise; the point is that a decision gets made and written down.
2. Publish that precedent internally as "here is what happened when the budget ran out." This is worth more than any amount of SLO training. It converts an abstract policy into a known procedure.
3. Then extend to the other two teams - one at a time, with the tooling and templates from step 1. Do not mandate SLOs across four teams with three people; you will get four sets of aspirational numbers nobody uses, and you will have burned your credibility.

Deliberately sequence rather than parallelize. The scarce resource is not SLO documents; it is attention and follow-through, and you have three people.

Give them a model, not a number.

The argument: SRE headcount should scale with the number of services under SRE-supported practice and their operational load, not with the number of product teams. Team count is a proxy that got us to 1:33 coverage and 70% toil, which is the problem, not the solution. Also show the counterfactual: 9 hires at fully-loaded cost is a permanent, recurring line item, and it buys a model whose toil fraction grows with the business. Tooling investment is one-time and serves everyone.

The proposal:

Phase	Ask	Condition
Now	3 hires: 2 platform/tooling, 1 SRE practice lead	-
6 months	Reassess	Product teams own on-call; toil < 50% across the SRE team; SLOs live on >= 4 teams
12 months	Possible further hires	Only where an embedded model is justified by criticality

Make the conditions explicit and measurable. This is the important move: leadership is much more willing to fund a model with checkpoints than an open-ended headcount request, and it protects you from being asked again in a year why reliability headcount keeps growing while nothing improves.

Also tell them the retention risk in plain terms. One SRE at 60% toil is one resignation away from a 33% team reduction and a knowledge cliff. That is not a hypothetical; it is a named person and a known number. Frame the 3 hires as retention protection for a team that already exists, not as growth.

And say the quiet part: the current model is not under-resourced so much as mis-shaped. Nine hires would make it a bigger version of the same problem.