Incentives

The idea

Charlie Munger placed reward and punishment first in his list of the causes of human misjudgment, in "The Psychology of Human Misjudgment", a talk he first gave at Harvard in 1995 and later revised for Poor Charlie's Almanack. His point was that almost everyone believes they understand how much incentives shape behaviour, and almost everyone underestimates it.

One of his examples is Federal Express. Its overnight sorting operation kept running late until the company stopped paying night-shift workers by the hour and paid them by the shift, letting them go home when the planes were loaded. The delays went away.

Architecture standards fail in the same way when they conflict with what teams are measured on. If teams are rewarded only for feature velocity, they will route around the review board, however good the standard is.

Why it works

People respond to what is rewarded, not what is requested. A request competes with every other demand on a team's time; a reward shapes priorities directly.

Incentives often work invisibly. Teams rarely decide to ignore a standard. They simply choose, every day, the option that their goals, budgets and promotion criteria favour.

Misaligned costs and benefits stall good ideas. When one team pays the cost of a change and another team gets the benefit, the change waits, even if it is clearly right for the organisation.

Where it applies

• Architecture governance, when adoption of standards or platforms is low.
• Shared platforms and reuse, where the team that builds a shared component pays for it while others benefit.
• Funding models, such as project budgets that reward shipping and penalise maintenance.
• Vendor and outsourcing contracts, where payment terms shape behaviour more than the statement of work.

How to apply

1. Find out what teams are really measured on: objectives, budgets, performance reviews and what leaders praise.
2. Trace costs and benefits of the behaviour you want. Note who pays and who gains.
3. Make the desired path the easiest path, with templates, tooling and platforms that remove the cost of doing the right thing.
4. Align goals. Work with leadership so architectural outcomes count toward team objectives, and fund shared work centrally where needed.
5. Watch for side effects. New incentives create new behaviour, not all of it intended.

Example scenario

An API-first mandate saw little adoption. For a product team, building a proper API added a couple of weeks to each delivery and earned no credit, because objectives counted only features shipped. Teams agreed with the mandate in meetings and quietly skipped it.

The architect stopped arguing for the principle and changed the economics. A platform team automated API scaffolding, documentation and publishing, and reuse of a team's APIs by other teams was added to its quarterly goals. Adoption rose within two quarters, without any extra enforcement.

Questions to ask

When not to use it

• As the only lens on behaviour. Habit, skill gaps, fear and simple lack of information also explain why people do what they do.
• When you cannot change the incentives. Understanding them still helps, but the remedy may be to work with them rather than redesign them.

How it misleads you