Organizational Impact of SRE
SRE changes how decisions are made
The deepest organisational effect of SRE is not tooling; it is that reliability becomes a negotiated, measurable commitment rather than an argument. Error budget policies give product, development and operations a shared rule for when to ship and when to stop and fix. Production readiness reviews shift reliability consideration left, into design.
SRE teams take several shapes: embedded (SREs sit inside product teams), consulting (advise, then hand back), infrastructure/tools (build platforms others use), and central/ops teams that hold the pager for legacy systems. Each has trade-offs; the common anti-pattern is a central team that becomes a ticket-driven gatekeeper and a bottleneck.
Sustainable on-call
On-call health is an organisational responsibility. Reasonable practices include capped incident load per shift, compensation or time off, escalation paths, runbooks, and a rule that an on-call who is woken repeatedly is generating toil that must be engineered away. Team size matters: rotations that are too small burn people out, and burnout destroys reliability.
Traps
- Framing SRE as a gatekeeping approval body rather than an enabler and partner.
- Assuming ‘you build it, you run it’ means SRE has no role; SRE provides the framework, platforms and practices that make ownership viable.
- Copying another company's SRE org chart instead of its principles.
- Ignoring the human cost of alert noise; the pager is a design artefact.
Rule of thumb
If an SRE team spends more time on tickets than on engineering, it has become an ops team with a new name. The organisational fix is to push ownership to service teams and have SRE build the paved road they use.