How Dev Managers Can Encourage Accountability After a Team's Failure (Without Everyone Getting Defensive)

How Dev Managers Can Encourage Accountability After a Team's Failure (Without Everyone Getting Defensive)
Photo by Steven Coffey / Unsplash

I’ve made a lot of mistakes in my career.

Some of them had serious consequences. Production downtime, lost revenue, frustrated users, and more. And each time it was always easier to point fingers or spread the blame around.

I learned that was just my ego's self-defense in action, working to protect the perception I had of myself.

We all think we’re competent and doing a good job

Nobody on your team wakes up in the morning and thinks “I’m terrible at my job and have no idea what I’m doing!”

Instead they all think they’re good people, who are capable, and are doing good work. This positive self-perception is critical for them – and everyone else – to get through the day without second guessing every decision or action.

So when they have conflicting information, like when they make a big mistake, they are forced to reconcile.

Defensiveness and shifting blame is human nature

The easiest way to reconcile a conflict between our self-perception and reality is to get defensive.

That’s why you get excuses and finger pointing when you go to your team expecting some ownership and accountability. Your team members know they bear some responsibility for things going wrong. But it’s a lot easier to maintain “I’m good at my job” when it's not 100% their fault.

Which means you can take a shortcut to accountability by helping your team reinforce their self-perceptions.

Reinforce, Reimagine, Reset

The next time you’re expecting more accountability after a mistake, try this simple framework: Reinforce, Reimagine, Reset

  1. Reinforce their self-perception (e.g. “Look, we’re a good team, and even good teams make mistakes.”)
  2. Reimagine how the situation could have been handled (e.g. “What could have gone differently?”, “If we had to do it all over again… how would it go?”)
  3. Reset expectations around ownership and accountability (e.g. “It’s true that QA could have done more testing, but I expect this team to ultimately be responsible for quality.”)