An interviewer says - your platform team has found a change that would cut roughly £400000 a year of cloud spend and would take two engineers a quarter to deliver. Talk me through how you decide, and what you would want to know before you answer.

What the interviewer is testing

Whether you treat engineering time as a real cost, and whether you know that a headline saving can be worth a fraction of its number, zero, or less than zero. The candidate who answers "the payback is under three months, obviously do it" has not asked the questions that decide it.

The clarifying questions that change the answer

• Is the spend under a commitment? If £300000 of the £400000 sits inside a two-year committed-spend agreement signed last month, reducing usage changes nothing on the invoice until the term ends. You would still be paying for the capacity you stopped using. The realisable saving this year is £100000 and the project is roughly break-even.
• Does the saving persist without attention? A configuration change to a shared module persists. A rightsizing pass across 900 workloads decays as teams grow their requests back, and is worth its half-life rather than its headline. Ask what re-creates the cost.
• Who owns the result? If the change leaves behind a pipeline, a dashboard or an exception process that someone must run, that is a permanent claim on a team, not a one-quarter cost.
• What does it displace? Two engineers for a quarter is the roadmap item that does not ship. The comparison is against that item's value, not against zero.
• What does it do to headroom? A saving that removes capacity kept for failure has moved risk onto the reliability budget, and that belongs in the same decision.

The arithmetic

Two engineers for a quarter is roughly half an engineer-year. Fully loaded, including employer costs, tooling and overhead, that is on the order of £60000 to £100000 in the UK in 2026. Against a genuinely recurring £400000, payback is inside three months and the answer is yes. Against a realisable £100000 that decays by half within a year, the same project returns perhaps £70000 over its life and is a loss.

The rule: compare the annualised saving that survives without maintenance against the fully loaded delivery cost plus the ongoing cost of keeping it. Reject when the spend is committed, when the saving decays, when nobody will own the residue, or when the capacity being removed is reliability headroom.

Common weak answers

• "It pays for itself, so do it." Ignores commitment coverage, decay and ownership, which are the three ways this goes wrong in practice.
• "Cost is finance's concern." The decision needs both: finance knows the commitment position, engineering knows whether the saving survives.
• "Always take the saving, it compounds." Savings that require a standing rota do not compound, they accumulate operational debt.

What a strong answer adds

Two things. First, ask whether the same two engineers could instead change a default that prevents the cost class from recurring across every team, such as the base image, the infrastructure module, the cluster autoscaler policy or the retention setting on the log pipeline. Prevention usually beats remediation by an order of magnitude because it applies to work that has not been written yet. Second, say how the saving will be verified: billing data lags by a day or more and is noisy at the team level, so agree the measurement, the baseline and the date before starting, or the project will be argued about for a quarter after it ships.