Your bonus system is part of your delivery system

Most delivery improvement work starts with the board, the ceremonies, or the tooling. But the board only describes the work. The reward structure describes what people are paid to care about. If those two disagree, the board loses.

This is not an HR topic that lives in a separate policy binder. In interdependent software delivery, the way you reward people is a design input to how work flows, how much people help each other finish, and how honestly they report status. Before you redesign anything visible, it is worth inspecting whether your rewards, targets, and bonus narratives ask for the behavior your delivery system actually needs.

Incentives are a flow variable, not a side issue

Software delivery is a chain of dependent steps. A change moves through analysis, implementation, review, testing, integration, and release, and it usually crosses roles, teams, and queues on the way. Value appears when the whole chain finishes, not when any single station is locally busy.

Individual rewards attach to things that can be observed and attributed to one person: tickets closed, story points, lines shipped, features delivered. Those are station-level proxies. When the reward attaches to a local proxy, the rational move under pressure is to protect that proxy: keep your own throughput high, keep your own numbers clean, even when the system-level work would be finished faster if you stopped starting new items and helped someone else close theirs.

That is the mechanism worth naming plainly: rewards tied to individual output proxies can pull effort toward local optimization and away from finishing shared work. This is not a claim about bad people. It is a claim about what a measurement plus a reward will do to ordinary behavior over time.

What the pay-for-performance evidence actually supports

The research here is broad and generally favorable to performance-based pay, but it is not a blank cheque, and almost none of it is software-specific.

Financial incentives do tend to raise measured performance. A meta-analysis of 146 studies covering roughly 31,861 people found individual incentives positively associated with performance overall, with team-based rewards also positive; the size of the effect depends on moderators rather than being fixed (Garbers & Konradt, 2014). A more recent meta-analysis of 108 samples and over 71,000 people found pay-for-performance positively related to job performance, but the effect runs through mediators like intrinsic motivation, felt pressure, and perceived fairness, and it is stronger for core task performance than for the contextual, helping-oriented behaviors that hold a delivery system together (Chen et al., 2023).

The collective side is more cautious than team-bonus advocates usually admit. A cross-disciplinary review of 106 empirical articles found collective pay-for-performance only weakly associated with collective outcomes, with the underlying theory and boundary conditions still underdeveloped (Nyberg et al., 2018). A separate review found collective systems, alone or alongside individual pay, associated with higher performance, with no reviewed study showing individual incentives beating collective ones, while cautioning that moderation evidence is thin (Wood, Leoni & Ladley, 2023).

The most useful single result for our purpose is older and not about software at all. Studying pay dispersion across industrial workforces, Shaw, Gupta & Delery (2002) found that wide pay dispersion can support performance when there are individual incentives and the work is independent, but that pay compression is preferable when work is interdependent, or when there is no individual incentive system to justify the spread. Read that against a software delivery chain and the implication is direct: the more your value depends on people coordinating, the weaker the case for reward structures that visibly reward some individuals over others for the same shared outcome.

So the honest summary is not "individual bonuses are bad." It is that individual rewards are a design choice whose fit depends on task interdependence, fairness, how observable each person's contribution really is, and whether the organization needs cooperation or separable effort. For separable tasks with clean attribution, individual incentives have real support. For interdependent delivery, the support gets thinner exactly where you need it most.

What interdependent delivery needs from people

Look at what makes agile delivery teams effective, and you find behaviors that are hard to attribute to one person and easy to quietly withhold.

A teamwork effectiveness model for agile software development describes the working parts as shared leadership, team orientation, redundancy, adaptability, and peer feedback, coordinated through shared mental models, communication, and mutual trust (Strode, Dingsøyr & Lindsjørn, 2022). Notice what those are: helping when it is not your ticket, giving honest review feedback, keeping a shared picture of the system, covering for each other. None of them show up cleanly in an individual output metric. Several of them cost the individual something in the short term.

Quality behaviors sit in the same place. Research on psychological safety in agile teams, combining 20 interviews with a survey of 423 people, links psychological safety to admitting mistakes, taking initiative, and learning from past mistakes (Alami, Zahedi & Krancher, 2024). A reward structure that punishes the person who surfaces a defect, or that makes admitting a mistake look like admitting you missed your target, works against precisely the behavior that protects quality.

This is where incentive design and delivery design meet. If cooperation, peer feedback, honest status, and joint ownership are the coordinating mechanisms of your delivery, then a reward system that pays for individually attributable output is competing with your own operating model.

The failure modes to watch for

The risks are concrete and recognizable.

Local optimization. People keep their own station busy and their own numbers healthy while system-level items sit in a queue. Utilization looks great; lead time does not move.

Metric gaming. Any metric used as a target invites gaming, and delivery metrics are no exception. DORA's own guidance warns against turning delivery metrics into goals precisely because teams will optimize the number rather than the outcome, and warns specifically against a single headline metric, disparate cross-team comparisons, siloed ownership, and internal competition (DORA metrics guide). Bolt a bonus onto deployment frequency and you should expect the number to improve faster than anything a customer notices.

Withheld help and feedback. If review time, mentoring, or pairing is unrewarded overhead against a personal target, the honest economic signal is to do less of it. Review quality and peer feedback are the first things to erode.

Fairness friction. Perceived unfairness in how rewards are distributed is a live sensitivity, not a theoretical one. Both the mediation evidence (Chen et al., 2023, via distributive and procedural justice) and the interdependence evidence (Shaw et al., 2002, on pay compression) point the same way: when work is shared but rewards are visibly unequal, the fairness cost can outweigh the motivational benefit.

What you will not find is direct evidence that a particular bonus design improves cycle time, lead time, deployment frequency, or change failure rate. The software-flow evidence for incentive design is thin. The chain of reasoning is sound and the general performance evidence is solid, but nobody should present a bonus redesign as a proven lever on your DORA numbers. Treat it as removing a source of counter-pressure, not as installing a delivery accelerator.

Design choices, stated honestly

None of this argues for abolishing individual reward. It argues for matching the reward's unit to the work's unit.

Where contribution is genuinely separable and observable, and some specialist, individually owned work does qualify, individual incentives have evidence behind them. Where value only appears when an interdependent chain finishes, the reward's unit of account should move closer to the team or the delivered outcome, and pay differences for shared outcomes should be defensible on fairness grounds. Multidimensional views of productivity, such as the SPACE framing (Forsgren et al., 2021), are a reminder that no single attributable number captures what a developer contributes; a reward built on one proxy will always be rewarding a fraction of the work.

The decision is not moral, it is structural: how interdependent is the work, how observable is each person's contribution, and does this part of the organization need cooperation or separable effort? Answer that honestly per area, and the reward design mostly follows.

What to inspect on Monday

Add these to a Flow Audit before you touch boards or ceremonies. The goal is not to redesign compensation in a morning. It is to see whether your current incentives fight your delivery system.

1. What behavior does the bonus narrative actually reward? Read the plan and the internal story around it. Does it pay for finishing shared work, or for individually attributable output?
2. Where do individual targets attach to local proxies? List every target tied to tickets, points, or personal throughput, and ask whether protecting that number could delay system-level work.
3. Is helping unpaid overhead? For your key coordinating behaviors, review, pairing, mentoring, covering, is there any target that makes doing them a personal cost?
4. Are we bonusing a metric we told teams not to game? Cross-check reward targets against DORA's warning list: metrics-as-goals, one headline number, cross-team comparison, siloed competition.
5. Would a person on this team say the reward split is fair? For shared outcomes, are pay differences defensible on contribution and process grounds, or just inherited?
6. Does the reward's unit match the work's unit? For each area, is the work separable or interdependent, and does the reward account match that?
7. What would we expect to change if we removed the counter-incentive? Name the behavior, not the metric. If you cannot state the behavior you expect, you are guessing.

If several answers point the wrong way, that is your first delivery intervention, before the board.

Evidence and caveats

This piece reasons from general pay-for-performance research plus software-specific teamwork and quality research. The reasoning is sound; the direct software-flow evidence for incentive design is thin, and none of these sources measured cycle time or deployment frequency against a bonus design. Treat the argument as a design lens, not a proven lever.

• Alami, A., Zahedi, M., & Krancher, O. (2024). The role of psychological safety in promoting software quality in agile teams. Empirical Software Engineering, 29(5), Article 119. doi.org/10.1007/s10664-024-10512-1
• Chen, Y., Zhang, Z., Zhou, J., Liu, C., Zhang, X., & Yu, T. (2023). A cognitive evaluation and equity-based perspective of pay for performance on job performance: A meta-analysis and path model. Frontiers in Psychology, 13, Article 1039375. doi.org/10.3389/fpsyg.2022.1039375
• Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., & Butler, J. (2021). The SPACE of developer productivity: There's more to it than you think. Queue, 19(1), 20–48. doi.org/10.1145/3454122.3454124
• Garbers, Y., & Konradt, U. (2014). The effect of financial incentives on performance: A quantitative review of individual and team-based financial incentives. Journal of Occupational and Organizational Psychology, 87(1), 102–137. doi.org/10.1111/joop.12039
• Harvey, N. (2026, January 5). DORA's software delivery performance metrics. DORA. dora.dev/guides/dora-metrics
• Nyberg, A. J., Maltarich, M. A., Abdulsalam, D. D., Essman, S. M., & Cragun, O. (2018). Collective pay for performance: A cross-disciplinary review and meta-analysis. Journal of Management, 44(6), 2433–2472. doi.org/10.1177/0149206318770732
• Shaw, J. D., Gupta, N., & Delery, J. E. (2002). Pay dispersion and workforce performance: Moderating effects of incentives and interdependence. Strategic Management Journal, 23(6), 491–512. doi.org/10.1002/smj.235
• Strode, D., Dingsøyr, T., & Lindsjørn, Y. (2022). A teamwork effectiveness model for agile software development. Empirical Software Engineering, 27(2), Article 56. doi.org/10.1007/s10664-021-10115-0
• Wood, S., Leoni, S., & Ladley, D. (2023). Comparisons of the effects of individual and collective performance-related pay on performance: A review. Human Resource Management Review, 33(4), Article 100982. doi.org/10.1016/j.hrmr.2023.100982

A note on market signal: recent reporting suggested employees at a large manufacturer reacted strongly to unequal bonus distribution. Treat that only as weak evidence that fairness sensitivity around bonuses is real and current, not as evidence for any claim in this article.