What You Praise Is What Your Team Becomes

Firefighters are heroes. They run into dangerous situations and save people. But think about why we need them. Our built environment has been assembled over centuries by many different hands with differing ideas about what matters. This legacy of inconsistent design, coupled with our varying attitudes to fire safety, means we need a professional fire service in continuous deployment to deal with fires (and, of course, cats up trees).

Now think about inspectors. They're portrayed as jobsworths - busybodies getting in the way of business. Yet consider this: what's more costly - paying extra for fire-retardant insulation, or crawling through the ash pile that was your home looking for the baby photo album?

Prevention is cheaper than reaction. Everyone knows this. Yet somehow the firefighter is the hero and the inspector is the nuisance. The same dynamic plays out in software teams every day - and the consequences are worse than you might think.

We Optimise For What We Praise

It's easy to see how someone looks at a developer putting out fires and thinks that's the most important person on the team. It's easy to see how that firefighter then gets praised for how they handled the crisis. And it's easy to see how that positive feedback incentivises that person to jump from one fire to the next - I mean, who doesn't like being treated like a superstar?

Now think about the developer who spent a quiet afternoon writing the test suite that would have caught that fire before it started. No drama, no late night, no Slack channel lighting up. Just a merge request that nobody remembers. That developer will never be treated like a superstar for it, but their work was worth more.

This is where the feedback loop takes hold. Firefighting is visible and measurable. Prevention is neither. It's straightforward to measure that your server is no longer crashing. It's much harder to measure the impact a unit test had on preventing that crash to begin with. And because we can't easily measure prevention, we don't reward it, which means we keep rewarding the firefighting that poor engineering practices made necessary.

Over time, this praise loop reshapes the team. Other developers see that the route to that bonus or that promotion is to be a firefighter rather than an inspector. They stop having those awkward conversations that drive better engineering practices because there isn't any reward for it. The engineering effort changes to focus on getting that fix out rather than preventing the fire.

Meanwhile, the root causes never get fixed. Why would it? The team is coping. Management sees a crisis handled well and moves on. Nobody is asking why the crisis happened in the first place because the reaction looked like success. The codebase quietly degrades, becomes more fragile, and the fires become more frequent. Eventually, even praise isn't enough to motivate the team, as burnout sets in.

The team hasn't been optimised for quality. It's been optimised for visible heroics.

Other organisational factors can and do contribute to the need for firefighting, such as understaffing, unrealistic deadlines, too many priorities, etc. Often these organisational factors are outwith the control of the team. In this post, I've only focused on the praise feedback loop, as this is an area that a team can more easily internally shape.

How To Reward The Right Work

Breaking out of this praise loop doesn't mean ignoring firefighting - firefighting is meaningful work, it deserves recognition - it means shining a light on the preventive work to balance the praise scales. Once the smoke clears from the latest firefighting, the question that matters isn't "who saved us?", it's "why did we need saving?". The answers to that question almost always point back to the same two things: poor communication and weak enforcement of standards.

Communication

The goal is to eliminate surprises. When code changes land on the main branch, nobody should be seeing them for the first time. Here's how to get there:

Daily standups that surface blockers early. Not status updates where everyone recites what they did yesterday - actual conversations about what's stuck, what's about to change, and what might conflict. If two people are working in the same area of the codebase and don't know it, that's a communication failure waiting to become a merge conflict. When someone flags a conflict early and saves the team a painful merge, that's worth calling out.

Peer reviews with real feedback loops. Reviewing isn't a rubber stamp. It's the single best opportunity to catch problems while they're still cheap to fix - a comment on a pull request costs minutes. The same issue found in production can cost hours or days. The best reviews look beyond the code to the decision-making that led to that code, so be on the lookout for anyone who is only reviewing solely as a linter and guide them to be better reviewers. A thorough review that catches a design problem before it ships is exactly the kind of work that deserves recognition.

Linting is important, but we can give that job to the computer - check out SwiftLint.

Short feedback cycles between everyone. Peer-to-peer, lead-to-developer, developer-to-lead. The longer an issue goes unspoken, the more expensive it becomes. If a developer is struggling with an approach, the worst outcome is finding out two weeks later when the work needs to be thrown away.

Enforcement

Communication decides what the standard is. Enforcement makes sure it sticks.

Automated testing as a safety net. This is the single most important enforcement mechanism. A test suite that runs on every commit catches regressions before they reach anyone. It's the inspector who never takes a day off. Without it, you're relying on human vigilance alone - humans get tired, the computer never will.

Coding conventions that the team owns. Not a document that was written once and forgotten - a living agreement that evolves with the codebase. Developers tend to write code to match the quality of existing code. If the codebase is of poor quality, new code will match it. If it's clean, new code will match that instead. This gravitational pull means it's much easier to maintain a standard than to achieve one. Once you've done the hard work, don't let it slip. The temptation here is to list out absolutely everything and create a dense rulebook because it feels safer - don't do this, choose the top 5 to 10 conventions and document those, outside of that, let the team express itself. If everything is a priority, nothing is.

I've fallen to the temptation of writing a massive rulebook before, it gets too prescriptive. It leads to code reviewers only enforcing it and not actually looking at what the code is trying to do.

Peer review as enforcement, not just communication. Reviews sit in both categories for good reason. They're how knowledge spreads (communication) and how standards are maintained (enforcement). A review that catches a shortcut isn't nitpicking - it's preventing the slow erosion of quality that turns a clean codebase into a mess.

Be careful with overapplying the advice above. Don't praise prevention work just because it's prevention work. Praise it when it reduces real risk, improves delivery or prevents repeated pain.

Unlike firefighting, the impact of prevention rarely shows up in one dramatic moment - it shows up in trends. Fewer hotfixes. Deadlines hit more often. Bugs caught before they reach production. Make those trends visible - a dashboard, a retro talking point, release health metrics - so the team can see what prevention actually looks like over time.

No team exists in a bubble where they can dictate what they work on - features need to be shipped, and deadlines need to be met. Focus on improving the areas the team controls.

Praising Your Inspectors

Somewhere on your team, right now, someone is doing inspector work. Writing a test, flagging a conflict early, holding the line in a review.

Nobody will remember it by Friday.

Start there. Find that work, name it, and make sure the team knows it mattered - because what you praise is what your team becomes.