Accountability is not the same as blame.

For much of my career leading software engineering teams, “accountability” was often described in rather violent terms.

Who is the “one throat to choke?” Whose “head is on the chopping block” if things don’t go well?

Eeew… We actually talked that way.

In some respects, it was an artificial grab for respect or authority. We were saying, “Team, you need to do listen to me, or to do what I say, because I’m protecting you, shielding you from the sandstorm of blame that’s coming if things fail.”

That’s what we thought it meant to be “held accountable” for something.

But the fear of blame is really not a great motivator. And that is not what Patrick Lencioni is referring to in his book “The Five Dysfunctions of a Team” when he talks about accountability.

Overcoming the avoidance of accountability is not about being ready to place blame for failures. Holding people accountable is not about answering “Whose fault is it?”

In fact, a culture of blame undermines trust, eroding the very foundation on which the rest of Patrick Lencioni’s pyramid is built. The first step to building a culture that supports and embraces accountability is to create an environment of trust, in which people can feel safe to share their weaknesses and their mistakes.

In a trusting environment, conflict can be positive and productive, resulting in the kind of shared clarity that allows people to commit to actions and behaviors even if they may disagree. And it is that commitment that makes true accountability possible.

True accountability, then, is not blame for results. Rather, it is expecting each member to honor the commitments they have made for their actions and behaviors.

If you’d like to foster true accountability in your team, without the threat of figurative choking or chopping, visit https://stevedwire.com/talk for a complimentary conversation.