advanced 2 min answer

A team reduces its cloud bill 30% by removing a standby replica, then has an outage. What was wrong with the incentive structure?

chargebackincentivesreliabilityslogovernance
Show the full answer Hide the answer

What is being tested

Whether you recognise a single-objective incentive as the cause, rather than blaming the team's judgement.

The diagnosis

The team was given a cost target with no corresponding reliability target. They optimised the metric they were measured on, which is exactly what incentive structures produce, and the organisation got what it asked for.

The failure is not the engineer's decision. It is that the decision — trading availability for cost — was made locally, by people who saw only one side of it, because only one side was on their dashboard.

What should have been in place

1. Paired targets. Cost and reliability together. A team with an SLO and an error budget cannot remove a replica without visibly consuming budget, so the trade becomes explicit rather than invisible. The error budget is exactly the mechanism that makes the reliability side of the trade consequential.

2. Reliability requirements as constraints, not preferences. "This service must survive the loss of one availability zone" is a constraint the cost optimisation must respect. Encoded as policy — minimum replica counts for tier-1 services — it cannot be optimised away by a team acting locally.

3. Cost review that includes architectural change. Reducing a snapshot retention period is different in kind from removing a redundancy component. The second deserves review; the first does not. A cost programme that treats them identically will eventually produce this outcome.

4. Unit cost rather than total cost. A team growing efficiently should not be penalised alongside one that is not, and reporting totals encourages exactly the kind of blunt reduction that removed the replica.

The general chargeback pathologies this illustrates

  • Perverse reliability trade-offs — the case here.
  • Gaming — avoiding tagged resources, or hiding cost in shared infrastructure.
  • Under-investment in shared platforms, because nobody wants to fund something others use.
  • Administrative overhead, arguing about allocation keys.

Which is why most organisations land on showback with accountability: teams see their spend and their unit cost, have a target, and explain variance, without money actually moving. That captures most of the incentive with little of the dysfunction.

The framing for the retrospective

Not "the team made a bad decision". The system produced a predictable outcome from a single-objective incentive, and the fix is structural: pair the objectives, encode reliability requirements as constraints, and review architectural changes made for cost reasons with the same care as any other architectural change.

What a strong answer adds

That the outage very likely cost more than the 30% saved, and quantifying that is what makes the case for paired targets to whoever set the cost target in the first place.