The Players and the Vocabulary

I have had enough of these conversations to appreciate the distinction between knowing the terminology and understanding how another discipline uses it. A lower recurring cost can be real and still require money at a time when the business has committed that money elsewhere. A migration can be a good investment once it is finished and a difficult one to fund while both environments are running. If I leave Finance out until I have completed the analysis, I may have completed the wrong analysis.

The same problem appears with customers, operating teams, suppliers, and specialists. Each knows something we need, but knowing the answer and having authority to change it are different things. A capacity practice has to work across both: find the people who can explain the constraint and the people who can decide what to do about it. There may be quite a distance between them on the organization chart.

How to read this chapter

This chapter maps the people around a capacity decision and the vocabulary that makes agreements between them legible.

1. Four parties, more than four people — Finance, Business, Software Engineering, and SRE, why none can relax its position alone, and where SRE’s capacity role begins.
2. The nouns that change a meeting — forecast, target, budget, request, reservation, and commitment, one question that tells them apart, and one product noun that changes meetings just as often: the SKU.
3. Who can change the promise? — an authority map for the launch.
4. When agreement does not arrive — options that expire, escalation that reaches real authority, and being overruled.
5. When you are the one escalated on — escalation as a daily event, why there is no escalation of reality, and a standing committee for the conflicts that need a ruling.
6. Visibility without agency — cost information for the people who can act on it.
7. Find the people who already know — demand knowledge outside the capacity team, and planning methods that differ for good reasons.

The people who understand demand and the people who control supply may hold different parts of the answer. A useful agreement connects their evidence and makes the decision authority clear.

Four parties, more than four people

Finance, Business, Software Engineering, and Site Reliability Engineering give us a useful starting point for understanding the competing inputs. I don’t mean that every company should draw four boxes and assign the work accordingly. Procurement, security, legal, facilities, data specialists, and platform teams may hold information or authority that determines whether a proposal is feasible. The FinOps Foundation makes the same point about its personas: they are stakeholder groups, not individual people.² I keep SRE separate from software engineering because our launch turns on that difference: new work set against a reliability promise already made to existing customers.

Think about the launch from the preceding chapter. Each party at that table answers to somebody who isn’t in the room. The business owner has told customers, or a sales team, roughly when the feature will arrive. Finance has given the executive team a spending plan for the year and will have to explain any variance from it. The engineers have a delivery schedule that other teams are counting on, and the SRE team holds the promise the business made to existing customers: that the service will stay up if part of it goes down. None of these positions is unreasonable, and nobody can relax one alone, because each was made to somebody else. Someone has to be able to change one of the promises.

Most organizations split cost, capacity, and capability across teams with different incentives. FinOps sees dollars, the capacity team sees headroom, and product and operations see capability: what the service has to do for its customers. Each view is accurate, and each is partial. A decision made from any one of them can satisfy that team’s measure while damaging the other two.

Not every team thinks capacity belongs at the table. A team that doesn’t get it treats the capacity team as janitors. I have seen the capacity team schedule a meeting with a team and hear, “Why would we need to talk to you about anything? I’m just going to ask for capacity, and you’re going to give it to us.” You have to laugh, because in a world of AI capacity shortages, computers that cost real money, and several ways to pay for them, it is complicated. The teams that got it understood that cloud capacity and cloud cost are an engineering function, and that the capacity team might bring things to the table they hadn’t thought about: different ways to pay, different ways to commit, and conversations that need to happen with a provider before anyone assumes they will be able to get 2,000 A100s or H100s or GB200s.

The capacity organization connects their work, which can be an influential role without giving it authority over every participant. The SRE literature makes a strong case for SRE involvement in capacity planning and is careful about where that involvement begins. Site Reliability Engineering makes an SRE team responsible for the capacity planning “of their service(s),” says that “the business or the product must establish” the availability target, and notes that few services begin their lifecycle with SRE support.³ I agree. What I reject is the broader inference that owning availability makes SRE the owner of enterprise capacity planning.

In a large organization, decisions about supply, investment, and future customer obligations can be underway before a service reaches an SRE team, if it ever does. Think of a large power-generation operation: the people running the plant are indispensable to understanding what it can deliver, but that expertise doesn’t by itself give them authority over every future customer agreement, financing decision, or expansion project. An enterprise capacity function has to work that far upstream, shaping the promise before a launch team discovers that it depends on supply nobody arranged, and still listen when an operator says an apparently available resource cannot yet support the work safely. Coordinating a plan does not make us more qualified than everyone supplying its evidence.

The nouns that change a meeting

A surprising amount of trouble can fit inside the sentence “We planned for it.” Before the discussion turns into an argument about who failed to deliver, I want to know what planning meant to each person involved. Did we estimate the demand, authorize money, ask for resources, or obtain an actual commitment to supply them? Those are all useful activities, but they leave us in very different positions when the launch date arrives.

You don’t need to interrupt every meeting with a vocabulary lesson, but you do need to intervene when two people use the same word for things that lead to incompatible actions. The SRE book tells a service level objective (a target) from a service level agreement (a contract with consequences) by asking what happens if it isn’t met.⁶ That question sorts this whole list. A missed forecast is revised, a missed target disappoints someone, and a budget overrun has to be explained. A declined request leaves us where we started, a reservation does whatever its terms say, and a broken commitment lands on whoever relied on it.

Three consequences make the SKU a meeting noun. The catalog prices SKUs, so price and commitment conversations are SKU conversations: commitments discount or reserve particular SKUs, and moving work to a different SKU can strand a commitment Chapter 1’s arithmetic still counts. Supply concentrates at the SKU: quota is tracked per family, shortages are shortages of one SKU while neighboring sizes remain available, and the reservation products that hold supply are SKU-specific, as Chapter 10 records for Azure’s unsupported GPU families. And the SKU choice is an engineering choice with a price attached: two SKUs can run the same workload at very different speeds, and the differences that matter — memory bandwidth, local disk, network throughput, an accelerator — rarely show up in a price comparison. That is why SKU selection appears among the conflicts the committee later in this chapter exists to rule on. A request is what someone wants; the SKU is the thing that would actually be bought, and the two need to stay separate in the record.

Who can change the promise?

In our portfolio, the full rollout would take the expected peak to 14,000 requests per second, above the 12,000 the web service can carry after losing a failure group. Eight batch workers could support a smaller first stage, and sixteen new workers might be ready in about six weeks. The arithmetic cannot tell the batch owner to wait or the business which customers should enter first.

The capacity team hears about every row; the last column says who else must. The other columns often name different people: Procurement can relay the supplier’s estimate without being able to improve it, and SRE can establish what the service survives without the authority to promise customers less. The last column fails quietly: a condition changes, and the person relying on it hears last.

The capacity lead has plenty to do without quietly acquiring those powers. We can challenge an assumption, recommend an option, maintain the combined account of the decision, and make it clear when the pieces don’t fit. What we cannot do is borrow the batch workers, narrow the customer promise, and report that the launch problem has been solved before the affected people have agreed to any of it.

Authority also comes in more than one form. A budget owner can approve spending within a delegated limit, a reliability or security review can stop a launch that doesn’t pass it, and nearly anyone can delay a decision by not answering. Naming one project owner gives us a starting contact, and from there we have to understand enough of the organization to avoid asking someone to accept a consequence they cannot control.

Microsoft’s Cloud Adoption Framework gives us a first draft of the map. In its shared-management model, platform teams provide shared services and guardrails and workload teams operate autonomously within them, and the same guidance asks for primary and backup owners for each responsibility.⁷ Capacity decisions sit on that seam. When two workloads need the same scarce capacity, I would find out who chooses between them before the urgent meeting rather than during it.

When agreement does not arrive

Some capacity conflicts have no arrangement that satisfies everyone. Suppose the batch owner cannot accept a delay, the business will not stage the rollout, and additional supply cannot be ready in time. Being more collaborative will not by itself create a missing resource.

At that point, the useful work is to explain the alternatives and their consequences clearly enough that somebody with authority can choose. A full rollout exposes the service under the modeled failure. Delaying it has a business consequence. Taking the batch workers without agreement transfers the problem to another customer. None of those facts should disappear because the meeting wants a green status.

Each option also expires. New workers that need six weeks cannot help a launch due within the month, however quickly the money is approved, and the batch loan works only if the workers return in time for the batch work to catch up. I worry more about a decision that stalls than one that is refused: an escalation that leaves out those dates invites “let’s revisit next week,” by which time an option may be gone.

The person or forum making the choice has to be able to change the obligations together. In your organization that might be a business executive, a technology executive, or a joint investment forum; the title matters less than the authority and whether you can reach it before the decision is made by default. I prefer to escalate with the other parties rather than about them. If the product lead and the batch owner agree that a one-page account of the options is fair, the executive can spend the meeting choosing instead of deciding whose version to believe.

Sometimes the person with authority chooses the option you argued against, and sometimes the argument was never really about capacity. Executives at different levels have agendas, and capacity and cost make a convenient lever. I experienced this with an executive who wanted to encourage teams to move capacity from public cloud to private cloud. The teams I ran came up with objective numbers, from the actual data and the actual cost data, and they concluded that the private cloud wasn’t measurably cheaper; in many cases it was a wash once you added the cost of labor and the risk associated with the supply chain. That gave us an opportunity to sit down with leadership and explain that when the contract with the provider was negotiated, we had factored in the cost of private at the time, and there really was no substantial difference. Our projections also said that shortages in RAM would drive the cost of private up substantially.

Even so, if an executive believes private is going to be cheaper than public, the executive is usually going to do it, and it might not be your job to die on that hill. Your job is to put an objective input into the conversation. And I believe this firmly: my career has suffered because I didn’t stop and ask whether that was what the executive wanted to hear. From a capacity-and-cost perspective, suffering consequences for the truth is better than failing at your job.

The launch is a less dramatic version of the same thing. If the person with authority approves the full rollout knowing what exposure they are accepting, and the promise is theirs to change, the decision is theirs. My job then is to agree with the business and operations on what the service will do if a group fails during the rollout, and to watch for the exposure growing.

Either way, I am wary of a record that says “accepted risk” without saying who accepted what. Keep the choice, its scope and deadline, the objections, and what would cause us to reconsider. If a nonnegotiable obligation is still unmet, keep it visible as unresolved. Otherwise the record can imply consent that nobody gave, and the capacity team becomes the accidental owner of a promise it was never entitled to change.

You may leave that discussion having been helpful without having been popular. Clarity about an infeasible promise is part of the job, especially when the organization would rather hear that another optimization will somehow make the arithmetic work.

When you are the one escalated on

Escalation in capacity and cost happens just about every day. Someone is going to escalate on you, especially when there is a shortage or a request you can’t satisfy, and some managers will be quick to blame you for it. Capacity is easy to blame, especially when an engineering decision has gone badly; it is the scapegoat. Your team isn’t responsible for the reality. It is responsible for reporting on the reality, and for getting people to prepare for the part of it that can be predicted. The more critical the project, the higher the escalation goes. I have been escalated on to the CTO, the CEO, an executive vice president, a vice president, and my own manager, and a newly established capacity team that hasn’t built its relationships yet will see escalations go to everybody.

The scene goes something like this. A team is very late. It hasn’t delivered the project on time, hasn’t done its homework, and hasn’t come to the monthly meetings, and now it shows up with a request that is simply impossible: “Tomorrow I need 200 of NVIDIA’s latest GPUs, and they need to be in that data center.” You call them and say that the provider doesn’t even have them in that data center. You aren’t saying it to say no, or to get them in trouble; you’re saying it because it’s true. Sometimes their next move is to email the CTO about how unresponsive you are to their needs. That is when it really helps that the CTO knows your name, knows you have the worst job in the company, and understands that you have done everything you can to prepare. The best case is a reply that says, “Work with the capacity team; do whatever they need you to do.” I have also had the executive an escalation went to call me up and laugh: “Do they even know what’s going on here? Do they think I can solve this?” The worst case is an executive who has no idea how capacity works, and that is your fault. Running capacity means having relationships with people several levels above you, and knowing the executives who will be escalated to before the escalation arrives.

When it happens, be ready at a moment’s notice to show all the inputs, all the outputs, and all the data, and to say: here is why we are where we are, these are the decisions that were made, and this is the situation we are all in. Someone who escalates on a capacity team is pointing a finger, and it is important not to point it back. If capacity is doing its job well, executives start to see it as a defense lawyer against uncertainty, a partner to team up with to manage risk.

There is no escalation of reality. Officially there is usually an executive, often the CTO, who can step in, but more often than not the cause of a capacity escalation has nothing to do with anything management can control. It is physics, or electricity, or the reality of supply. Someone who can’t use a data center because there aren’t enough GPUs in it can escalate all they want; escalation will not change import and export controls, supply-chain difficulties, or power limits. Large companies tend to believe that if you escalate high enough, you will find an executive who can solve the problem. Problems like these are solved by people doing the right analysis and preparing, which owes something to Jocko Willink and Leif Babin’s idea of extreme ownership.⁸ Sometimes a provider can’t follow through on an agreement, and the answer is to go and talk to another provider; Volume II, Chapter 19 takes up what a second provider is for. Often the best escalation is a contingency planned ahead of time.

Some conflicts do need a ruling, usually over utilization or SKU selection. For those, one of the best things you can do is establish a committee of qualified technical people to bring cases to: a sort of Supreme Court of cloud cost and cloud capacity. It should be a group rather than an individual, preferably with some members from the organizations doing the escalating, and at a company of thousands of employees people can feel somewhat honored to be part of it. Bring it only the toughest questions, maybe five or six big ones a year, each with all the evidence. When you step back, it isn’t the capacity team making the decision, and that defuses a good deal of escalation. More people and an objective review should produce more reasonable decisions, although that isn’t always the case.

Visibility without agency

I support making useful cost information available. I become less enthusiastic when that turns into an expectation that everyone should act as a part-time cloud accountant, including people who cannot change the decisions driving their bill.

The FinOps principles hold that “fast feedback loops result in more efficient behavior,” and, as the introduction noted, they already centralize rate, commitment, and discount decisions. Their ownership principle carries a condition too: product teams manage their usage “against budgets they help control.”⁹ Feedback changes behavior when the person receiving it controls the input. If a team doesn’t really have control over the cost decisions, sharing cost data with them isn’t helping.

A large consumer that controls its architecture but sees none of its cost is the case those principles address, and I would close that gap quickly. The other case is the long tail of small applications on the introduction’s shared platform, which Chapter 1 prices at $60,000 per thirty days and Volume II, Chapter 15 examines as a cohort. The platform team can improve that aggregate in ways none of the application owners can, so the owners need information tied to choices they have, such as a usage allowance or a way to request more capacity. Nobody needs to attend an efficiency review merely because we can produce a chart with their project on it.

An innovation program is a third arrangement: an explicitly funded period in which discovery takes precedence over efficiency. It still needs a boundary and a review, but treating every temporary inefficiency as a mistake would undermine the reason the program was funded.

Attribution, a report, a charge, and the authority to optimize can each go to a different person, and Volume II, Chapter 17 takes up how showback and chargeback create useful incentives when they reach the right ones. Reporting on a responsibility without supplying any agency over it can become a remarkably elaborate way of making people frustrated.

Find the people who already know

Before inventing a new demand-intelligence process, look for the planning work the company already does. Customer-facing teams may know onboarding and migration dates, Product may understand which features change usage, and Finance may recognize a business cycle that doesn’t appear in our technical telemetry. Regional teams can explain why a calendar assumption is wrong for their market. A specialist may know that next month’s maintenance will reduce the rate available to customers even if demand stays flat.

Ask how these people forecast their work, what units they use, and where they expect uncertainty. Then involve them in translating their answers. A customer-account forecast needs assumptions about adoption, activity, mix, and timing before it becomes a request forecast, while an annual financial plan can conceal the short peak that determines how much supply we need. If we turn the business plan into an unexplained technical multiplier, we have kept a number while discarding much of what made the conversation valuable.

They won’t all use the same method, and they don’t need to. A database specialist’s maintenance-aware limit, a product planner’s rollout scenarios, Finance’s spending plan, and a supplier’s delivery range describe different things. What we need is the basis, units, timing, conditions, and authority behind each, explained well enough that the people relying on the results can question them.

Some of the information will be sensitive. We may need a planning range and a readiness date without every detail of the customer discussion behind them. Work out what can be shared and who can revisit it, so that the capacity decision gets the signal it requires without creating a new problem for the person supplying it. Demanding unrestricted visibility is an easy way to lose access to useful information altogether.

For our launch, that means bringing the product plan, the operators’ evidence, the batch customer’s deadline, and the financial obligations together while somebody can still change the arrangement. Chapter 4 works through that decision with the arithmetic on the page, then comes back after the launch to see which of these people’s assumptions held.

Notes and sources

1. Tim O’Brien, “It’s Not That Simple”, Medium, June 21, 2026. The opening passage adapts the author’s description of recurring conversations with Finance.↩︎

2. FinOps Foundation, “FinOps Personas”, checked October 3, 2026, which calls personas “broad stakeholder groups that must collaborate, not individual people.” The four-party grouping and the authority map are the author’s.↩︎

3. Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy, eds., Site Reliability Engineering (O’Reilly, 2016), Chapter 1, “Introduction”, on SRE responsibilities and availability targets, and Chapter 32, “The Evolving SRE Engagement Model”, on services without SRE support. Both describe Google’s practice when the book was written; the conclusion about enterprise capacity authority is the author’s.↩︎

4. Beyer et al., Site Reliability Engineering, Chapter 18, “Software Engineering in SRE”, quoted from the Auxon case study. Auxon was an internal Google tool; the connection to this chapter’s launch is the author’s.↩︎

5. Microsoft Learn, “Azure virtual machine sizes naming conventions”, checked October 6, 2026. Field order (family, sub-family, vCPUs, additive features, accelerator, version), the additive-feature letters, and the rule that only specialized SKUs launched from the third quarter of 2020 carry the accelerator in the name. The Standard_D4s_v5 reading follows the page’s conventions and examples.↩︎

6. Beyer et al., Site Reliability Engineering, Chapter 4, “Service Level Objectives”, which asks “what happens if the SLOs aren’t met?” to tell SLOs from SLAs. Applying the question to the other terms is the author’s extension.↩︎

7. Microsoft Learn, “Prepare your organization for the cloud”, Cloud Adoption Framework, checked October 3, 2026. Describes centralized, shared-management, and decentralized operating models and recommends primary and backup owners for each responsibility. Applying the model to capacity decisions is the author’s.↩︎

8. Jocko Willink and Leif Babin, Extreme Ownership: How U.S. Navy SEALs Lead and Win (St. Martin’s Press, 2015), which argues that leaders own everything that affects their mission’s outcome rather than assigning the failure to others. The application to capacity escalation is the author’s.↩︎

9. FinOps Foundation, “FinOps Principles”, checked October 3, 2026, quoted from the principles on accessible data and ownership. Treating “budgets they help control” as the boundary of the case for visibility is the author’s reading.↩︎