Opens in a new tab
Commentary

Where SRE leadership changes the reliability plan

In brief

SRE leaders resolve collisions between reliability work and delivery commitments, remove response obstacles and decide what the team can actually fund.

4 min read

Sources
A delivery block fills one capacity frame while a separate reliability block waits with its allocation tab resting on that same frame.
On this page3 sections

The incident starts, but the release date and migration plan do not move themselves. The same engineers may now be expected to deliver all three. SRE leadership becomes concrete when someone resolves that collision: which work gets time, which commitment changes and who owns the choice. Without that decision, the gap becomes someone’s late night.

This responsibility appears at different stages of service work. Before an incident, it shapes the agreements people will use under pressure. During one, it removes obstacles to coordinated response. Afterward, it determines whether the lessons have enough time and authority behind them to change the service.

An error-budget policy is easier to use before a disputed launch

Service objectives help when product and engineering leaders understand what follows from missing them. An error-budget policy is easier to use when its consequences for releases have been accepted in advance. Introducing it during a contested launch adds a policy negotiation to an already urgent decision.

Exceptions will sometimes be reasonable. Record who accepted the risk, why, for how long and which protections remain. This preserves the context for responders and the next decision-maker. A private agreement to bypass the policy may get one launch moving while leaving everyone else unsure which rules still apply.

The agreement should also explain when the exception ends. A temporary accommodation becomes a different commitment if its exit condition repeatedly fails. Bringing that result back to the responsible leader keeps an expired compromise from becoming the team's unspoken operating model.

A change in operating demand needs a change in the plan
A change in operating demand needs a change in the plan
Illustrative planning choices. Incident work and recovery consume capacity; leadership must decide which commitments to fund, defer or narrow rather than leaving the gap with responders.
Read diagram description

Illustrative planning choices. Incident work and recovery consume capacity; leadership must decide which commitments to fund, defer or narrow rather than leaving the gap with responders. Diagram labels: Available team capacity: Account for response and recovery work; Fund support: Add usable capacity; Adjust commitments: Defer or narrow planned work; Revised plan: Named owners and a review point.

During the incident, access and coordination matter

Size the response around the incident: an incident lead, reachable service expertise and a communication owner appropriate to the work. Leadership can supply missing capacity, resolve an access problem or clear an organizational barrier. Those interventions help the people already coordinating the response continue their work.

Ask for the current impact, working hypothesis, action underway and next update. That information explains the present decision without requiring a premature root-cause declaration. As evidence changes, the shared account needs room to change with it. A confident explanation produced too early can make uncertainty harder to discuss just when it matters most.

Another senior person helps when they can remove an obstacle: find the specialist, resolve access or get a decision made. They help less when they create another channel asking for a competing version of the incident. Give each participant a purpose inside the existing coordination path, so more authority brings relief instead of more reporting work.

There is a practical difference between asking “Why have we not fixed it yet?” and asking “What is stopping the next check?” The second question can uncover a missing permission, an unavailable specialist or an experiment that needs a decision. It gives leadership something useful to remove while the incident lead keeps the response coordinated.

After the review, the delivery plan has to change

A post-incident review needs to describe confusing interfaces, conflicting incentives and missing permissions without becoming a search for a culprit. Leaders establish that expectation through what they ask and the changes they authorize. A finding about missing permissions should lead to a decision about access; one about competing commitments needs a planning decision. Those responses show the team how the review can improve the next incident.

Consider a hypothetical team that repeatedly postpones preventive engineering to respond to incidents while every product deadline stays intact. Endorsing the reliability goal leaves the collision unresolved. The next planning discussion needs the specific improvement, the hours it requires and the delivery work competing for them. Leadership can then fund the improvement, move a commitment or explicitly accept a delay. If the accepted delay outlives its exit condition, it returns for review rather than becoming an indefinite promise to fix things later.

Look at service outcomes and the people needed to produce them together. If meeting the commitment repeatedly requires exceptional effort, the plan may rely on capacity the team does not ordinarily have. Repairing a defect may help, but it does not settle the remaining mismatch between demand, people and time. Apparent uptime can hide that mismatch for a while.

Finite capacity means some reliability work will wait. Say which work and why, rather than leaving an unfunded promise for an engineer to fail personally. The useful end of the planning meeting is capacity for a named improvement or an owned deferral with a review point. The team can then plan around the decision the organization actually made.

Source context

This article does not include external reference links. Read it as the author’s perspective and evaluate the guidance against your environment.

Report an error or outdated detail

Keep reading

Where to go next