Anti-pattern 7.2
Chargeback in a Crisis
A cost-allocation scheme imposed in a hurry, which the architecture then reorganizes itself around.
In This Context
A business is under sudden pressure to cut costs. At Connector, after a disappointing IPO, the board wanted cost cuts to show the market by the first quarterly earnings call, three months away. Cloud spend is large and hard to attribute, and charging each team for what it uses looks like the fastest way to make spending visible and bring it down.
Therefore
The board imposes per-team chargeback, with quarterly reviews of each team’s P&L and a savings target for every team, without input from engineering.
Consequently
- It works on its own terms: cloud spend and overall costs fall, and the share price recovers to close to its IPO price.
- Services are isolated so each team’s costs can be measured, and shared VPCs are split one per team.
- Network costs rise, because traffic between the new VPCs costs more, and services are opened up to the internet to keep them talking.
- Teams turn inward. Helping another team becomes a cost on the helper’s P&L, so teams stop helping each other; the compliance team loses the platform team’s support and misses its figures for a board meeting.
- Shared components that one team uses and another looks after are orphaned.
- Engineers who optimize for their own team’s numbers do well; those with bolder ideas grumble about “ticket-shifters” being rewarded, and several senior engineers leave.
- A better approach: Showback Before Chargeback, Charge the Unit, Not the Team, Allocate by Tag, Not by Topology, Fund the Commons Separately, Write In the Review Date.
Seen In
Chapter 7, “After the Bell: The Pressure to Cut Costs”, Chapter 7, “Chargeback Phase I: Setting Up the Mechanism”, Chapter 7, “Chargeback Phase II: Execution”, Chapter 7, figure “From share price to silos”, Chapter 14, figure “Connector’s VPCs before and after chargeback, and whose budget pays for each part”; summarized in Chapter 17, “Chargeback”.