A small service upgrade
Imagine changes to customer support, delivery, assurance, funding and partner interfaces. Here each area is counted once and given equal weight. They are change areas, not a measured organisational hierarchy.
Add an area, change the cost rule, then try splitting the same areas between teams. Watch the result when crossing a team boundary becomes more expensive.
No capacity limit, danger threshold, forecast or recommendation is calculated.
Adding one more area
Each bar is the extra assumed cost of adding that area to one group. These are increments, not measured strain or a causal propagation model.
Where do the interfaces go?
Areas are divided as evenly as possible. Every possible pair is retained; only its cost changes at a team boundary. The picture does not decide which areas should share a team.
Same work, two arrangements
| Rule | One group | Within teams | Across teams | Split total |
|---|
What can this help you ask?
- Are difficulties driven by the amount of work, by interactions, or by a few specific bottlenecks?
- Which dependencies would genuinely disappear after changing team boundaries, and which would require a contract or coordination?
- What observations would justify the curve and interface costs before using the model to advise a real organisation?
Read the construction and the correction
The original app used C(n) = n³ / 10 for one to five simultaneous “change layers”. That arithmetic remains available. Its labels claimed a sustainable three-layer ceiling at Amazon and automatic spin-outs above it. The source supplied no evidence for that threshold or explanation of AWS, Lab126 or Kuiper. Those claims and the safe/danger colours have been removed.
The alternatives make the choice of assumption visible. Equal cost uses C(n) = n / 10. The pair model adds one tenth per possible unordered pair: C(n) = [n + n(n−1)/2] / 10. The original cubic curve is an invented shape, not a consequence of pair counting. All three agree at one area.
For team sizes nᵢ, the comparison uses Σ C(nᵢ) + h × cross-team pairs, where h is the chosen interface cost. We assume every area can interact with every other, equal importance, and no setup costs or changes to productivity. For the cubic case, splitting has a built-in advantage before boundary costs; that is a property of the formula, not evidence that decentralisation works.
AWS’s account of two-pizza teams discusses autonomy, ownership and reduced dependencies. It supplies context for the question, not this cost curve or a universal number of sustainable change layers. The numerical example here is our construction.