Accountability

Reblogged from Captain by Rank.

Accountability: what is it? Why is it important, and what do you do when someone on your team isn't pulling their weight? This week, I talk about one of the hardest nuts to crack as a manager.

In the previous three posts, I've talked either directly or tangentially about accountability, and I've mentioned that there are techniques for handling team members who aren't being accountable. Now I want to go into detail about that.

I hold engineers accountable for three things:

Note that I'm just scratching the surface with all three of these. There's a lot more to them than what I've written out below. For example, "a reasonable amount of work" can have a lot of interpretations, some good, some very, very bad. But these are good starting points for this discussion. Feel free to use them, but you'll probably want to add more detail. (It's likely a future post will do just that ;) Update: Here is the promised post.)

Once you've decided what people are accountable for, make sure that everyone is aware of your list (conversely, make sure you're aware of what you're accountable for as well). Your accountability list needs to be clearly and publicly communicated to the team, preferably on your wiki or whatever internal documentation you use. It's super important that information like team member responsibilities not be hidden or implicit. Everyone deserves to know exactly how their performance at work is being evaluated, especially when it's felt that they're not performing as well as they should be.

Now that everyone is aware of how they're being evaluated, what do you do when they're missing the mark? You talk to them. And you do it as soon as is reasonable. Not always an easy or fun thing, especially given the context and especially for us introverts, but it's very important that the conversation happen and happen soon enough after the issue was observed that everyone has sufficient context. To be clear, you're going to have to make a judgement call here. Some things literally require you to deal with them in the moment. Are they being abusive to another team member? Deal with it now! You need to send a clear message to the team that such behavior is unacceptable. However, what if the issue is that their bug count is a bit higher than you'd like, or maybe their productivity isn't quite as good as it could be? Save it for your next one on one. You are holding regular one on one's yes? I sense another post coming on. ;)

OK, you're talking. Awesome! Great! But what does that actually look like? This was where things used to fall apart for me. Like Mr. Trump, I always went straight for the nuclear option. Fix this or you're fired. It was the only tool I had, and certainly if I had ever had a boss give me that feedback, I would have fixed the issue! ASAP! Here's the funny thing, though. It never, ever worked for me. In all the conversations I've had with team members who where having accountability issues, the ones where I threatened to fire them resulted in only minimal improvements. I thought, WTF? It didn't make any sense to me. Eventually I convinced myself that they just weren't that good, so firing them made the most sense. Over the years, I came to realize that with rare exception, the problem likely had more to do with how I was addressing the issue vs. the individual themselves. For most people, the threat of being fired is a little too abstract, in my experience. They need to better understand what the consequences of their actions are instead.

Enter Crucial Accountability: Tools for Resolving Violated Expectations, Broken Commitments, and Bad Behavior. I've already mentioned this book a couple times, and for good reason. It is hands-down one of the most useful books I've read for dealing with this type of situation. If you only take one book suggestion from me, let it be this one. Much like in Crucial Conversations, they supply a framework for having these kinds of conversations (once again, an engineer's love of frameworks rears its ugly head ;)). I'm going to touch on the high points of their framework so the rest of this post makes sense, but you should really read the book to get all of the detail.

The first thing they recommend is to not tell yourself stories as to why this person is having issues. It's very easy for us to come up with some reason as to why they're behaving the way they are - they're lazy, they don't want to do it because it is difficult, they're doing it to just spite you, etc. Nine times out of ten, though, it's usually for some other reason. So try to enter into the conversation understanding that your story is just that, a story, and that you've likely biased yourself. Talk to them and find out what's actually going on before making judgments.

To begin the conversation with them, describe the gap. The gap is the difference between where they're currently at and where you'd like them to be. For example, they aren't getting as many tasks done as they should in the time allotted. Or, other team members are feeling put off by their communication style and you'd like everyone to feel comfortable having conversations with them. Be prepared for this to be a potentially hard conversation. Again, read the book to help with that.

Once you've described the gap, you need to explain the consequences if the current situation doesn't improve. This was the bit that was the real game changer for me. Before, I always had the one consequence. Instead, I learned to see that everyone has different things that motivate them, and it's on me to understand what works for each team member, and use this to explain the negative outcome of their behavior in a way that resonated for them. It is likely that figuring this out will be an exploratory process, based on your experience with this person as well as what you can unearth during the conversation you're having with them. One example of framing consequences; you have an engineer who doesn't care too much if production feels that he's behind, but he cares very much that his being behind causes the artists to have to put in extra time to make up for the lack of features, so you use that as the talking point for illustrating why you want to see a change. The takeaway here is talk to your team members, observe them, and see if you can figure out what consequences are relevant to them.

Now that they understand the gap and the consequences, you need to come up with a plan to address the issue. It's very important that you make sure they are able to achieve the goals laid out, and if not give them and/or get them the help they need. This could be training, providing more detail on what their tasks actually are, etc. Finally, make sure you follow up regularly and give feedback accordingly. Don't scrimp on this bit. If they've improved, be enthusiastic. If not, work with them to find out why and repeat.

So the theory all sounds well and good, but how does it work in reality? A while back, before I read this book, I had a programmer on the team whose productivity was lagging. I went through my usual process and gave him the dire warning, "Improve your productivity or you're fired." Small improvement as per usual. :-/ Then I read this book, and spent some time observing this particular programmer and getting a better understanding of what mattered to them. It hit me - he really, really liked working with the designers. With that in mind, the important consequence to communicate to him was that because he completed tasks so slowly and the designers were dependent on his work, it was a hard sell to continue giving him the tasks he liked doing because the designers were getting frustrated at how long things took. Bam! Within two days it was a dramatic turn around. While the threat of being fired garnered a small improvement, understanding that getting to do less of the thing he really enjoyed made all the difference. Those of you still paying attention will note that getting fired would have come to the same thing. But that's just it, given the opportunity to improve with the understanding that he'd end up with more grunt work if he didn't made all the difference. Everyone's motivations are different. Check your stories at the door.

It is important to note that this framework works both directions. Having issues with your boss? I highly recommend reading this book and applying the techniques in the opposite direction. Speaking from personal experience, you might be surprised as to how effective it can be.

There you have it, one of the most useful tools you can have in your toolbox, in my opinion. Hopefully you'll find it equally useful. Until next time.

Agree or disagree with anything I’ve said? Questions? Other book suggestions? Let me know in the comments below or via Twitter, Facebook or email contact at captainbyrank dot com.

Cheers,
Shaun