Table Of Contents
Something goes wrong. A defect escapes. A deadline slips. A customer complains.
And almost immediately, someone asks: “Whose fault is this?”
It’s a natural instinct. When things break, we want to know why. We want to understand what happened. And somewhere along the way, “what happened” becomes “who did this,” and understanding becomes blame.
I’ve been in plenty of rooms where this plays out. The finger-pointing, the defensiveness, the careful distancing from responsibility. It feels productive in the moment. It feels like accountability. But it’s not. It’s just noise.
Blame doesn’t fix problems. It just makes people afraid to admit them. It also makes people leave.
The Instinct to Blame
Let’s be honest: blame feels satisfying.
When something goes wrong, there’s a tension that needs to be released. Someone needs to be responsible. Finding that person, naming the fault, feels like resolution. The problem has been identified. Justice has been served. We can move on, call it closure.
Except we can’t. Because blame doesn’t actually solve anything.
The defect that escaped? It’s still in production. The deadline that slipped? The project is still behind. The customer complaint? They’re still unhappy.
Blame addresses none of this. It just assigns fault. And once fault is assigned, people stop thinking about how to fix the problem and start thinking about how to protect themselves.
That’s the trap. Blame feels like action, but it’s actually avoidance. It lets us feel like we’ve done something without doing the hard work of actually improving.
Why Blame Makes Things Worse
Here’s what happens when blame becomes the default response to problems. Similar to what happens with accountability gone wrong.
People stop admitting mistakes. If owning up leads to punishment, people learn to hide. They cover their tracks, minimise their involvement, or stay quiet and hope no one notices. The mistakes don’t stop happening. They just stop being visible until they’re too big to ignore.
Learning disappears. Every mistake is an opportunity to understand something better. But blame shuts down curiosity. Instead of asking “why did this happen?” the team asks “who did this?” The focus shifts from understanding to defending, and the lesson gets lost.
Trust erodes. When people are blamed publicly, it damages relationships. The person blamed feels resentful. Others watch and think, “That could be me next time.” The team becomes guarded, cautious, less willing to take risks or speak openly.
The same problems repeat. Without learning, there’s no improvement. The root cause never gets addressed. Six months later, the same issue surfaces again, and the cycle repeats. Different person, same blame, same lack of progress.
Good people leave. No one wants to work in an environment where they’re one mistake away from being thrown under the bus. The best people, the ones with options, will eventually find somewhere healthier to work.
Blame feels like accountability, but it’s actually the opposite. Real accountability is about owning outcomes and improving. Blame is about finding someone to punish so everyone else can feel absolved.
The Alternative: Curiosity and Learning
What if, instead of asking “whose fault is this?” we asked “what can we learn from this and how can we avoid this happening in future?”
It’s a simple shift, but it changes everything.
Curiosity opens doors. It invites honesty. When people know they won’t be attacked for admitting mistakes, they’re more likely to share what actually happened. And when you understand what actually happened, you can actually fix it.
This doesn’t mean ignoring problems or letting poor performance slide. It means separating the incident from the person. Addressing the behaviour, not attacking the individual. Focusing on improvement, not punishment.
The goal isn’t necessarily to make people feel comfortable with failing. Although that does have an upside. It’s to create an environment where failure leads to learning, not hiding.
Some questions that help:
- “What happened?”
- “What did we miss?”
- “What would have helped us catch this earlier?”
- “How do we make sure this doesn’t happen again?”
- “What support do you need?”
These questions assume good intent. They assume the person involved didn’t want things to go wrong. They focus on systems, processes, and understanding, not on finding someone to punish.
That’s the shift from blame to learning.
Guide Instead of Grump
A few years ago, I started using a phrase with myself: “guide or grump.”
It’s a reminder. When something goes wrong and I feel that instinct to react, to criticise, to point out what should have been obvious, I pause. And I ask myself: what would be more useful here? Venting my frustration, or helping this person do better next time?
The answer is almost always the second one.
Grumping feels good in the moment. It releases tension. It signals that you care about quality and standards. But it doesn’t teach anything. It just makes people feel bad, and feeling bad doesn’t make anyone better at their job.
Guiding takes more effort. It means understanding what went wrong, why it went wrong, and what the person needs to avoid it next time. It means having a deeper and sometimes lengthy conversation, not delivering a verdict.
In practice, guiding looks like:
Asking before telling. “Walk me through what happened” gives you information and gives them a chance to reflect. Jumping straight to “you should have done X” shuts that down.
Focusing on the future. “Next time, try this” is more useful than “you shouldn’t have done that.” People can’t change the past, but they can change what they do going forward.
Assuming capability. Most people want to do good work. If they made a mistake, it’s usually not because they’re incompetent. It’s because something was unclear, or they lacked information, or the process failed them. Start there.
Being specific. Vague criticism (“you need to be more careful”) doesn’t help. Specific guidance (“check the integration points before marking it done”) gives them something to act on.
Following up. Guidance isn’t a one-time conversation. Check in later. See if things improved. Offer more support if needed. Show that you’re invested in their growth, not just in catching their mistakes.
None of this means lowering standards. You can have high expectations and still treat people with respect. In fact, the teams with the highest standards are often the ones where guidance is the norm, because people aren’t afraid to push themselves and admit when they fall short.
What this Looks like in Practice
Let me give you a few examples from my own experience.
The missed defect. A tester on my team missed a significant defect that made it to production. My first instinct was frustration. How did this get through? For me, that came from knowing the heat I’ll get from above. But instead of leading with that, I asked them to walk me through things. Turns out, the test and production environments didn’t match, and the defect only appeared under specific conditions no one anticipated. The problem wasn’t carelessness. It was a gap in our environment setup. We fixed the environment configuration, added a check to our process, and the tester felt supported rather than blamed. They became more diligent, not less confident.
The recurring issue. A team kept having problems with a particular integration. Every few sprints, something would break. The instinct was to blame whoever touched it last. But when we dug in, we realised the integration was poorly documented, the API was inconsistent, and no one fully understood how it worked. The problem wasn’t individual failure. It was systemic. We invested time in documenting the integration properly and creating a checklist for future changes. The recurring issues stopped.
The junior who was struggling. A junior tester was making frequent mistakes, and some team members were getting frustrated. Instead of piling on, I spent time understanding what was going wrong. Turns out, they’d been thrown into the deep end without proper onboarding and poor Jira ticket information. They didn’t know what they didn’t know. I spent some time with them and then we paired them with a more experienced tester, created some structured learning, and within a few months they were one of the most reliable people on the team. If we’d just blamed them for the mistakes, we’d have lost them.
In each case, the instinct to blame was there. But resisting that instinct and choosing guidance instead led to actual improvement, not just for QA but for the entire sprint team. That’s the difference.
The Leader’s Role
If you’re in a leadership position, the tone you set matters more than you might realise.
When something goes wrong, your team is watching. They’re watching to see if you blame or if you learn. They’re watching to see if it’s safe to admit mistakes or if they need to protect themselves. Your reaction in that moment shapes the culture more than any company values statement ever will.
Here’s what I’ve learned:
Go first. When you make a mistake, own it publicly. Show the team that admitting fault is safe because you do it yourself. “I got that wrong” from a leader is powerful.
Control your initial reaction. The first few seconds after hearing bad news set the tone. If you react with anger or blame, that’s what people remember. Take a breath. Respond with curiosity, even if you’re frustrated inside.
Praise learning, not just success. When someone admits a mistake and learns from it, recognise that. “I appreciate you owning up and working through it” reinforces the behaviour you want.
Address patterns, not incidents. If the same person keeps making the same mistakes despite guidance and support, that’s a different conversation. But one mistake isn’t a pattern. Don’t treat it like one.
Protect your team from external blame. When stakeholders or other teams want someone to blame, shield your people. Take the heat yourself if needed. Your team will notice, and they’ll trust you more for it.
The goal is to build a team where people feel safe to take risks, admit mistakes, and learn. That doesn’t happen by accident. It happens because the leader creates that environment, consistently, over time.
The Take
Blame is easy. It’s instinctive. And it does “feel” like accountability.
But it doesn’t fix anything. It just makes people afraid, and afraid people hide, defend, and stop learning.
The alternative is harder but better. Curiosity instead of accusation. Guidance instead of grumping. A focus on improvement instead of punishment.
This doesn’t mean ignoring problems or accepting poor performance. It means addressing issues in a way that actually leads to change, rather than just making someone feel bad.
The best teams I’ve worked with aren’t the ones where no one makes mistakes. They’re the ones where mistakes are caught early, discussed openly, and learned from quickly. That only happens when blame isn’t the default response.
So the next time something goes wrong, resist the instinct. Don’t ask “whose fault is this?” Ask “what happened and what can we learn?” Guide instead of grump.
You’ll be surprised how much more you get done when people aren’t afraid to admit what went wrong.
A Note on Context
Every business and every project is different. What works in one place won’t work in another, and that’s the point.
Nothing here is meant to be a step-by-step prescription. It’s guidance, drawn from my own experiences, and deliberately kept general to avoid pointing fingers anywhere.
Take what’s useful, ignore what isn’t, and adapt it to your own context. Or as Joe Colantonio always says: “Test everything and keep the good.”
