BitBootcampBitBootcamp ← all explainers 🔄 Review ⚙ Settings

Drill 67 — The Commitment Mismatch

Theme: Cost & FinOps · Format: 20-min drill · Difficulty: advanced

The story

To save 40%, the platform team buys three-year reserved capacity for the current instance family — the spreadsheet math is airtight. Eight months later, an architecture migration to a new chip family with twice the price-performance makes the reserved family obsolete for their workloads. The commitment doesn't transfer. They now pay for reservations they don't use and on-demand rates for the capacity they actually run. The discount has become a penalty with twenty-eight months left on the clock.

⏸ Stop here and ask the room: the 40% savings is now the most expensive line on the bill. What question was never asked before signing?

Run it — facilitator script

Timing (20 min): 2 min story · 10 min questions · 3 min reveal · 5 min transfer.

This one plays best if you let the room defend the purchase first — the spreadsheet really was airtight — then pull the thread of what the spreadsheet couldn't see.

"What made a three-year commitment feel safe?"

Listen for: the framing trap — the decision was presented as "save 40%," never as "go long one instance family for thirty-six months." A discount hides the fact that a reservation is a bet on architectural stability. Strong answers spot the spreadsheet's blind spot: it modeled the current fleet perfectly and the future fleet not at all, and airtight math on the wrong question feels exactly like safety.

Weak signal: "the discount justified the risk." Ask who priced the risk. Nobody did — the risk column didn't exist in the spreadsheet.

"What portion of the fleet was actually stable on a three-year horizon?"

Listen for: the baseline/volatile split — some floor of capacity survives any migration, and everything above it churns with the architecture. Good answers propose evidence: historical instance-family churn, the roadmap itself, growth plans. The best answers notice the story's twist in advance — the migration was on the roadmap, so the answer was knowable in a different meeting.

Weak signal: "the whole fleet — we'd been running it for years." Running something for years measures the past; a commitment prices the future.

"In what order should optimization and commitment happen?"

Listen for: optimize first — right-size, delete orphans, re-architect — then commit only to what remains. The mechanism matters: committing first freezes today's waste at a 40% discount and removes the financial incentive to ever clean it up, because the money is spent either way.

Weak signal: "commit now, optimize later — the discount starts sooner." That sentence is how the waste gets a three-year lease.

The reveal

The "savings" decision was made from a spreadsheet of the current architecture, with no one asking how stable that architecture was three years out. The migration wasn't even a surprise — it was on the roadmap the whole time, in a different meeting.

Why this happens — the mechanics

A reservation is not a discount; it's a financial instrument — a forward purchase of specific capacity, often tied to an instance family, a region, sometimes an operating system. The provider sells certainty of revenue and shares the margin; the buyer sells flexibility and pockets the difference. That trade is invisible in the purchase spreadsheet because the spreadsheet only has columns for the current fleet: price now versus price committed. The thing being sold — the option to change architecture — appears nowhere, so it gets priced at zero. Eight months later, the zero turns out to be twenty-eight months of double-pay.

The organizational failure is a lock-in signed across a knowledge boundary. The people who understood commitment mechanics (platform, finance) and the people who knew the chip migration was coming (architecture, the roadmap meeting) were different people in different rooms. Neither group did anything wrong by its own lights — the mismatch lives precisely in the gap between the meetings. Commitment decisions have a multi-year blast radius, which means they need input from everyone whose plans span those years, and by default they get input only from whoever owns the spreadsheet.

Cloud pricing dynamics make the trap tighter: providers ship better price-performance families on a cadence shorter than three years, which is exactly why they discount three-year terms so deeply — the discount is partly compensation for the upgrades you're agreeing to skip. Exchange and conversion mechanisms exist on some commitment types but are bounded and asymmetric; "the commitment doesn't transfer" is the default, not the exception. Signing long is sometimes right — but only for the floor of capacity you're confident outlives the roadmap.

Diagrams

Problem — how the failure unfolds:

timeline
    title The discount that became a penalty
    section Month 0
        Spreadsheet shows 40% savings : Three-year reservation signed : Roadmap never consulted (silent)
    section Month 8
        Migration to new chip family : Reserved family now obsolete : Commitment does not transfer
    section Months 8-36
        Paying for unused reservations : On-demand for the real fleet : Double-pay, 28 months left

Solution — where the guardrails go:

flowchart TD
    A["Commitment proposal raised"] --> B["Optimize first: right-<br/>size, clean up, re-<br/>architect"]
    B --> C["Fleet split: stable<br/>baseline vs volatile layer"]
    C --> D["Reservations cover only<br/>the baseline floor"]
    C --> E["Volatile layer stays on-<br/>demand or in flexible<br/>commitments"]
    D -.-> F["Quarterly review of every<br/>commitment's utilization"]
    F -.-> G["Alarm fires when<br/>commitment utilization<br/>drops"]
    E --> H["Chip migration proceeds<br/>with no stranded spend"]

What good looks like

The lesson

Commit only to your stable baseline — the floor you're confident survives architecture churn — and keep the volatile layer on-demand or in flexible commitments. The discount order of operations is: optimize first (right-size, clean up, re-architect), then commit to what remains. Committing first locks in the waste at a 40% discount.

Named concepts: commitment portfolio management, baseline vs. volatile capacity, optimize-then-commit ordering, architecture-horizon risk.

Real-world echoes

Commitment mismatches rarely produce public postmortems — they surface as gross-margin footnotes and quiet renegotiations, not incidents — which is part of why the pattern keeps repeating. No specific public case is cited here.

Transfer

Pull last month's commitment utilization: what fraction of reserved spend covered nothing? Now check the roadmap — which planned architecture change would strand more of it?

Make it a ticket: Export current commitment utilization by reservation; file one ticket per commitment under 90%, and a second ticket to cross-check the full commitment portfolio against the next four quarters of the architecture roadmap, with findings presented at the next platform review.

Related