The Person Who Prevented The Problem Got No Credit

Hello Learners,

This is Learn Leadership. Every issue takes one thing that quietly goes wrong between managers and their teams, shows it happening through a real story, and leaves you with something to try this week.

Today it's recognition that goes to whoever put out the fire and skips whoever stopped the next one. You'll leave with a three-line thank-you note built for prevention and one Monday question that finds it.

Thursday night, 11:40

At 11:40 on a Thursday night, Dan pushed the hotfix that brought checkout back. The launch had gone live at nine, and for 22 minutes a rounding bug had been rejecting discount codes. He found it, fixed it, and posted a screenshot of the green dashboard in the launch channel. Forty-one people reacted.

At Friday's all-hands, the CEO thanked Dan by name. There was applause and a gift card, and someone called him "the launch-night hero," which stuck for a month.

Amara sat in the third row and clapped too. She's the QA lead, and three weeks before launch she'd opened an email from the payment provider that everyone else on the list had archived. It said the old API version would switch off on launch day.

She spent four days moving the integration to the new version and testing 212 payment paths. Her only record of it was a ticket comment. If she'd archived that email too, every payment on launch night would have failed at the first click, and Dan's 22 minutes would have been a footnote.

She didn't bring it up at the all-hands, and nobody asked. To everyone else in the room, launch night had one near miss, and Dan had caught it.

What was actually going on

Recognition followed the last person who touched the problem. Dan's fix had everything praise likes: a timestamp, an audience, and a clear before and after. Amara's work had nothing to point at, because its whole product was a night that went fine.

Nelson Repenning and John Sterman of MIT's Sloan School ran into this while studying why process improvement efforts stall. An engineer at a car company summed it up for them: "Nobody ever gets credit for fixing problems that never happened."

Their 2001 paper describes where that leads. Organizations stuck in firefighting reward and promote the people who rescue troubled projects, and those people go on to favor more rescuers like themselves. One project leader told the researchers his own promotions had come from delivering programs under duress.

The same paper explains why this loop is hard to break. Working harder pays off straight away and is easy to see. Improvement work, like upgrading an integration early or writing the documentation, makes things a little slower before it makes them better. A manager who only looks at this week will pick firefighting every time.

The pattern underneath

Praise works as an instruction. Every public thank-you tells the room what kind of work gets seen here, and people adjust to it.

Adam Grant and Francesca Gino tested a version of this with university fundraisers in a 2010 field experiment on gratitude. The annual giving director visited one group of callers and thanked them for their work. In the following week, the number of calls the average thanked fundraiser made rose by more than 50 percent.

The researchers traced the lift to one thing: the thanked callers felt more valued by the person who ran the program. When a senior notices your work, you do more of it, and it keeps working after the thank-you.

So when you only thank rescues, you're teaching your team that rescues are the job. The people who prevent problems keep at it for a while, out of pride. Then they notice what the applause is for.

What to do Monday

Start by finding the prevention. It won't announce itself, so ask for it. In Monday's team meeting, go round the table with one question: "What didn't go wrong last week because someone caught it early?" Write down the names.

Then thank it properly. "Thanks for being proactive" slides off people, because it never says what was prevented. Use three lines:

• What they noticed, and when;
• What they did about it;
• What would have happened otherwise, with a number if you have one.

For Amara, that sounds like this: "You caught the provider's API deadline three weeks out. You moved the integration and tested 212 payment paths. Without that, every payment on launch night would have failed." It takes under a minute to read aloud.

Say it in the room where the rescue got thanked. If the hotfix earned an all-hands mention, the prevention gets one too, in the same meeting and at the same volume.

Then put the same three lines in writing, in the channel or in an email that copies their skip-level manager. The spoken thanks is for the room. The written version is what shows up when someone opens their file at review time, and prevention usually has no other record.

Where this goes wrong

The first trap is taking credit away from the firefighter. Dan worked hard at midnight and deserves his thanks. Put Amara's thank-you next to his.

The second is inflated counterfactuals. Once people learn that "prevented a disaster" earns applause, you'll start hearing about disasters that were never coming. Ask for the evidence: the email, the ticket comment, the date. Amara's comment was timestamped three weeks before launch, which made her easy to credit.

The third is waiting for something big. Prevention usually comes in small sizes, like a renewal caught in time or a wrong figure spotted before a client saw it. Credit the small ones too, or people will stop mentioning them.

One thing this week

Your one thing is the Monday question. Ask it, write the names down, and send one three-line note before Friday.

The Friday after launch, Amara's manager Maya asked for two minutes at the all-hands and read her three lines out. The CEO asked Amara to walk the leadership team through how she tracks provider emails, and two other teams had copied her system within a month.

Dan clapped the loudest. He'd been on the provider's mailing list too.