On Accountability

Accountability comes up a lot when talking about engineering organizations. Everyone wants to know how to hold engineers accountable. And, in my exploration of this topic with folks, I’ve found that the term accountability means something different to everyone. There are some folks who use accountability to mean an ability to explain. There’s a slightly larger set of people who use accountability when they really mean ownership. And then, there are a large number of organizations that use accountability to mean a mechanism to blame and punish people when they “don’t perform”.

I’ll admit that talking about accountability is triggering for me. So often it comes with an implicit, forgone conclusion. Something is going wrong at my company, let me roll out some accountability measures to prove that X team is not doing their job. In effect, it’s an externalization mechanism that very conveniently directs a leader’s problems outward rather than inward, skipping over the person or people with the most influence on an outcome, the leaders.

I talk a lot about the importance of alignment and contextualizing problems in my management practice. The idea that communication is key, and building narratives around why a project is important for the company and why it should matter to my engineers. The idea is that you can avoid a whole host of problems just by having a story, a VMSO, or some narrative arc that aligns and motivates your team.

People initially gobble this up. I get a lot of head nods and “mmm hmms.” But rarely do I get out of these conversations without someone asking, “but how do you hold people accountable?” And, I kind of stumble here, because, often times what’s behind that question is an insinuation that people are operating with bad intent. But in the past 7 years of my experience, it has so rarely happened. Does it happen? Yes. And usually, having a chat with that person is enough to get them moving. Sometimes that chat is friendly. Sometimes that chat is a what we in the biz call a “difficult conversation.”

One of the uncomfortable truths about the vast majority of the work we do in tech is that it is rarely the case that people aren’t technically capable of doing the work. It is far more common that people disagree about what the work is and the parties involved have some constraint that prevents reconciliation, whether it be time, ability to repair misunderstandings, or desire to come to an agreement. Folks don’t get fired because they can’t do the job. They get fired because the people involved can’t get to an understanding of what the job is and, in the process of hashing it out, have torn their relationship to shreds.

Which brings me to a couple ideas, The first is that accountability is a capability, not a measure. It is a means and not an end. Having or creating accountability will not solve your team or organizational performance problems. It will give you the ability to understand your performance problems and how you address them is up to you.

The second is that if most of your conversations around your engineering team are about needing accountability because your engineering organization is underperforming, that is more of a reflection on the leadership than it is on the team. Maybe you are hiring the wrong people. Maybe the team doesn’t have the ability to do the work. But, most of the dysfunction I’ve seen comes from some flavor of lack of goal clarity. Whether that is failure to define the goal, rapidly changing the goal, having too many goals, or not having a strong story about why achieving the goal is important. Whatever the reasons end up being, there’s rarely a world in which you as a leader didn’t have a hand in creating the environment in which those problems have been able to persist. So whatever definition of accountability you’re using, the first place to apply it is to yourself and your leadership team.

Finally, if nothing in this post resonates with you, take a tip for Lara who says:

When you want to use the word “accountable”, try to use more descriptive words to say what you mean instead. (Is punished if something fails? Is rewarded when something succeeds? Develops the strategy for? Is the person responsible for reminding others about? Is the person you should ask all your topic-area questions to?)