Shared platform costs are £4.8M a year and currently split evenly across 30 engineering teams. Teams complain the number is arbitrary, nobody reduces usage, and two teams generate most of the load. Which allocation model should replace it?

What is actually required

A cost allocation is a control, and a control is judged by the behaviour it produces. An even split produces none, because a team's own decisions do not move its bill: usage is free at the margin, so the only rational response is to use more. The two heavy teams are behaving correctly under the rules they were given.

So the requirement is that the number a team sees moves when the team changes what it does, and that the driver used is something the team can see and influence. Everything else — fairness, precision, finance's reporting needs — is secondary to that.

The one change that matters

Pick one measured driver per platform service, in units engineers already understand: ingested gigabytes for logging, active series for metrics, build minutes for CI, requests and egress for the gateway, provisioned IOPS and storage for the data platform. Then publish the unit rate, so a team can calculate the cost of a change before making it. A rate card turns a bill into a design input, which is the entire purpose.

Three details decide whether it works:

• Show the unallocatable remainder separately. Platform team salaries, control planes, reserved capacity bought ahead of demand and the baseline cost of existing at all cannot honestly be attributed to a usage driver. Spreading them pro-rata buries them and makes every team's rate look worse than the marginal cost; showing them as a named central line keeps the marginal rate truthful and keeps the platform's own cost under scrutiny.
• Start as showback, not chargeback. Publish the numbers for a quarter before anyone's budget depends on them. The first month of data is always wrong, and discovering that during a budget dispute destroys trust in the model.
• Make the cheap path the default. Allocation tells a team their logging bill is £40k; a sampling default and a retention policy in the platform's own templates are what actually reduce it. Charging without providing the lever produces resentment and no saving.

Why the other options fail

• Headcount is a proxy for nothing. A six-person team running a data pipeline can out-consume a forty-person team shipping a web front end by an order of magnitude, and the allocation would tell both of them the opposite. It is popular because it is easy to compute and because it never changes, which is the same reason it changes no behaviour.
• Share of total cloud spend double-counts and rewards the wrong thing. A team that moves a workload onto the shared platform reduces its own cloud spend and therefore its platform allocation, while increasing platform load. The signal points backwards.
• Showback without charging is the right first step and an incomplete answer. It creates awareness and no trade-off: when a team must choose between a feature and a cost reduction, visibility alone loses to the feature nearly every time. Keep showback permanently as the reporting layer, and let the budget consequence follow once the data is trusted.

What I would leave alone, and when not to allocate at all

Do not allocate the platform team's own payroll by usage, and do not try to reach 100% attribution. Chasing full allocation produces an unmaintainable model and arguments about pennies, and the last 15% of accuracy changes nobody's decisions. Two decimal places of fairness is not the goal; a rate a team can plan against is.

How I would argue this in review

With the two heavy teams' numbers. Show what each would pay under the current even split and under a usage driver, then show the three changes each could make and what those would save. The argument is won by demonstrating that the model gives teams a lever, not by demonstrating that it is fairer. And commit to publishing the central remainder, because the first objection will be that the platform is passing on its own inefficiency.