Motivation and Incentives

The default approach to motivating employees in most organisations is straightforward: pay people more when they perform well, and the performance will follow. The practice is widespread, but the research tells a more complicated story. For routine, repetitive work, financial incentives reliably improve output. For complex, creative, judgment-heavy work (which describes most of what a Stream Team does), they often reduce performance.

Goal

To design motivation and incentive structures that support the kind of work Product Teams actually do, rather than transplanting structures designed for a different kind of work.

Context

The research on extrinsic motivators is older and more consistent than most managers realise. Three findings worth knowing:

• Glucksberg (1962): extrinsic motivators reduce performance on creative tasks. In his famous candle-mounting experiment, the group offered a financial reward solved the problem more slowly than the unrewarded control.
• Deci (1971); Lepper, Greene and Nisbett (1973): extrinsic rewards diminish interest in complex tasks. People who were paid to do something they previously enjoyed reported lower interest in continuing the activity once the payment stopped.
• Mellström and Johannesson (2008): offering money for blood donation reduced the number of women who donated. The financial incentive crowded out the intrinsic motivation people had to give blood for free.

The common explanation is that humans have two distinct motivational systems. Intrinsic motivation comes from the work itself: mastery, autonomy, purpose, the satisfaction of solving a hard problem. Extrinsic motivation comes from outside: pay, recognition, fear of being fired. The two interact in non-obvious ways, and adding a strong extrinsic motivator can crowd out the intrinsic one.

For routine work where there is no intrinsic motivation to crowd out, this isn't a problem and bonuses work as expected. For creative, judgment-heavy work where intrinsic motivation drives most of the performance, bonuses can backfire.

What this means for Product Teams

The work done inside a Stream Team is largely judgment-heavy: deciding what to research, what to build, what to drop, what to refactor. Designing the bonus system as if the team were on a production line tends to produce two predictable failure modes:

• Goodhart's Law applies. Once a measure is used to determine bonuses, people optimise for the measure rather than the underlying outcome. Engineers ship features that move the metric without solving the problem; researchers run interviews with users they expect to confirm the bet; designers polish the things that get shown in reviews.
• Intrinsic motivation erodes. Practitioners who used to care about doing good work start asking instead what counts toward the bonus. The shift is gradual and hard to measure, but the team's natural quality bar slowly drops to whatever the measurement system rewards.

What works instead

The honest answer is that no incentive structure is perfect, but a few approaches reduce the failure modes:

• Pay people fairly for their level. Get the base compensation right relative to the market and to the performance level the person operates at. Most of the motivational gain from money comes from feeling fairly paid; very little of it comes from variable performance bonuses.
• Make the work itself motivating. Autonomy, mastery, purpose, and belonging are doing more work than the bonus is. Stream Teams that own their value stream and see the customer impact of their work tend to need less extrinsic incentive than teams that are handed a backlog and asked to ship it.
• Use multi-level bonuses instead of pure individual ones. A bonus that combines team, product, and ecosystem-level performance reduces the gaming that happens with individual targets, because no individual fully controls the team or product outcome.
• Be transparent about how performance is evaluated. Even when there are no individual bonuses, people want to understand how their work is being judged. A clear, public evaluation rubric reduces anxiety and removes the implicit incentive to manage upward instead of doing the work.

Anti-patterns

• Stack-ranking and forced distributions. Public ranking against peers reliably damages collaboration. The team becomes incentivised to avoid helping colleagues whose performance is being compared to theirs.
• Per-feature bounties. Paying people to ship features encourages shipping more features, not better features. Most product organisations already over-ship.
• Bonus tied to a metric the individual doesn't control. Frustrating and demotivating. If the only honest answer is "the team owns this outcome," make the bonus a team bonus.
• Removing all financial recognition for top performers. The other extreme. Top performers know they're top performers and will leave if their compensation doesn't reflect it. The goal is to compensate fairly through level and base pay, not to flatten the curve.