Allocating the Shared Platform at Crestline Media
Crestline Media spends $4.5M a year on public cloud. Around 40% of that runs on a shared Kubernetes platform, a shared observability stack and a shared data warehouse, all operated by a central platform team. Tag coverage is 55% and the untagged spend sits mostly in the shared platform accounts. Central IT has proposed allocating all shared costs by business-unit headcount. Four product teams have rejected the proposal in writing, arguing that their workloads are small in headcount terms but dominate the warehouse spend. The CFO wants a defensible number for next year's budget cycle and has asked why 45% of the bill is still 'unallocated'.
1. Is the binding constraint here a data problem or an accountability problem? Justify what you would fix first.
Read the worked answer
It is both, and the sequencing matters more than the diagnosis.
The data problem is upstream: untagged spend concentrated in shared accounts means the allocation question cannot even be posed precisely - you cannot see which namespace, dataset or service the money belongs to, so any model you pick is asserted rather than evidenced. That is fixable cheaply: tag enforcement on new resources, namespace-level cost split from the Kubernetes billing export, warehouse spend split by query or compute user, and a named owner for each remaining untagged line.
But the accountability problem is why the headcount proposal exists at all. Central IT proposed a driver with no causal relationship to the cost because the goal was to make the number go away, not to change behaviour. Headcount allocation guarantees the product teams will dispute the result forever, because it is not defensible on its face - and once a chargeback is discredited in year one, it takes years to rebuild.
Fix the data first, but do not wait for full data to publish a model. Run showback for one to two cycles with a deliberately provisional driver, publish the method openly, and let teams challenge the driver rather than the number. Data quality and model legitimacy converge faster when people can see their own line. Chargeback comes after the numbers have survived argument, not before.
2. Design the shared-cost allocation model. Be specific about drivers and about what happens to spend you cannot attribute.
Read the worked answer
Split shared costs into a fixed and a variable component and treat them differently - this is the core move.
- Kubernetes platform: a per-cluster fixed share (the control plane, core networking, platform team tooling) allocated by an agreed weighting, plus the variable portion allocated by CPU/memory requests per namespace. Use requests rather than usage, because requests are what teams actually set and therefore what they can change. Publish both so teams see waste between requested and used.
- Observability: allocate by ingested volume (GB logs, metric series, trace spans). This is the line item teams can act on by turning down log levels, and it makes the charge self-correcting.
- Data warehouse: allocate by compute consumed (credits or slot-hours per role/query tag), not storage. Storage is cheap and static and misleads; compute is where the disputes and the savings both live.
- Network/egress and support charges: allocate proportionally to each team's share of consumed cost, with the method stated.
Unattributable spend: do not spread it silently across teams - that is how a model loses credibility. Carve out a named 'Platform - Unallocated' line with an owner and a target: 90-95% of total spend allocated to a team, with the residual shrinking quarter over quarter and the reason for each residual documented. The CFO's 'why is 45% unallocated' becomes a trend line rather than an accusation.
3. The four product teams reject the model. How do you handle that, and what would make you actually change the driver?
Read the worked answer
Treat the rejection as useful data - they are telling you the driver does not reflect causality, and in the headcount case they are right.
What I would do:
- Walk them through the method, not the invoice. Show the formula, the inputs and their own namespace/dataset consumption. Most allocation disputes are disputes about transparency, not about arithmetic.
- Ask each team for the decision the charge is supposed to change. If a team cannot name an action the number would prompt, the allocation is decorative and should be simplified.
- Give them a lever. A driver they can influence (log volume, resource requests, query efficiency) turns a charge into a decision. Headcount gives them none, which is the strongest argument against it.
- Make the challenge mechanism cheap and time-bound - a two-week window each cycle to contest a line with evidence, not an open-ended veto.
What would change my mind on the driver: a team showing that their consumption of a driver is not under their control, or that two workloads with the same driver consumption have an order-of-magnitude difference in the cost they cause. That is a legitimate reason to re-weight. A team simply preferring a smaller number is not.
Escalate to leadership only after the data has been shown and the challenge window has run. Escalating a contested model early converts a technical disagreement into a political one, and the CFO will get a number nobody believes - which is the outcome you were hired to avoid.