skip to content

A shared network hub and a central logging estate serve every team — how do you attribute their cost without pretending a label can?

level: seniorimportance: should knowfreq 43%

answer

  1. one owner, many beneficiaries
  2. no label is truthful here
  3. unallocated, split, or flat fee
  4. the driver must be influenceable
  5. shares must reconcile to the pool

basics

~20 s

You cannot label a genuinely shared cost into one team's bucket, so you choose a posture instead: leave the pool visible and unallocated, or divide it by a driver everyone agreed to in advance. Any split is a convention, not a measurement.

solid answer

~50 s

Shared platform costs — a hub network, a central logging estate, a shared build fleet — are incurred by one owner on behalf of everybody, so no label on the underlying resources attributes them truthfully. Three postures exist: leave the pool unallocated and visible as a platform line, divide it by an agreed driver (measured usage, attributed direct spend, headcount), or charge a flat per-team amount. Divide by usage where a usage metric genuinely exists — bytes logged, bytes through the hub, build minutes — because that is the one form of split that also changes behaviour. Whatever the rule, it must be agreed and published before the numbers land, reconcile back to the pool with the residue shown, and be applied prospectively when it changes. No split is a measurement; the aim is a convention nobody is surprised by.

code

pseudocode · 20 lines
pseudocode
sharedPool = hubNetworkCost + loggingEstateCost + buildFleetCost

// driver: what each team measurably put through the shared platform
for each team in teams:
    driver[team] = bytesLoggedBy(team) + bytesThroughHubBy(team)

driverTotal = sum(driver[team] for team in teams)

for each team in teams:
    if driverTotal == 0:
        // agreed fallback when the metric is missing: an even split, not a drop
        share[team] = sharedPool / count(teams)
    else:
        share[team] = sharedPool * driver[team] / driverTotal

    reported[team] = directlyAttributedCost[team] + share[team]

// both branches distribute the whole pool, so this is rounding residue only
residue = sharedPool - sum(share[team] for team in teams)
publish(residue)

go deeper

for a junior

Recall that some cloud costs are incurred once on behalf of everyone — a shared network hub, a central logging estate — and that no label on those resources can say which team caused them.

for a middle

Explain the three postures and their failure modes: unallocated pools grow unchallenged, a driver-based split is only as good as the driver, and a flat fee ignores how much each team actually consumes.

for a senior

Show the operating detail — a driver that is measured, causal and influenceable, a published rule agreed before the first bill, a defined fallback when the metric is missing, and shares that reconcile with the residue shown.

for a principal

The call you own is how much behaviour change the split is meant to buy against how much argument it will cost, and whether the shared pool should instead be shrunk by making a platform consumable directly.

## Why no label fixes this A label attributes a resource to an owner. A shared platform resource has one owner and many beneficiaries, so labelling it truthfully produces the answer `owner=platform` — which is correct and useless, because the question being asked is which of the teams behind the platform caused the spend. Typical members of this class: - a **hub network** that every team's traffic transits - a **central logging and telemetry estate** everything writes into - a **shared build fleet** running every team's pipeline - **support and account-level fees** with no resource behind them at all - the **unused portion of a commitment** bought centrally on everyone's behalf Each of these is genuinely joint. Any number you publish per team is the output of a rule you chose, not a measurement you took, and saying so plainly is most of what separates a strong answer from a hand-wave. ## Three postures | Posture | What it says | Where it fails | |---|---|---| | Leave unallocated | The pool is a visible platform line owned by the platform team | Nobody feels its growth, so it grows | | Split by a driver | Each team carries a share proportional to something measured | Arguments move to the driver; a bad driver is just a tax | | Flat fee per team | Every team carries the same amount | Punishes small consumers, invisible to large ones | Leaving it unallocated is the right starting point and an underrated one: it keeps the pool measurable, it keeps one accountable owner, and it makes the trend obvious. Its failure mode is that a cost no team sees is a cost no team helps shrink. Splitting by a driver is where most mature estates end up. The quality of the split is entirely the quality of the driver. ## Choosing the driver A usable driver has five properties: 1. **Measured, not estimated.** Bytes written into the logging estate, bytes through the hub, build minutes consumed. If the metric does not already exist, the split is arithmetic dressed as evidence. 2. **Causal.** A team that doubles its logging should carry more of the logging estate. That is what makes the split behaviour-changing rather than a tax. 3. **Influenceable.** If a team cannot change its driver value, the charge is noise on their report and they will learn to ignore the whole report. 4. **Stable and cheap to compute.** Recomputed monthly by an automation, from data that already exists. 5. **Agreed and published before the first bill lands.** A split that arrives as a surprise gets disputed on principle, whatever its merits. Proportional-to-attributed-spend is the common fallback when no usage metric exists. It is defensible and has one honest weakness worth naming: a team that works hard to cut its direct spend also cuts its share of the shared pool, which means part of the saving is quietly transferred to teams that did nothing. Say this out loud rather than pretending the rule is neutral. ## The arithmetic has to close Whatever the rule, the shares must sum back to the pool. Publish the residue rather than absorbing it: a shared pool that reconciles to within rounding is a report people trust, and one that does not is one they audit instead of acting on. Two more mechanical rules: - **Apply a rule change prospectively.** Re-splitting a closed period rewrites numbers teams have already reported upward, and it teaches everyone that the figures are provisional. - **Have a defined fallback for a zero driver.** A month where nobody logged anything, or where the metric pipeline failed, must not divide by zero or silently drop the pool. ## What good looks like The shared pool is named, owned, visible as its own line, and shrinking as a share of total spend. The split rule fits in a paragraph, is published, and was agreed before it was applied. Each team's report shows three numbers, not one: their directly attributed spend, their share of the shared pool with the driver value that produced it, and the unattributed remainder in their own account. Disputes then land on the driver, which is a productive argument, instead of on whether the whole exercise is made up. And there is a boundary worth keeping: attributing a shared cost and deciding what to *do* with the attributed number — show it to teams, bill it internally, build a business case from it — are different problems, and an argument about the second one often masquerades as an argument about the first.

  • Why is splitting the pool in proportion to each team's directly attributed spend not a neutral rule?
    Because a team that cuts its own spend also cuts its share of the shared pool, and that relief lands partly on teams that changed nothing. It is a reasonable fallback where no usage metric exists, but it rewards and penalises indirectly, so publish it as the convention it is rather than as a measurement.
  • The driver metric fails for a month. What should the split do?
    Fall back to a rule agreed in advance — the previous month's proportions, or an even division — and say in the report that the fallback was used. Silently dropping the pool understates everyone and breaks reconciliation to the invoice; improvising a new rule during the month is how a split loses its credibility.
  • Is leaving a shared pool unallocated ever the right answer?
    Yes, particularly early. It keeps one accountable owner, keeps the trend visible, and avoids inventing a split nobody believes. It stops being right when the pool is large enough that its growth needs the teams driving it to feel something, since a cost no consumer sees is a cost nobody optimises.

saying these in an interview costs you the question

  • Claims a label can attribute a genuinely shared cost truthfully
  • Presents an allocation split as a measurement rather than a convention
  • Chooses a driver teams cannot influence, then expects behaviour to change
  • Re-splits a closed period after changing the rule
  • Hides the residue so the shares do not reconcile to the pool
  • Leaves a large shared pool unallocated and unowned indefinitely