Patterns / 5. Changing the Flows
Pattern 5.2
Charge the Unit, Not the Team
If you charge for shared services, bill the business unit rather than each team, so that the financial boundaries are ones that already exist.
In This Context
Chargeback works, when it does, because it puts a cost in front of the person who incurs it. But the level at which you charge decides where people draw boundaries. Connector charged every team, so every team had a reason to draw a boundary around its own bill. Services were isolated and VPCs were split. Helping another team became a cost on the helper’s P&L, so teams stopped helping each other, and shared components that one team used and another looked after were orphaned.
You notice this when the teams being billed are smaller than the units that hold budgets, and when teams start asking who will pay before they help each other.
Therefore
Charge at the level of the business unit. Teams within a unit go on sharing freely, and the only boundaries that matter financially are the ones the organization already has.
- Pair it with Allocate by Tag, Not by Topology, so the unit’s bill can be produced without changing the architecture.
- Fund the shared platform itself separately (Fund the Commons Separately), so using it isn’t penalized.
Consequently
- Teams within a unit can share and help each other without a bill attached.
- No new boundaries are drawn in the system to match the bill.
- It doesn’t settle how the shared platform itself is paid for, which still needs a separate decision.
Seen In
Chapter 17, “Designing a Chargeback That Doesn’t Become Connector’s”; contrast Chapter 7, “Chargeback Phase I: Setting Up the Mechanism” and Chapter 7, “Chargeback Phase II: Execution”.