Why reliability loses every individual trade-off
A feature arrives at planning with a sponsor, a date, a customer quote and a revenue story. A reliability item arrives with a probability. Its payoff is an absence, the outage that did not happen, and nobody gets credit for an absence. In any single ranking exercise the feature wins, and it should win, on the evidence presented. Repeat that decision across forty teams for a year and the organisation has chosen fragility without anyone choosing it.
That is why exhorting teams to "prioritise reliability" fails, and why blaming product managers fails too. They are optimising the measures they were given. At executive level the job is to change the rules of the planning game, not to win individual items inside it.
An error budget policy as an organisation-wide rule
The mechanics of SLOs and error budgets are covered on the SLO and error budget page. The executive contribution is turning that mechanism into policy with real authority. Three things make the difference.
First, SLOs are set per user journey, such as checkout, sign-in or payout, and agreed with the product leader who owns that journey. A target engineering wrote alone is a target product can ignore. Second, the error budget policy says in advance what happens at each budget state, and both the CPO and you sign it. Third, the policy names who may override it. Without that clause the policy is waived quietly every busy month.
| Budget state, rolling window | What happens | Who decides |
|---|
| Healthy | Normal release cadence; teams take reasonable risk | The team |
| Burning fast | The owning team's next sprint starts with the top reliability item | Engineering manager, reported weekly |
| Exhausted | Feature releases for that journey pause, except fixes and security | Engineering director and product director together |
| Exhausted, business wants to ship anyway | Allowed, with the risk written down and a date to restore the policy | A named VP or above, recorded in the monthly review |
The last row is the one that changes behaviour. It does not forbid the business from choosing features over reliability. Sometimes that is the right call: a contractual launch, a regulatory date, a competitor's move. It makes the choice explicit and owned. An executive who has to sign "we accept a higher outage risk on checkout until 30 November" signs less often, and remembers it when the outage arrives.
A capacity floor that is not a bidding item
Not all reliability work fits under an error budget. Patching, dependency upgrades, certificate rotation, capacity headroom and on-call carry are the running cost of software already in production. They should not compete in planning at all. Set a capacity floor for this work, derived from measurement of where time went last quarter, as described on the capacity allocation page. Then defend it as a policy, not a mood.
The organisation-level step is making the floor visible above team level. Report it in the quarterly business review alongside feature delivery. When a director raids it to hit a date, that shows up in the numbers, and you ask about it.
Putting reliability investment in the same currency
Larger reliability investment, such as regional isolation, a database migration or a deployment-safety programme, still has to compete for funding. It loses if it is argued in engineering terms. It wins more often when it is argued with the company's own incident history, priced from stated assumptions:
Illustrative cost of last year's checkout incidents (derive from your own data)
revenue at risk = orders per minute in the affected window x minutes down x average order value
service credits = credits actually paid under customer contracts
support load = extra contacts x cost per contact
engineering time = responder hours + review and remediation hours
-> compare against the cost of the programme that removes this failure class
Two cautions keep this honest. Revenue at risk is not revenue lost, because some customers retry later, so say which one you are quoting. And do not promise the programme will prevent all future incidents. Claim the failure class it removes and how you will check.
Changing who notices
Planning rules only hold if leadership attention backs them. Put SLO status for the top journeys on the same page as delivery metrics in your monthly executive review. Ask about budget burn as often as you ask about launch dates. Make on-call load and incident counts visible per team, so a director whose teams carry three times the pages of their peers is a conversation, not a statistic.
Promotion criteria matter here too. If the engineers who led a quiet year of deployment-safety work are promoted more slowly than those who shipped launches, every engineer in the organisation reads the real policy correctly.
Why handing it to a reliability team backfires
The tempting executive move is to create or grow a central SRE team and give reliability to them. It feels decisive and it produces an org-chart change you can announce. It also lets every feature team keep shipping fragile changes, because someone else now owns the consequences. The central team becomes a fire brigade, burns out, and reliability still loses in planning, because planning still happens in the feature teams.
A platform or SRE group can build tooling, define standards and coach. Reliability of a user journey must stay with the team that changes it, under a budget that team's product leader signed. A candidate who reaches "hire an SRE team" first, without explaining how ownership stays with feature teams, has moved the problem rather than solved it.
What changes and how you will know
Give the organisation two or three quarters before judging the error budget policy, and measure outcomes rather than compliance. Useful signs are fewer incidents on the journeys under policy, more of them caught by burn alerts before customers report them, and override requests that are rare and specific rather than routine. If overrides are signed every month, the SLOs are wrong or the business does not accept the trade-off. Both are worth knowing, and the second is a conversation with the CEO, not with the teams.
Reliability loses when it competes item by item. Make the trade-off a rule agreed in advance, make breaking the rule a signed executive decision, and price the risk in the company's own incident history.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).