Lots of organizations try to prevent developers from making mistakes, or catch them doing so, leading to more bureaucracy and over-control. Some examples include:

• Requiring all teams to follow the exact same process.
• Using permissions to keep developers from rebasing code with Git.
• Managers external to the team running compliance reports on whether user stories are filled in "correctly."
• Penalizing developers using development issues/bugs as a metric.

Let's look at that last one more closely. One of the DORA group's Four Metrics is to capture how often release failures occur. One way to think of that is "how many severe bugs are we getting after release?"

It's tempting, then, to also track how many issues/bugs are found during development, the notion being that reducing bugs during development naturally reduces them in release. But this is wrong headed. There could be value in looking at issues found during development, but it's wrong to use this to evaluate, praise or punish developers. Why?

• More issues found during development isn't good or bad.
• Context is missing if you're only looking at numbers.
• Whether and how development issues are reported is highly person-dependent.

In short, you can't tell whether a developer is doing a good job based on development issues. That isn't why you'd capture development issue metrics. You would capture them as one metric to compare the effects of making development changes. For example, a team commits to increasing unit test quality. What effect did that have on the number of issues found?

What are you even tracking? Is it the number and severity of issues found by QA? That might be OK. But how do you know that Billy has the same standard for "severe" as Claudia? Maybe Rahim breaks down an issue into more bug reports than Luciana.

This is when bureaucratic management tries to get everyone working the same way with endless meetings on "what does severe mean?" and "what's the right way to report issues?" Some of this matters, sure. But thinking this way more often misses the point. Its focus is on treating people as replaceable resources, as machines.

The coercive style of management has these qualities:

Restrict. Prevent. Catch. Punish.

Those qualities can be summed up as "Developers, we don't trust you."

What if, instead, we use a reliable metric--change failure rate--to guide improvement? Further, what if we let the teams figure out how to make that improvement, allow for mistakes, and measure what matters? We'd end up with a trusted team.

In a Trust Team environment, you

• Give your developers more permissions.
• But also keep audit trails so if something goes wrong we know who did what.
• Create a robust system that can be recovered quickly.
• Notify developers of problems automatically and immediately.
• Help understand what caused issues and how to improve.

Again, let's dig into that last one and contrast to an untrusted team.

In the untrusted team, if a severe bug is discovered, several assumptions are made.

• One person is at fault. The team isn't treated as a unit.
• The developer made a mistake. There's someone to blame.
• The bug could have been prevented.
• There needs to be a meeting to put procedures in place to keep it from happening again.
• Non-team management is needed to enforce the new process.

In a trusted team,

• The team takes responsibility, knowing multiple people work on the code.
• The developer may have made a mistake. But there's no blaming because mistakes are part of development.
• Not everything is in our control. Software's very complex. The developer may have made the right decision, even though there was a poor outcome. You can't prevent all bugs.
• Adding process adds complexity to an already complex business. Sometimes process needs improvment. But often there's nothing to fix.
• As soon as external management insists on compliance reports, the team ceases to be self-managing. Quality will go down, because the focus shifts from building software to pleasing management.

In the future, when something goes wrong:

1. Determine and explain the impact on the overall business.
2. Let the team sort things out.
3. Ask them to inform management what, if anything, will change.
4. Trust their answer.

Build trust, not scapegoats.