10. People: the room around the math

In short: capacity is a handshake among capital, supply and demand, and the planner brokers it. Then come the seams, overrides, reorganizations and gaming.

Every capacity plan is a handshake among three parties. Capital is finance and the leaders who set the envelope: it has the money, and wants it to buy something. Demand is the teams that launch and grow products, and the shared services they call: they have plans, and want capacity on time. Supply is whoever turns money into running machines: the supply chain, the sites, the fleet. It has lead times and contracts, and wants a signal it can buy against.

None of the three can close the deal alone. Capital can approve, but it can't deliver. Demand can declare, but it can't fund. Supply can build, but only against a signal that's often late, padded or both. That's where the planner sits: in the middle, usually owning no capacity and no budget.

So what does a planner trade in? In my experience, four things:

• Information: what's coming, who holds what, and what supply can really do by when.
• Timing: when each question must be asked, so the answer arrives before the order has to be placed.
• Trust: numbers that hold up, from a planner who doesn't pad its own.
• Credible commitments: signatures that turn one party's promise into something the others can buy against.

The planner owes each corner something different. Capital gets numbers that hold, a cut line that names what falls below it, and early warning of finance decisions dressed as capacity ones. Supply gets signed demand before each commit point, with its stage and range, not churn. Demand gets the same picture as everyone else, a "no" that comes with a path, and capacity back when it gives some up.

The paper's two claims sit on the triangle's edges. A coefficient is the price demand pays capital for what supply provides, so it holds only while all three agree on it. And approval is capital's handshake with demand; allocation is supply's. The gap between them is the third seam (Section 10.1).

A shared service sits on two corners at once: it's supply to its callers and demand to the fleet. That's why the first seam below exists. Section 10.1's Figure 41 draws the triangle, with the seams on its edges.

A platform lead gets blamed for a shortage in one meeting and for the bill in the next. It isn't personal. In my experience, the most persistent conflict in this field is structural, and it runs along three seams.

The first seam runs between product and platform. Product is rewarded for launches and growth; platform is measured on cost and reliability, and blamed for both. Section 5.2's identity sits on this seam: volume belongs to product, coefficient and rate to platform. Neither can manage cost alone; the mechanisms keep the conflict productive, not personal.

The second runs between planning and finance. Planning thinks in machines, megawatts and lead times; finance, in capital and operating spend, depreciation schedules, and a forecast already given to its own leadership. Some decisions that look purely technical cross this seam:

• A third-party bridge turns capital into operating spend.
• Deferring a decommission extends depreciation on an asset finance had written off its plan.
• An early order commits cash in one fiscal year for capacity charged back over several. So a plan reconciled only to the rate can approve spend the cash budget can't carry.

Each is a finance decision disguised as a capacity decision. Bring finance in only to set the rate, and you'll discover them at the quarterly close.

Finance often distrusts planning's numbers, and it often has reasons. Think of inflated asks, double counting, missing baselines and "just in case" capacity. Add savings promised and never seen, and teams that can't explain their own use of shared services. Trust comes back the slow way. Use one template and one format for every team, so asks can be compared. Put each team's baseline and last year's actual beside its ask (mechanism 2). Ask for a short business case tying the ask to growth, a launch, efficiency or risk. And show constrained supply against ranked demand on one page, with a way to drill down. None of it is clever. It's what makes an ask believable to someone who's been burned before.

The third seam runs between planning and supply, and it's where "approval is not allocation" actually lives. Planning approves in a common unit; supply buys parts, racks and buildings on dated contracts with penalties. Demand that changes inside supply's lead time makes every supplier look late; supply that commits without naming its risks makes every approval look firm. So the seam needs five artifacts both sides sign. Four are an answer to every approved ask (Section 8.3), pegging (Section 6.4), change bands and who pays beyond them (Section 6.5), and shortage rules agreed in advance (Section 9.3). The fifth is a definition of done for each handoff: what "delivered," "live" and "ready for service" mean and who accepts each, anchored on Hixson and Guliani's "Ready to serve" [6]. The SRE chapter warns against treating "ready" as binary, so a definition can have phases [7]. Supply gets matching decision rights (Section 9.2). An approval becomes firm when supply has answered it, not when the forum has voted. Figure 41 puts the three seams on the triangle's edges, with what has to cross each.

Overrides. Sometimes a senior leader will move a launch above the cut line for a reason the forum couldn't weigh, such as a contract or public commitment. Make overrides:

• Allowed: the executive who owns the trade-off may make it.
• Explicit: the log records who decided, what moved up and what moved down.
• Priced: any bridge the override needs is charged to it.

A rule of thumb from my experience: a forum overridden once a year is working. One overridden monthly is not the decision-maker, and the fix is to bring the overriding executive into it.

Reorganizations. A reorg can orphan a coefficient, unnoticed until it drifts. So attach every commitment, coefficient and unallocated line to a durable object (a product line, a cost center, a service identity), never a person or team name. Treat the reorg as a re-sign event: within one cycle, the new leader re-signs or formally amends the inherited commitment; until then it stands. An orphaned coefficient gets an interim owner and a transfer date.

A new owner needs more than a signature request, though. Engineers often know their own integration path well and the shared service's operating model barely. That means how a request is sized, what quota means across many sites, and why one launch waits on another. So onboard a new leader, or a new team, in one sitting. Show it what it asked for last year and what it used, its coefficients and who owns them, the commitments it inherits, and the dates that matter. Size its first ask with it, not for it. And tell it who to call when an alert fires or a launch is blocked. A team that understands its first ask usually writes a better second one.

Orphans don't only come from reorganizations. Some work falls between charters from the start. For example, if reliability engineering's charter covers serving and nothing else, the batch pipelines that feed serving may belong to no one. When they fail, the product degrades or loses features without a clean outage, so no one's alarms go off. That kind of work is often the work that matters. So once a year, lay the charters over the chain that delivers the product, end to end, and name an owner for every gap. Planning can hold a gap until someone takes it.

Planning's own misses. Finance remembers idle capacity; product remembers the launch that slipped. Left implicit, the shortage-to-idle ratios of Sections 6.3 and 6.5 get set by whichever critic spoke last. So finance and product sign them at the annual cycle, per supply layer and kind of demand, with supply supplying the cost of idle and the liability terms. Reliability engineering set the precedent for availability: "The business or the product must establish the system's availability target" [79]. The SRE chapter says it for capacity: base buffer sizes on "SLOs and business impact," with product, SRE and finance aligned on "risk tolerance, and cost-benefit thresholds" [7]. What this paper adds is a signed number per layer. Illustratively, that means Section 6.5's ratios for persistent demand, and near 1:1 for transient peaks. Surplus within them is the plan working, not a planning failure.

The SRE chapter ties capacity planning to error budgets (Section 6.3) [7]. A signed ratio makes that budget a number you can count. One way to count it: a 4 : 1 ratio covers the eighth of ten outcomes. So if each launch is bought at its own cover point, about one launch in five should need a bridge at that layer. Call it a shortage budget. For example, if 20 launches a year buy machines this way, expect about four bridges. Far fewer, two years running, and the ranges are padded. Far more, and the stage records run optimistic or the ratio is too low. It's a backtest of the ratio, the kind the chapter recommends for choosing a confidence level [7]. One caution: launches tied to one driver spend the budget together (Section 6.6). This is an analogy, not a result.

When a miss happens anyway, the funnel and the decomposition show where it arose, often shared. Resolve the launch before assigning cause.

Shocks. When a big shock hits (a new site slips by quarters, a key supplier stalls), the informal channels that planning runs on can stop overnight. The planner has to replace them on purpose, and fast. Give every team the same short briefing: the state of the fleet, what's known about the shock this week, where supply stands, and where finance stands. Then work through that team's own forecast and requirements with it. In my judgment, the same picture for everyone keeps rumors from turning into forecasts. It also makes the hard trades (tighter forecasts, reworked asks, moving tenants off constrained capacity, a bridge) feel shared rather than imposed. While supply is unknown, a simple holding policy helps. Everyone stays at current capacity plus approved growth and buffers, and everything else goes through a stricter review. The policy also says when it will be revisited.

Re-baseline. After a shock, or when plan and actual have drifted far apart, the old plan stops being a useful baseline. In my experience, patching it line by line rarely converges. It works better to pick a date, take a snapshot of actuals, and make that the new baseline. Then work through the teams one by one, brokering trades between those holding excess and those running short (Section 6.4). Hold the utilization floor agreed beforehand: capacity that keeps a team below it is excess, and goes back into the shared reserve, under the landing rule (mechanism 8). Then restart the forecast from the new baseline, with each team's declarations refreshed. Section 5.3 restates a coefficient's history at a break; this restates the plan's. Section 5.2 suggests making it routine rather than a one-off.

Say an urgent email arrives the week after the cut line was drawn: an undeclared launch needs capacity now. If that ask costs its sender nothing extra, you've taught the whole organization when to file.

Capacity requests are budgets in hardware units, pathologies included. People "lie in the formulation of budgets" and "game the realisation" [95], and organizations get the behavior they pay for [96]. The common games, and their counters:

The last row matters most: planning that pads its own numbers can't credibly ask anyone else not to. Figure 42 pins each game to the point in the cycle where it pays off.

Past a point, legitimacy matters more than precision in whether anyone acts on the number. Ostrom's design principles for durable commons map onto shared infrastructure [97], and one matters most: a channel to challenge coefficients. A consumer who can challenge a coefficient, and sometimes wins, trusts the rest of the bill. Figure 43 draws the channel with three parts the paper already has. The first two are the coefficient register, with each coefficient published and versioned (mechanism 3), and the forum, which rules and keeps the decision log (mechanism 10). The third is the discontinuity register (mechanism 6).

Escalate in steps: nudges before bills, bills before constraints. Spotify nudged only "teams that are growing faster than Spotify's business" [98]. Neither showback nor chargeback is more mature than the other [99], but chargeback without the right to change consumption is a tax.

Change in the right order. Moving from team-held reservations to shared pools asks a team to trade a certain asset for a promise. So earn it: prove fulfillment first, pool the buffer before the base, and give returners a right of recall. Move to attributed cost only after a full cycle of showback.

Give each audience what it needs. Executives need one page of decisions. It shows what is above and below the cut line, and what just below it could be funded and at what cost. It also shows what above it carries fulfillment risk and until when, and any decision needed today. Engineers need their own coefficient, reproducible from their telemetry, with forecast error treated as data, not fault.

In between, the planner translates. Product speaks in launches, users and requests per second. Supply speaks in shapes, sites and dates. Finance speaks in dollars, years and depreciation. In my experience, much of planning is saying one party's need in another party's words without losing what it meant. Reviews help when every line is one of three things: a fact (measured), an assumption (someone's judgment, with an owner) or an ask (a decision needed, by when). A review that mixes them becomes a status update; one that separates them produces decisions.

Where planning reports matters less than who owns the cut line. Inside infrastructure, planning knows supply but is suspected of favoring it; inside finance, it's trusted on numbers but not on shapes. Either works if the forum owns the cut line, and planning publishes the same indicators about the infrastructure organization's coefficients as about consumers' forecasts. And don't let brokering live in one head: log every trade and rotate the role, or unlogged trades become a second, invisible arbitration forum.