Every product organization says it wants teamwork, candor, and total quality. Then it pays for individual results, reported good news, and shipping on schedule, even with defects. Steven Kerr named this failure in 1975, in a paper whose title has done fifty years of work: On the Folly of Rewarding A, While Hoping for B, published in the Academy of Management Journal and republished as an Academy Classic in 1995. People do what pays, to the near-exclusion of what doesn’t. Twenty years after the paper, the Academy surveyed its executive panel: 90 percent said the folly still ran their companies. Nothing since suggests it has retired.
The fast-team research points one way out, and it starts with a distinction most pay systems blur. An incentive is a formula announced in advance: hit this number, receive this payment. It steers behavior before the fact, toward the number as written, defects included. A reward is recognition after the fact of an outcome judged whole, with room for the judgment a formula cannot hold. Teams that reward performance keep their cooperation and their honest data. Teams that incentivize get the metric and lose everything the metric does not price. Fast teams reward performance. They do not incentivize it.
The schedule-only trap
Kerr’s diagnosis explains why cooperation is the first casualty: managers gravitate to objective, quantifiable criteria and to behaviors that are easy to see. Cross-functional cooperation is neither. A date is both. So schedule, the most visible and most quantifiable number in a program, becomes the incentive by default, and a team paid on the date will make the date. What moves to protect it is everything the formula does not price: qualification scope, test coverage, scrutiny of the new and difficult parts, the honest red. That is why right product sits inside the target at equal weight with right time. A milestone paid as a date is an invitation to redefine doneness. A milestone judged on its doneness criteria protects the product while the schedule discipline protects the date.
The general rule: every speed measure needs a counterweight, or it produces the behavior it was meant to prevent. Cycle time alone buys cut corners. Gap-to-target alone buys padded plans. A date, paid, buys redefined doneness.
Money corrupts the measurement
There is a second cost, and it is the more expensive one. The moment a red trend triggers punishment, the reds stop being honest and the chart goes green and useless in the same quarter. Our control-systems research found the same pattern at the organizational level: the high-control organizations were not the fast ones. The fast ones paired autonomous teams with honest, frequent, low-ceremony measurement. The instrument and the paycheck have to stay apart. The wigglechart exists to make slip visible as it forms; put it in the pay system and it stops being true. Recognize pull-ins and early bad news in the room instead: name them in the refresh, in front of the team. Keep measurement out of the pay formula and it stays honest.
The team earns it together
Kerr’s sharpest example comes from sports: coaches preach teamwork, rewards follow individual statistics, and the player who passes instead of shooting doesn’t get drafted. Putting yourself first becomes the rational move. Swap in the functional version and it reads like a swimlane org chart: the engineer paid on functional output is rational to optimize the silo.
A product is an indivisible team outcome. No function can ship a product alone, and the result is only measurable at the team level. Carve the outcome into slices and pay each person for theirs, and you rebuild the swimlane inside the team. The benchmarks back the team side: in the APQC study, genuinely cross-functional teams were present in 79.3 percent of the best-performing businesses and 7.7 percent of the worst; the numbers are in our Twelve numbers paper. Katzenbach and Smith drew the harder line in The Wisdom of Teams (1993): a real team is defined by mutual accountability to common goals, and people accountable only for their functional slice are a working group wearing a team’s name.
The split that works is clean. The team earns the product reward together. The function develops the individual: technical competency, craft, and career path stay with the functional manager. Recognition and development are different channels. Conflate them and the raise pulls the lead back to the silo.
What to do
Reward the core team as a team. After the fact, on the whole outcome: the product qualified at the customer and the date it shipped, judged together. Every core seat earns from the same event at the same weight, the quality lead alongside design. Criteria stated as principles, never as a formula.
Never pay on a date alone. A milestone counts when its doneness criteria are met, not when its box turns green. Any schedule recognition carries its quality pair or it doesn’t exist.
Keep the wigglechart out of the pay system. It exists to make slip visible as it forms. Recognize pull-ins and early bad news in the room instead.
Route recognition through the product, not the function. In the heavyweight model the core team leader conducts or influences 50 to 100 percent of core-member reviews; that influence is the designed counterweight to functional pull, while the functional manager keeps development and craft. Used fully, the raise follows the product outcome.
If executive pay must move, move it late and move it together. One shared slice on the same portfolio numbers, at the same weight, for the whole leadership team, and only after the definitions have survived several quarters. Function-by-function bonuses rebuild Kerr’s folly at the top of the house.
What you make payable
Kerr settled the underlying question half a century ago: people do what pays. That is not the problem. The problem is what you make payable. Make the number payable and you will get the number, exactly as written, defects included. Make the whole outcome recognizable, after the fact, at the team level, and you will get the product. Pay for the number and you get the number. Reward the outcome and you get the product.
Related reading: Control Systems Don’t Generate Speed, Do tighter control systems create faster projects?, Fast Autonomous Teams, Integrated Core Team, The Rhythm of Accountability, Ten numbers on two clocks, The Product Boss owns the product; the Program Manager owns the plan, and Where targets come from.