Why the Numbers Belong to the Business, Not the Engineers

It is tempting to treat recovery objectives as a technical specification, something the infrastructure team sets after studying the systems. This is precisely backwards, and getting it backwards is one of the more expensive mistakes in the field.

RTO and RPO are statements about tolerance for harm. How much money is lost per hour of outage? How many customers walk away and do not return? What does a regulator do when transactions vanish? What happens to a reputation when a hospital, a bank, or a logistics network goes dark? None of these are engineering questions. They are questions about the business, its obligations, and its appetite for risk — and the only people who can answer them are the people who own those consequences.

The engineer's job is different and just as important: to translate a chosen tolerance into an architecture and a price, and to tell the truth about both. When someone with authority over the profit-and-loss statement says the trading system may lose no more than two seconds of data, the engineer's task is to say what that costs and what it requires, not to invent the two-second figure. When the engineer invents the figure, two failures follow. Either the number is too lax, and a business consequence nobody signed up for arrives during the outage; or the number is too strict, and the organisation quietly pays for a resilience it never actually needed, year after year, because 'the systems people said so.'

This is why the numbers must be negotiated in a room where both kinds of authority are present. The business side brings the consequences; the technical side brings the costs. The objective is the point where those two curves meet. Below a certain RTO, the cost of infrastructure rises steeply — halving the acceptable downtime can more than double the bill, because you move from restoring a system to running a permanent shadow of it. The business side has to see that curve to make a real decision. Handed only the wish ('zero downtime'), they will always wish for more than they would ever pay for. Shown the price of each increment, they choose like adults.

There is a second reason ownership matters: accountability during the event itself. When a system is down and the RTO clock is ticking, someone has to decide whether to keep trying to fix the failed environment or to cut over to the recovery one. That decision has consequences — a premature failover can cause its own damage; a delayed one burns through the RTO. If the objective was set by the business, then the business has, in effect, pre-authorised the trade-off: 'past this many minutes, stop trying to save it and switch.' The engineer executing at three in the morning is not improvising a business decision under stress; they are carrying out one that was made calmly, in advance, by the people entitled to make it.

The failure of ownership shows up in a predictable symptom: uniform objectives. When every system in the catalogue has the same RTO and the same RPO, you are almost certainly looking at numbers that were set by engineers applying a default, not by business owners weighing distinct consequences. Real businesses are lumpy. The system that takes customer payments does not deserve the same protection as the internal wiki, and a set of objectives that pretends otherwise is a set of objectives no one has actually examined. We will return to this lumpiness in the next module, because deciding what matters more than what is the entire game.

A closing note on language, because language is where ownership is won or lost. Keep these conversations in plain terms — hours, minutes, dollars, customers, obligations. The moment the discussion retreats into acronyms and tiers, the business owners disengage, and disengaged owners default to 'protect everything,' which is indistinguishable from 'we never chose.' The whole point of naming two numbers was to force a choice. Say the numbers out loud, in words a chief executive would use, and make someone with a budget agree to them. That agreement is the plan's foundation. Everything downstream — the architecture, the testing, the drills at three in the morning — is just faithful execution of a decision the business has already, knowingly, made.