The Relationship Discipline

How to read this chapter

This chapter is about learning of changes early, working with specialists, and checking evidence when someone has an interest in the answer. Together they are the practice the Introduction called demand intelligence, and the main way a capacity team sees the systems that drive consumption.

1. Make early information worth sharing — protecting sources, and the exchange that gets you told early.
2. Keep the relationship bigger than one number — diagnosing a missed forecast before blaming its source.
3. Work through the specialists — hiring and partnering for expertise, and what “validated” means.
4. When the answer has a sponsor — vested interests, including our own.
5. Special projects are part of the job — scoped architecture investigations and how they end.
6. Apologies, jokes, and hypnosis — reaching a feasible answer among four parties.
7. Tags, borrowed projects, and reasons to participate — showback, conditional chargeback, and disputed charges.

The lesson to carry: people share early information when sharing it has helped them before, and every consequential number, ours included, needs someone other than its sponsor who can check it.

Make early information worth sharing

Running capacity at scale, you hear “I’m not supposed to tell you this, but…” a lot. An engineering leader says, “I’m not supposed to tell you that we’re not going to deliver on time — but we’re not going to deliver on time, so we won’t need 1 million cores by next month.” A provider says, “We’re having issues in this data center, and I need you not to get me in trouble for telling you this, but if you ask us for this much capacity, it’s not going to work.” Neither of them had to say anything.

The last thing I want to do is stand up in a planning meeting and say, “Joe called me last month and told me…”. My job is to reverse-engineer a way to make the fact known without getting the source in trouble, including making sure a junior engineer does not get fired for telling me. Often that means adjusting the forecast and the provider conversations quietly, and saying there is going to be an attenuation of demand in the next quarter rather than that a particular project will miss its deadline. “I’m not going to tell you what the source of this information was” is a sentence I say a lot. A capacity manager is something like a journalist: finding information, looking at the data, and protecting the people who give early signals. We are not there to get people in trouble.

Some of the most useful signals are buried in a schedule. Private capacity starts with hardware that takes months to arrive; then, if you run your own facilities, racks, space, and power; then several teams setting up the platform; then the applications. It is a Gantt chart of delay and failure, with at least 10 or 11 sources to query frequently, none of which wants to be the reason for the delay. Somebody has to translate the status updates, pick up the phone to ask what someone really meant by a complication with the racks being shipped from Mexico, and tell application teams six or seven levels removed what it does to their dates. In one case the schedule had slipped so far that the capacity would have become available during a really problematic time of the year, so the data-center expansion was moved back another year.

Weather is early information too, and nobody has to take a risk to share it. Capacity does not run the business, but when severe weather was forecast in the East, the capacity team could pick up the phone, call the operations center, and say, “Move workloads out of East tomorrow. We need to move them to West.” Then came the second conversation, about increasing capacity in West to carry the extra work, because the region taking the load needs room for it before the load arrives. The precaution is not theoretical. On the night of June 29, 2012, a derecho, a fast-moving line of violent thunderstorms, swept through Northern Virginia; the power failure in one Amazon Web Services Availability Zone took Netflix, Instagram, and Pinterest down for hours.¹ Four months later, as Hurricane Sandy hit New York, Stack Exchange moved its sites from a Manhattan data center running on generator power to its secondary data center in Oregon “as a precaution.” By the next day the facility’s operator was preparing to shut off all power, because refueling trucks could not reach the building.²

What made people willing to tell us these things was mostly that we listened and went out of our way to help. Listening is rarer in IT departments than it should be, and taking the time to understand somebody, with some empathy, is when people start trusting you. Providers are no different: I want to be the customer who does not only consume but asks, “You’ve helped us; what can I do to help you?”, so that when things get tough, the provider comes to us first. This is one of the most relational jobs in a company, won or lost by how many people you know and whether those relationships work. A good relationship with everybody is not always possible, but it should be the goal.

Help is also the return a source should see. In the constructed portfolio, Product’s rollout plan is what lets the capacity team arrange staging and temporary supply before the demand appears. If the plan reverses the last one, the person bringing it should not have to defend the change.

Settle the terms before the information arrives, and say them out loud rather than leaving them to goodwill. The person supplying a plan should know what it will become in Volume I, Chapter 3’s vocabulary: a forecast we plan against, a request we will act on, or, if we will hold capacity against it, something close to a reservation. They should know who will see it; as Volume I, Chapter 3 suggested, sensitive commercial detail can often travel as a range and a readiness date, checked by someone authorized to see what lies behind it. And they should know what the disclosure will not trigger. If mentioning a possible cancellation automatically cuts a team’s funding before it has decided, expect very careful wording in the next update; I would let the possibility change our scenarios and leave the funding alone until the team decides.

Keep the relationship bigger than one number

A slipped launch is an opportunity to ask what we misunderstood, including what the capacity team may have done to the original answer. Did the customer offer a range that we converted into a single date? Did a prerequisite fail? Those questions join the three Chapter 14 asked of a missed adjustment, and I would want them settled before deciding that this customer gives us unreliable forecasts.

An owner and a timestamp can make a forecast register look disciplined while it still misrepresents what the owner said. Let that person see how the business plan became resource demand, and give them a way to correct the translation without first winning an argument with its author.

Alongside accuracy, I would watch how much notice each source gives us: the time between when the event record says the information was supplied and when the change arrived. A shrinking interval can show that people have stopped telling us things before anyone says so.

Work through the specialists

When I interview someone about databases, I want to hear about the systems they have lived with: what changed in the use of the data, which decision became painful, and what they did when the original approach stopped working. I have a particular interest in schema regret. The explanation of a compromise tells me more than a list of products the candidate claims to know.³

That needs enough trust for a specialist to tell us where a measurement is incomplete without expecting a performance review. For a material decision, I would use the following division of responsibility:

That table is not a requirement for four departments and four signatures. A small decision may deserve a short peer review, while a consequential architecture change may justify having another specialist reproduce a material part of the result; a central team that insists on rerunning every measurement will become the reason the organization cannot finish measuring anything.

Reviewers do need access to the observations and conditions behind the conclusion: the time window, workload mix, configuration, calculation, and exclusions, subject to the appropriate access controls. They also need to say which check they performed. Rechecking the arithmetic, reviewing the method, reproducing the result, confirming that it applies to our workload, and observing the promised behavior after deployment are different claims. Whenever someone writes “validated” next to a number, I want to know which of them it means and who made it.

Forecasts need particular care. A reviewer can examine the inputs, challenge the method, and compare previous predictions with outcomes, but cannot certify what a future customer will do. A measured service rate and an assumption about how much work the business will generate may belong in the same plan; they arrived there by different routes.

When the answer has a sponsor

Ask me to name an enemy of cloud cost and capacity management and my answer is people with vested interests in outcomes. Before anyone on the capacity team gets too comfortable with that answer, it includes us.

A preferred architecture needs a business case, and a savings program needs savings. Under that pressure, it can become surprisingly easy to select the interval in which an improvement looks strongest, omit a cost that somebody else will pay, or stop investigating once the result supports the presentation.

Most of this is ordinary, and I have to resist making my own easy inference. Engineering teams make ideal assumptions, which I do not find surprising or concerning: engineering leaders want to achieve things and get promoted, and a business owner is supposed to care about the customer. Part of the capacity team’s job is to correct bad assumptions and bad math, politely and professionally, and to make sure its own analysis stands on its own, because statistics can be pushed in many directions. Deliberate falsification, or omitting data to reach a result, does happen too. An error, a defensible but disputed assumption, selective presentation, and deliberate falsification call for different responses.

An error is corrected where everyone who saw it will see the correction. A disputed assumption is carried both ways, with the name of whoever holds each version. Selective presentation calls for restoring the missing interval, cost, or failed run before anyone discusses the conclusion. Deliberate falsification is no longer a capacity question. At scale these questions run to hundreds of millions and billions of dollars, and a proposal that is off by hundreds of millions because of someone’s agenda is one I would take to whoever handles ethics and misconduct. Treating any of the first three as the fourth is a quick way to stop being told things, which is why the challenge goes to the evidence first.

A capacity manager is not technically an officer of the company but provides a financial assessment that officers rely on, and I treat that as a duty to report accurately, including when an executive wants a different answer, as with the private-cloud numbers in Volume I, Chapter 3. Much of the skill is telling people, politely, that the rules here differ from the rules in engineering. Preferring a database or a language and throwing everything at a slide deck to justify it is fine. Manipulating numbers that have consequences for shareholders crosses the line. Two things help a capacity team hold it: a partnership with Finance, which is used to these conversations, and knowing the conflict-of-interest rules that govern vendor conversations and pricing negotiations.

Consider a hypothetical proposal to optimize a service whose annual cost is $10 million. The team’s proposed budget is $8 million, so its presentation shows a saving of ($10m − $8m) ÷ $10m = 20 percent. Now suppose $2 million of the same work will be paid for by a shared platform. The enterprise still spends $8m + $2m = $10 million; the expense has moved without an enterprise saving. Before we congratulate ourselves on the percentage, I would like to know whether the proposal’s author understood that distinction, whether the platform agreed to carry the work, and what question the presentation was meant to answer.

Different claims need different questions:

Agreeing on the comparison before the result is known helps, and so does keeping the original observations when the method changes. Someone qualified to challenge the result must be able to do so without first asking its sponsor whether the challenge is welcome.

Our own savings report deserves exactly that treatment. If the capacity team is rewarded for reductions, someone outside it should be able to question its baseline and boundary, and if we justified a large reserve with a forecast, the original forecast needs to survive the arrival of less convenient demand data.

Special projects are part of the job

Working through specialist teams cannot mean waiting indefinitely for somebody else to investigate a consequential problem. Suppose a service’s projected resource requirement threatens the budget, but its engineering team is occupied with delivery and has no time to examine a different deployment. We ask for a revised estimate and receive the same estimate, perhaps in a newer template. At some point the capacity manager needs people who can go and find out what is behind it.

That is why I would retain an investigative engineering capability alongside forecasting, allocation, and customer work, whether by hiring a few specialists, assigning engineers to a focused project, or bringing in someone who understands the particular constraint. They need to read code and deployment configuration, design a comparison that includes the difficult parts of the workload, and explain what the result means for the business. They also need time. Filling their calendars with routine reporting and then asking why they have not challenged a multimillion-dollar architecture is a fairly efficient way to frustrate everybody.

High spend is one reason to begin an investigation; a smaller service with a critical dependency or an irreversible commitment can be another. A useful investigation may also conclude that the existing design is the right one, and if we only recognize success when we discover a cheaper alternative, we give our investigators a reason to favor the result we wanted.

When architecture becomes a capacity question

An engineering team can reasonably regard deployment choices as its responsibility, so a capacity team arriving with questions may feel like a challenge to its competence. I understand that reaction. I would still ask when the decision affects the enterprise budget or leaves other customers unable to obtain resources, and respecting the team includes learning why it made the original choice.

Take “containers versus VMs,” a phrase that makes an architecture comparison sound much more settled than it is. Kubernetes runs containers on nodes that may themselves be virtual or physical machines, and its scheduler places pods by what their containers request rather than by what they use.⁴ The bill can depend less on the label than on how generously teams set requests and how well the work packs onto the nodes, so before comparing costs we need the actual configurations, what runs underneath them, and the operating work each requires.

Suppose, in a separate hypothetical example, a preliminary comparison puts the difference at $2 million per month, or $2 million × 12 = $24 million a year in recurring expenditure. That is worth investigating, although we have not yet measured a saving or established that either technology is inherently cheaper. Migration, parallel running, staff time, existing commitments, and changed service behavior could alter what the business can realize; Volume I, Chapter 13’s double bubble applies here.

With that much at stake, my inclination is to start the investigation and repair the organizational friction afterward. But the intervention has to earn its credibility: use representative demand, give the engineering team a chance to identify behavior we missed, and take its operating constraints seriously. If the alternative wins only because we removed recovery capacity or shifted work to a team whose costs are outside our model, I want that discovered before we take the result upstairs.

Starting without an invitation does not mean starting in secret. I would tell the team’s leader first and show them what we intend to examine. Before any test runs, I would ask what result would change their mind and say what would change ours; if we cannot agree on that, we have found the first useful question. The team should see the draft finding before anyone above it does, with time to correct it, and its written response should travel with the result. The team may still dislike the conclusion, but it will not have learned about it from someone else’s slide.

Give the investigation an ending

Before committing people to an investigation, I want a brief short enough for everyone affected to read:

• Decision: what the result could change, the money or service at stake, and who can act on it.
• Question: the disputed assumption, competing explanations, and the evidence that would distinguish them.
• Comparison: baseline period, workload, service and recovery conditions, and cost boundary, agreed before any result exists.
• People and allowance: the named specialists, the owning team’s part, and the time and money we will spend.
• Stopping point: the result, date, or spend that ends the work, including a finding that the existing design is right.
• Operator: which team would run a change, and who would maintain anything the investigation builds.

The last line matters more than it looks: an investigation that quietly creates another platform for the central team to maintain leaves us a much larger job than we intended.

If the proposal proceeds, agree how migration and operating responsibilities transfer and how the result will be assessed. Released capacity, reduced expenditure, and an avoided purchase are different results, as Volume I, Chapter 13 explains, and claiming one as another makes the next review harder. If the existing design wins, I would say so, with the reason, to the people who heard the original concern. If the investigation is inconclusive, keep the unresolved question rather than converting an unproven opportunity into delivered savings.

Apologies, jokes, and hypnosis

How do you get Finance, Business, Software Engineering, and SRE to agree when they want incompatible things?

Jokes and hypnosis.

The more accurate answer is apologies, jokes, and hypnosis. The hypnosis remains aspirational; most of the work is listening long enough to discover that we have misunderstood what at least one person needs.

This is the weekly Kobayashi Maru from the introduction. Ideally, everybody leaves feeling they found an answer together, which sounds wonderfully simple until you try to find it. Business may care about one customer’s launch more than the full rollout. Engineering may need room to test an approach rather than a permanent allocation. SRE may need a credible recovery option rather than duplication of everything, and Finance may fund a temporary transition if somebody can explain how it ends. I cannot assign those positions to people in advance. I have to hear what they say and be willing to change the option I brought into the room.

The listening has more mechanics than the joke admits. Before pushing back on a position, I want to restate it well enough that its owner accepts my version. Then it helps to separate what cannot move in the time available, such as a compliance rule, a service-level objective, or capacity already promised, from what can, such as instance family, region, or rollout timing. A position that sounds immovable can often become a testable question: what would need to be true for it to change? And the goal can stay fixed while the tactics move: “hit the budget” leaves far more room than “turn off autoscaling.”⁵

Then I need to show how the resulting option responds to each party, including the part it cannot satisfy. If our questions have disrupted a plan people worked hard on, an apology may be owed for that specific cost, such as the week a team spent answering us, without withdrawing the finding. Humor can help us have the conversation without pretending the disruption is enjoyable. Neither will make the resources infinite; if the requirements remain incompatible, the people who can change them need the one-page account of the options that Volume I, Chapter 3 describes. Helping a customer get to a feasible launch is far more useful than appearing at the end to announce that there is insufficient capacity.

Tags, borrowed projects, and reasons to participate

I have written about untagged resources in fiction, too. Redundant, the first novel in my trilogy The Condition Set, follows Rob Coleman, who runs the FinOps review that names the waste nobody wants to hear about, and I wrote it to capture the frustrations a FinOps team lives with. Untagged resources are one of them: the novel’s FinOps leaders complain that internal teams fail to tag their resources. Sometimes a fast-moving team launches before the ownership information catches up. There is also a more deliberate version, which I have encountered in practice: a new system appears under an existing group’s project or tags because that makes it less visible to cost and capacity management. The familiar label reassures the report while telling us very little about what the resource now supports.

I would establish the actual owner and purpose before interpreting the discrepancy. A wrong tag is not proof of concealment. But where a team is trying to avoid us, it is worth asking what avoidance buys it. If disclosure brings delay, blame, and another reporting obligation, reciting the tagging standard leaves the incentive almost untouched.

Robust showback, and chargeback where the organization can support it, have been very useful in my experience. Showback makes attributed cost visible to the groups responsible for it; chargeback sends those expenses into official budgets and accounting systems, which the FinOps Framework treats as the primary difference between them. The framework requires showback in any FinOps practice and considers neither more mature; chargeback depends on accounting policy, may not be worth its cost when spending maps to a single cost center or an easily allocated set, and needs a process for corrections after an accounting period closes.⁶ I agree with keeping the choice conditional: a mechanism that creates useful responsibility in one organization can create an argument over an unreliable allocation in another.

Shared costs need their own decision. The framework’s allocation guidance notes that most organizations fund some shared costs centrally, by an explicit decision it calls an “informed ignore,” and split others by fixed share, proportion, or a proxy metric. It also tracks metadata compliance and the share of cost that cannot be allocated.⁷ A borrowed tag satisfies both measures: it counts as compliant and keeps its cost out of the unallocated total. The first signal may come from the group whose project was borrowed, when it sees a charge for a system it does not run.

Tooling can repeat the mistake faithfully. Azure’s tag inheritance, for example, applies subscription and resource-group tags to the usage records of the resources beneath them without changing the resources’ own tags.⁸ If a new application is running under another team’s subscription, inheritance assigns it the wrong owner, and fixing the tag does not by itself repair an earlier month’s report. A platform team explaining consumption to its customers should agree the allocation basis with them, put a date on revisiting it, and check that inherited ownership is still correct.

The report has to distinguish direct costs, shared allocations with their basis, and ownership we have not yet resolved. An owner needs a practical way to dispute a line, especially when the report assigns a system the group does not operate. I would move a disputed line into the unresolved total, with a named person investigating it and a date for an answer, rather than leave it on the challenger’s bill or drop it from the report. Under chargeback, a correction should move it once the owner is known.

Participation also needs a return beyond a more accurate bill: help settling a shared-cost dispute, a credible view of upcoming demand, or an earlier answer to a capacity request because we heard about it earlier.

“Shared ownership makes it essential for people to communicate and cooperate.” There: a sentence ready for a book selling feelings. It sounds as if the problem has been solved, yet nobody has corrected a tag and the unanswered email is still in somebody’s inbox.

I would judge the arrangement by what those people can now do. Does the report reach someone who can change the resource’s use or explain it? Does answering us make their next decision easier? Some of the hardest conversations this produces concern capacity that looks idle and that somebody insists on keeping, which is where the next chapter begins.

---

Notes and sources

1. Amazon Web Services, “Summary of the AWS Service Event in the US East Region”, July 2, 2012, which describes “a large scale electrical storm which swept through the Northern Virginia area” and a power loss in one Availability Zone; NOAA/NWS Storm Prediction Center, “The Ohio Valley / Mid-Atlantic Derecho of June 2012”, which reports more than two million customers without power; Sean Ludwig, “Amazon Cloud Outage Takes Down Netflix, Instagram, Pinterest, & More”, VentureBeat, June 29, 2012. All checked October 4, 2026.↩︎

2. Kyle Brandt, “Failing Over Stack Overflow and Stack Exchange for Sandy”, Server Fault Blog, October 30, 2012, checked October 4, 2026.↩︎

3. Tim O’Brien, “Databases Will Break You (And They Should)”, September 7, 2025. Describes the author’s interviewing practice. Suggested interview answers are illustrative.↩︎

4. Kubernetes documentation, “Nodes” and “Resource Management for Pods and Containers”, accessed October 3, 2026. Nodes may be virtual or physical machines, and the scheduler refuses a placement whose container requests would exceed a node’s capacity, even when actual usage on the node is low. Establishes deployment-layer overlap and request-based placement, not a comparative cost advantage.↩︎

5. Tim O’Brien, “‘Predatory FinOps’: How to Spot It, Stop It, and Keep the Room Together”, September 30, 2025. The listening practices adapt the essay’s recommendations, which are proposed practice rather than evidence of results.↩︎

6. FinOps Foundation, FinOps Framework, “Invoicing & Chargeback”, accessed October 3, 2026. Identifies formal allocation to accounting budgets as the primary difference between showback and chargeback; says showback is always required and usable at any granularity, neither is more mature, and chargeback depends on accounting policy and may be unwarranted where costs map to a single or easily allocated set of cost centers; includes corrections after period close. The author’s experience and proposed practices are separate from the framework.↩︎

7. FinOps Foundation, FinOps Framework, “Allocation”, accessed October 3, 2026. Notes that most organizations fund some shared costs centrally and split others by fixed, proportional, or proxy-metric methods; describes an explicit decision to budget shared costs centrally as an “informed ignore”; lists metadata compliance and the percentage of cost that cannot be allocated among its KPIs. The borrowed-tag observation is the author’s.↩︎

8. Microsoft Learn, “Group and allocate costs using tag inheritance”, accessed October 3, 2026. Supported for EA, MCA, and MPA with Azure plan subscriptions; tags are applied to usage records, not resources. Purchases, and resources that emit no usage at a subscription scope, do not receive inherited subscription tags.↩︎