Multi-Level Bonus
A multi-level bonus is a compensation structure where the variable component of pay is calculated from performance at multiple levels of the organisation: the team, the product, and the ecosystem. It addresses the well-known problem that pure individual bonuses tend to encourage individuals to optimise for their own measure at the expense of the team they are part of.
Goal
To compensate people for the outcomes they collectively produced, rather than for the appearance of individual contribution to those outcomes.
Context
Most variable compensation in tech is structured around individual performance. The intuition is fair: pay each person for what they delivered. The reality is that almost nothing of consequence inside a Stream Team is delivered by one person. Research is run by the team, design is shaped by the team, code is reviewed by the team, decisions about what to ship are made by the team. Trying to pay people on individual contributions inside that kind of work creates two predictable problems.
First, it incentivises the wrong behaviour. If your bonus depends on your individual feature shipping, you are quietly incentivised to take the visible work, hand off the un-glamorous work, and get your name on as many high-status decisions as possible. None of this is what makes a Stream Team produce good outcomes.
Second, it requires measurement that doesn't really exist. The "individual contribution" of one person on a team that worked together for six months is hard to disentangle in any rigorous way. Forcing managers to estimate it produces evaluations that are mostly noise and slightly biased toward whoever is most visible to the manager.
A multi-level bonus structure pays people on outcomes the team produced together, plus broader outcomes that align the team with the wider organisation.
How it works
A typical multi-level bonus has three layers, each tied to a different scope of impact:
| Layer | Tied to | What it rewards |
|---|---|---|
| Team | The Stream Team's own KPIs and the value-stream metrics the team is accountable for. | Outcomes the team produced collectively. Aligns everyone on the team with the same goal. |
| Product | The Product Team's combined outcomes across all the Stream Teams underneath it. | Cross-team collaboration and product-level success. Discourages teams from optimising at the expense of the wider product. |
| Ecosystem | The organisation's overall performance. | The fact that even a perfect product outcome is constrained by the wider business context. Aligns Stream Teams with the company's strategic position. |
The weights between the layers are a design choice. A typical mix might be 50% team, 30% product, 20% ecosystem, but the right ratio depends on how independent the Stream Teams really are and how much of the variance in outcomes the team itself controls.
Why three layers
Each layer corrects a failure mode of the layer above:
- Team-only bonuses can incentivise inter-team competition that hurts the product overall. A team that is paid only for its own metrics has no reason to help another team that is missing its targets, even when the help would benefit the wider product.
- Product-only bonuses can produce free-rider problems. A weak team can quietly ride on the success of a strong team because they share the same product-level number.
- Ecosystem-only bonuses dilute the connection between work and reward. People stop seeing how anything they did affected anything that paid them.
Combining the three layers is a compromise that no single layer achieves on its own.
Inputs
| Artifact | Description |
|---|---|
| Team-level KPIs | The metrics each Stream Team is accountable for, agreed during quarterly objective-setting. |
| Product-level KPIs | The Product Team's success metrics across all Stream Teams. |
| Ecosystem-level KPIs | The organisation's overall performance metrics (revenue, retention, market position). |
Outputs
| Artifact | Description | Benefits |
|---|---|---|
| Bonus calculation rules | A clear, documented formula for how each layer contributes to the variable compensation of each role. | Removes ambiguity and reduces the perception that bonuses are subjective. |
| Performance reviews | Conversations focused on growth and development rather than on bonus negotiation. | Decoupling individual performance from variable pay frees the conversation to focus on coaching. |
Anti-patterns
- Hiding the formula. People will figure out the rough rules eventually. Hiding them just means people optimise based on guesses, which is worse than optimising based on the real rules.
- Adding a fourth "individual" layer that reintroduces the problem. Layering an individual bonus on top of the multi-level structure undoes most of the benefit. If individual recognition is needed, handle it through level/promotion, not through variable pay.
- Setting the team layer too narrow. If the team-layer KPI captures only one dimension of the team's work (e.g. number of features shipped), Goodhart's Law applies as it would in any other bonus system.
- Making the ratios too aggressive. A bonus that swings dramatically with ecosystem performance becomes a referendum on macroeconomic conditions rather than on the team's work. Keep the variability proportional to the influence the team actually has.