BitBootcampBitBootcamp ← all explainers 🔄 Review ⚙ Settings

Drill 68 — The Unit Economics Nobody Owned

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

The story

The company celebrates 3x transaction growth; in the same period, the cloud bill grows 5x. Nobody notices the crossover, because revenue lives in one meeting and cost lives in another, and no single chart has ever shown both. Then a board member asks a one-line question — "what does one transaction cost us to process?" — and the answer takes three weeks to produce, with caveats on every number.

⏸ Stop here and ask the room: three weeks to answer a one-line question. What does that delay tell you about ownership?

Run it — facilitator script

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

Open by writing "3x" and "5x" side by side on the board and asking who in the story could see both numbers at once. The answer — nobody — is the drill.

"Why did nobody see 5x cost against 3x volume?"

Listen for: the two curves lived in different meetings, on different dashboards, owned by different functions — and each looked healthy in isolation: growth teams celebrate rising volume, finance expects a growing company's bill to grow. The failure is that no chart, and no person, ever divided one by the other. Strong answers name the deeper effect: growth forgives everything — rising totals read as success even while efficiency decays inside them.

Weak signal: "finance should have flagged it." Finance saw a total within the range a 3x-growth company budgets for. The signal only exists in the ratio, and nobody owned the ratio.

"What makes cost-per-transaction so hard to compute after the fact?"

Listen for: allocation — the numerator is a bill full of shared infrastructure, multi-product platforms, and untagged resources, and mapping each dollar to a transaction requires metadata that was never captured (drill 64's tags, back to haunt the arithmetic). Plus definitional fights: which transactions count, how shared costs amortize, what to do with fixed platform spend. Three weeks and caveats is what reconstruction looks like when attribution wasn't designed in.

Weak signal: "just divide the bill by the transaction count." Do it live — then ask which caveats the board would attach. That naive quotient is precisely the number that took three weeks to correct.

"Who should own that ratio, and what should they watch weekly?"

Listen for: a named single owner — typically a platform or product-engineering lead — with cost-per-transaction on a dashboard next to the revenue dashboard, a trend alarm on the ratio, and weekly per-service showback so every team sees the cost of what it ships. The best answers give the acceptance test: the board's question should be answerable in under a day, from a chart that already exists.

Weak signal: "everyone should own cost." Everyone means no one — that is the exact mechanism by which the ratio in this story went unowned.

The reveal

Once finally computed, cost-per-transaction turns out to have doubled year over year — driven by three specific services, each fixable in weeks, none previously visible. Not hidden by anyone: simply unowned. Total spend had an owner; the ratio had none, and growth kept the totals looking like success.

Why this happens — the mechanics

Unit economics has no natural owner because the ratio crosses every organizational boundary that exists. Engineering owns systems, finance owns totals, product owns revenue — and cost-per-transaction needs all three: a numerator from finance's world, a denominator from product's, and remediation from engineering's. Anything that requires three departments by default belongs to none of them; the ratio isn't hidden, it's homeless. Meanwhile each department's own dashboard genuinely looks fine, which is why the miss survives every review.

Growth is the perfect camouflage for efficiency decay. When volume triples, a bill that quintuples still feels like the cost of success — every individual chart points up and to the right, and up-and-to-the-right is what everyone was hired to produce. Yet 5x cost on 3x volume means each transaction quietly got two-thirds more expensive, compounding monthly. Totals cannot show this; only the ratio can, and the ratio is exactly the chart nobody had.

The three-week delay is the diagnostic. Cloud bills arrive a month late and aggregated, and turning them into cost-per-transaction requires allocation metadata — tags, service-to-product mappings, shared-cost rules — that must be designed in advance. If it wasn't, the computation is an archaeology project with caveats on every number. This is the maturity ladder FinOps (Financial Operations — the practice of making engineering teams accountable for the unit economics of what they build) climbs: first make spend visible, then attributed, then unit-costed — each step impossible without the one before. A KPI (Key Performance Indicator) that takes three weeks to compute isn't a KPI; it's a research question.

Diagrams

Problem — how the failure unfolds:

sequenceDiagram
    autonumber
    participant GR as Growth
    participant CB as Cloud bill
    participant BD as Board
    participant TM as Team
    GR->>TM: Transactions grow 3x -<br/>celebrated
    CB->>TM: Bill grows 5x in the<br/>same period (silent)
    Note over GR,CB: Revenue and cost live in<br/>different meetings (silent)
    Note over TM: Nobody owns cost<br/>per transaction
    BD->>TM: What does one transaction<br/>cost us to process?
    TM-->>BD: Three weeks to compute -<br/>caveats on every number
    Note over BD,TM: Unit cost doubled year<br/>over year, unnoticed

Solution — where the guardrails go:

flowchart TD
    A["Cost per transaction<br/>defined as a first-class<br/>KPI"] --> B["Named owner for the ratio"]
    B --> C["Unit-cost dashboard beside<br/>the revenue dashboard"]
    C -.-> D["Trend alarm fires when<br/>unit cost creeps up"]
    A --> E["Showback: every team sees<br/>its services' cost weekly"]
    E -.-> F["Cost regression caught<br/>like a latency regression"]
    D --> G["Three driver services<br/>found and fixed in weeks"]
    F --> G

What good looks like

The lesson

Unit economics — cost per transaction, per decision, per document — is a first-class KPI (Key Performance Indicator) with an owner, a dashboard, and a trend alarm, because total spend numbers hide efficiency decay under growth. And engineers should see the cost of their own services weekly (showback — reporting each team's spend back to it), so a cost regression is caught the way a latency regression is: by the people who caused it, days after they caused it.

Named concepts: FinOps practice, unit economics, showback/chargeback, cost-efficiency SLIs.

Real-world echoes

Transfer

What does one unit of our core work — a decision, a document, a transaction — cost today versus a year ago? If producing that number takes more than a day, the delay is the finding.

Make it a ticket: Time-box one day to compute our cost per core unit of work from existing data; whatever blocks the computation — missing tags, unjoined billing exports, an undefined denominator — becomes the ticket, assigned to a named owner with a target of "answerable in under a day" by next quarter.

Related