Without Surprise

Most of the decisions in this book start with a conversation about money. Go back to the case from the introduction: a demonstration has turned into a launch, and the service can take on the new work only as long as nothing fails. The additional capacity won’t arrive in time. One of the first questions from Finance is why the resources we are already paying for can’t do more of the work. That’s a fair question, and before we can answer it, or ask anyone to approve a purchase, we need to be able to say what the organization is paying for today and what would actually change if we did something different.

This is usually when savings enters the conversation. Somebody proposes making room for the launch by retiring the old environment in a migration, borrowing some batch workers, or shrinking a service that looks underused, and describes the result as money saved. Sometimes it is. Often the change is worth making but does something else: it moves an expense from one team’s report to another’s, or it avoids a purchase next quarter without reducing this month’s bill. When you are managing cost and capacity, these are the questions you need to be able to answer before making a decision.

Before you promise anyone savings, go and talk to the person who has to answer for the bill. You will often find that you both did the math right, you both like the change, and you are still talking about two different things.

Suppose an application will stop using some resources, but the organization has already committed to paying for them. Releasing those resources may let another team use them or avoid a purchase later, which is useful work. It just doesn’t cancel the payment. If we don’t follow the change through to the obligation, we can congratulate ourselves on a reduction that Finance will spend the next month trying to find.

To work through this, the chapter uses the constructed portfolio from the introduction: the customer-facing web service, a pool of batch workers, data platforms, a shared platform for many small applications, an AI assistant that drafts replies for the support team, and a migration with its old and new environments running side by side. Together they cost $448,000 over thirty days. The organization and its numbers are invented and chosen so that you can check every calculation. What matters is that each line calls for a different kind of decision.

By the end of the chapter, I want you to be able to take any line on that bill and say what work it supports, what we have already promised to pay, what the invoice leaves out, and whether a proposed change would remove the expense or only move it. We start with the vocabulary for describing how an expense behaves, then walk through the portfolio, follow two changes the launch might require, and look at the costs the invoice doesn’t show. That still won’t tell us whether the service can handle the work we are asking of it. Knowing the price of a resource is different from knowing it will be there when we need it, and that is the subject of the next chapter.

Several dimensions of the same dollar

Start with some familiar vocabulary: fixed, variable, committed, metered. These are useful words, but trouble starts when we treat them as four separate boxes and assume that placing an expense in one tells us how to manage it. A payment can be fixed for the next month and avoidable next year; metered consumption can be covered by a commitment, and a service whose usage varies can still carry a minimum payment. The period and the agreement matter as much as the label.

When I ask about cost behavior, I want to know what happens as demand changes. Another request might add a small charge, or it might fit inside a service whose cost stays level until we need another instance. Additional data might create a charge when we store it and another when somebody reads it. This is where an engineer who understands the application and a finance partner who understands the agreement need to look at the same change, because a useful answer has to describe both the work and the period over which the expense can move.

An obligation is what we have promised to pay, including promises that outlast the reason we made them. If the workload disappears, which part of the payment can disappear with it, and when? I would rather discover an awkward answer while evaluating a proposal than after the organization has included its expected savings in a budget.

Metering is how consumption gets counted: requests, worker-hours, byte-months, model tokens. The count needs a rate and a pricing rule before it becomes a cost, and it still needs a connection to the work the business wanted done before we can say much about value. An application can produce plenty of billable activity without accomplishing anything useful.

Then there is attribution, which connects an expense to the workload or decision that caused it. Attribution helps us understand who is consuming resources and gives us somewhere to start a conversation. It doesn’t automatically tell us what the enterprise would save if that consumer went away. We will return to this distinction repeatedly, because shifting a cost between teams is surprisingly easy to mistake for reducing it.

These qualifications become important in a migration proposal, where usage charges, existing commitments, operating work, shared costs, and temporary overlap can all be combined into an attractive comparison. Rather than spend the meeting debating whether a line is technically fixed or variable, I would begin by following the proposal through time: which expenses disappear, which remain, which move to somebody else, and which we are about to create. Once those answers are clear, the vocabulary has something useful to describe.

A bill we can follow

Here is the constructed portfolio from the introduction, expressed as a thirty-day operating-cost view. The amounts are synthetic teaching inputs, not market prices or an organization’s actual spending. I have kept the portfolio small enough that we can inspect it, while including several kinds of work that require different decisions.

For the web pool, we have 64 workers at a constructed resource charge of $40 per worker-day: 64 × $40 × 30 = $76,800. The eight compatible batch workers carry the same charge, giving us 8 × $40 × 30 = $9,600. The other rows are declared fixture amounts; later examples develop selected costs from the units relevant to those workloads.

The shared platform is one environment, run by a central team, that hosts hundreds of small internal applications: reporting tools, departmental workflows, things somebody built for one group and never retired. None of them costs much on its own. Together they cost $60,000 a month, and nobody who owns one of those applications can do much about the platform’s bill. When later chapters refer to the long tail, this is what they mean.

There is a deliberate complication in the AI line. Its $100,000 includes $12,000 in token charges, $8,000 for retrieval, evaluation, and platform services, and $80,000 in modeled human-review time, which we will work through in Chapter 7. Most of what the assistant costs is people reading its output, not the model. The other rows are resource and service charges, without all the people needed to operate them. We therefore have a mixed operating-cost view, useful for this example but neither a vendor invoice nor a complete economic total. If you extend it to include labor, don’t add that AI review time a second time.

Each included expense is counted once, with discounts and relevant commitment allocation already reflected in the charge. That matters when somebody brings a separate report of commitments to the discussion: we need to reconcile it with the consumption view before adding anything. Otherwise, paying for the computing can show up twice because two reports describe different aspects of the same arrangement.

I am using thirty days so that the calculations are easy to reproduce. In an operating report, the calendar has to agree with the period Finance is closing, including whatever treatment is needed for partial periods, credits, currency conversion, and adjustments. A normalized run rate can be useful alongside that report, as long as nobody has to guess why its total differs from the bill.

Now look past the amounts to the work. The migration needs a credible way to stop paying for the old environment. The data platforms need someone who understands their maintenance and recovery requirements, while the AI support assistant needs a clearer account of what it is accomplishing. The long tail needs an owner who can improve the shared platform without calling every application user into a meeting. A single instruction to reduce utilization or cut each line by the same percentage would avoid all these questions, which is precisely why I wouldn’t trust it.

Even ranking the opportunities by expense requires care. A small shared component may be holding up several much larger services, and a conspicuous database bill may reflect an obligation that is expensive for a good reason. The table tells us where to look. We still have to learn what we are looking at.

Follow a change across the boundary

The business wants to roll out new functionality on the web service, and one possible bridge is to move the eight batch workers into it temporarily. Over a thirty-day transfer, that adds $9,600 to the service’s attributed resource cost and removes $9,600 from the batch allocation. The web service now shows $76,800 + $9,600 = $86,400, while the enterprise still shows $448,000.

We have changed what the workers do, without buying another worker or reducing the total resource charge. But before anyone describes the transfer as free, we need to talk to the person whose batch work will wait. Perhaps the delay is harmless within an agreed window; perhaps the backlog will need extra capacity to catch up. We don’t yet have enough information to price that consequence, and leaving it unpriced is different from declaring it zero. The batch owner has information that our cost table cannot supply.

Now suppose sixteen additional workers become available at the same constructed charge. They add 16 × $40 = $640 per day, or $19,200 over thirty days. If everything else stays unchanged and no commercial arrangement offsets the increment, the modeled total becomes $467,200. That gives us an estimate to take into the commercial discussion, where we still have to check the agreement, effective date, and payment treatment before predicting the invoice.

There is also a supply lead time, which approving the expenditure will not shorten by itself. You can have agreement on the economics and still have a launch arriving before the workers are ready. This is why I resist separating purchasing strategy from consumption so completely that nobody follows the decision across both. Different specialists can own different parts of the work, but they need to evaluate the same change: what we buy affects the economics of later usage, and what engineers change affects the usefulness of what we already bought.

The invoice leaves things out

People are the most obvious expense missing from a resource-only comparison, although adding a headcount line is rarely the end of that discussion. An architecture can create patching, upgrades, on-call work, and a need for specialist knowledge. If the team is already employed, using more of its time may leave payroll unchanged while delaying something else that matters. Finance and engineering need to be able to discuss that consequence without pretending either that a new hire is inevitable or that an existing employee’s time is free.

Take a separate synthetic proposal that reduces resource charges by $5,000 a month and adds recurring work estimated at half of one person’s available time. If the planning model values a full year of that person’s capacity at $240,000, the allocation is 0.5 × $240,000 ÷ 12 = $10,000 per month. We have found $5,000 less in resource charges and $10,000 more in modeled labor consumption.

I would not turn that into a claim that cash spending must rise by $5,000. I would ask whether the team has room for the work and what it would otherwise be doing. If there is available time and the change is valuable, the proposal may be perfectly sensible. If the same people are already postponing critical maintenance, the staffing assumption deserves considerably more attention than it received in the savings slide.

Migration work adds another kind of complication. Our portfolio is paying $24,000 for the old environment and $18,000 for its replacement because customers have to move and results have to be verified before the old one can stop. We will examine this double bubble in Chapter 9. For now, both expenses belong in the current view, however much we would prefer to show only the architecture we intend to have when the migration is finished.

The invoice is also silent about the consequence of a backup that cannot be restored in time or the value of keeping a launch option available. These are important omissions, but filling them with a convenient expected-loss number does not improve the analysis. We can measure an expense and describe an exposure while acknowledging that the business judgment remains with someone who understands the obligation and has authority to accept it.

A quiet system is a question

If you want an impressive savings total quickly, add a waste column to the inventory and populate it from an average utilization threshold. You will have a number before you have learned much about the systems, which is the problem. That quiet resource could be abandoned, waiting for a scheduled operation, preserving a recovery option, or sitting oversized because nobody has yet done the work to establish a safer configuration.

The last case is worth emphasizing. Not understanding a resource is a reason to investigate it; it is a poor basis for either deleting it tomorrow or protecting it indefinitely. I would start with the person who can explain what the resource supports and when it will next be needed, then work with the relevant specialist to establish what could change safely. The recommendation should explain what the change releases and whose work would be affected, so that the resulting number means more than “the average looked low.”

Sometimes this takes five minutes. If a disposable test environment has finished its job, its owner confirms that nothing else depends on it, and the relevant records and obligations are dealt with, retire it through the normal change process. We don’t need a symposium on uncertainty for every forgotten experiment. The reason to distinguish easy cases from difficult ones is to leave enough time for the database whose apparent idle capacity turns out to be doing something important that only two people understand.

Enough information to have the next conversation

I would begin the cost record with the work being supported, its owner, the period, the amount, and the decision we are considering. Alongside those, show the basis of the charge and which costs are direct, shared, or still unresolved. Keep the underlying records available, because the first version will contain questions that somebody else can answer better than we can.

An unknown owner needs investigation. A shared allocation needs an agreed method, and if we change that method, we need to reconcile the movement so that reallocating an expense doesn’t earn us credit for eliminating it. These are ordinary bits of housekeeping until a large reported saving depends on them; then they become the difference between useful evidence and a number that everyone has begun repeating.

The FinOps Foundation’s FOCUS specification addresses consistent cost-and-usage data across providers, reducing some of the translation work needed to bring the records together.¹ That is valuable groundwork. Once the data is comparable, we still need the people who can explain a disputed shared cost or decide whether an expense is serving a worthwhile purpose.

For our portfolio, we can now explain the web service’s cost and calculate the charge for additional workers. The proposed demand has changed, though, and before we recommend buying anything we need to know what the existing service can deliver, including when some of its workers are unavailable. That requires a conversation about what we have promised the customer, which is where a price calculation starts to become a capacity decision.