The Decisions

Some of the most useful news I received while running capacity was that a team was about to start using a rare and limited SKU, one we weren’t using at all. Say you run mostly on a general-purpose family such as Azure’s D-series, and a team wants to switch to another SKU family. Your conversations with the provider are largely organized around the families you already use, and a new expectation changes that relationship. If you need half a data center’s worth of a different SKU family, two questions come first: does the provider have it in that data center, and what timeline is realistic to get it? The answers decide what the change will cost, whether the service can do what the team has promised, and who has to agree to a different date.

What computing costs, whether the systems have the capacity to deliver the capability the business needs, and who can accept the answer are different questions, even when they arrive together. This part takes them one at a time. They are still questions about one system, and the problem that arrives first is not always the one governing the outcome.

Releasing a resource, cutting a team’s allocation, and lowering the enterprise bill can be three different results, even when the proposal calls all of them savings. We follow a change through to the obligation, and to the person who will have to defend the bill.

None of those results tells us whether the systems can handle the work that is actually coming, or whether the promise still holds after something fails. Capacity is a separate question, and answering it means deciding which operating condition the customer is entitled to rely on.

Neither answer is a decision until someone accepts it. Finance, the business, engineering, and operations each hold part of the answer. Forecast, budget, and commitment do not mean the same thing in every one of those conversations, and knowing a constraint is different from having the authority to accept it.

If you have run this work before, some of what follows will be familiar ground. Read it as calibration: these chapters set up the methods and the vocabulary the rest of the book applies at scale, and the argument about obligations becomes sharper once the bill is ten times larger.

Whoever runs your capacity and cost work does not need to know every detail of every line on the bill, but they do need to know the overall feel of it: what has changed, what is changing, which changes were expected, and what showed up unexpectedly. Engineering teams may have an excellent understanding of their services while the view across the portfolio remains unassigned. Someone needs to connect those perspectives into a plan that says, “here is an idea: we can do this, and we can do that.” And once in a while — rarely, but it happens — the person holding that view sees something the engineering team is missing, because they are the one looking across the whole bill while everyone else is looking down at their own line.