How to hold developers accountable

CTOs struggle with accountability

Part of my CTO Coaching

Without accountability, there is no functioning development organization., Without accountability, everything breaks down. Without developer accountability, there are more problems created all the time than the CTO can fix. But, CTOs and engineering managers struggle with holding developers accountable. Why and what can you do?

What is the difference between accountable and responsible? Responsible are to the individuals who complete a task, while accountable is the person who ensures the task is done - which in the case of developers might be the same person, although they are still two things not to be confused. Most prominent is this distinction with the RACI/RASCI framework, which makes it clear for each project and task who is responsible and who is accountable (highly recommended!).

Developer accountability centers mostly around two things:

code quality / bugs
commitments (deadlines)

Although there are more

Technical (Writing documentation, writing tests, writing secure code, doing code reviews)
Process & Communication (Knowledge sharing, timely communications, updating tickets)
Professional Growth (Learning, mentoring juniors)
Team Collaboration (Pull requests in time, following coding standards)
Business Impact (Thinking of customers)

we’ll focus on those two that seem to create most problems for CTOs I have talked to.

Sometimes people confuse “holding someone accountable” with forcing things on people. “I make you accountable for …” is a sign of this culture. You can’t hold people accountable for things they or their team did not commit to. Holding people accountable has to mean holding people accountable for their commitment. For their time commitments (not arbitrary deadlines) and their quality commitments (not arbitrary metrics). Accountability in this sense has a lot to do with engineering culture. You commit to the engineering culture. And as a great CTO once said, “Engineering culture is binary, you’re either in or out.” You either act on your commitments or you don’t.

Some developers commit to things, or commit to a culture or commit to teams and then don’t deliver. There might be many reasons for this. They are too junior and committed to things they didn’t know out of juniorness. There are unforeseen events. They make mistakes. All of this is can happen. But then there are developers who commit to things and think delivering and finishing is optional. Repeatedly so.

Those are times to hold developers accountable.

You know all of this. Still, I needed to write this article, because I meet too many CTOs who have problems with repeatedly broken promises and broken commitments. They don’t hold developers accountable.

Why do CTOs not hold developers accountable? The reasons are

engineering managers are often introverts and have trouble talking to and directing people
they believe people see the light by themselves when they explain things
they don’t want to micromanage or don’t want to look like a micromanager
there is no culture of positive conflict
engineering managers want to look nice
they don’t want to be the pointy haired boss (PGH) (you’re not!)
engineering is about presenting the better facts - with the assumption the other accepts better facts. When they don’t, engineering manager run out of tools

First, I’ll want to get this out of the way: You can be nice and still hold people accountable. People will respect you more when you hold them and others accountable. Team morale breaks down when individuals repeatedly don’t feel accountable for their commitments. What can you do?

Lets start.

Accountability needs to be part of your engineering culture. This is where accountability flows from. You need to be accountable, you need to be a role model for accountability.

Always try to make teams instead of individuals accountable (But remember, accountability is a soap bubble, you micro manage and it pops). Holding a team accountable is Champions League Final Round (World series baseball). You and the team need to be on that level to achieve this. Holding individuals accountable is Premium League. So you might need to start with making a lead accountable (see above, “on their commitments”) before the team can be accountable and responsible. Too many CTOs I meet want to start with making a team accountable and responsible and fail.

Second, give regular feedback, do not deviate for longer periods of time. If a developer misses tasks or commitments, work on it ASAP.

Don’t skip dailies (!). This is key for team accountability. With remote many CTOs skip dailies. Don’t. Ideally, the team holds members accountable for commitments, for tasks that no one touched for two days. If the team isn’t yet there, the ScrumMaster, team lead, or you need to hold people accountable in a daily. Start by asking “Anything left?"—if no one points out the tasks no one touched for two days, say “What about X?"—don’t let the team out until someone feels responsible.

To make commitment stick, show the impact of their failed commitments. It’s easy to throw the hands in the air, it’s more difficult to shrug everything of if you see the consequences of your failed commitments and failed deadlines. Especially in waterfally organizations, people tend to just see their own unit of work, moving tickets from left to right. You’re the storyteller giving the whole context.

Don’t give conflicting messages and goals. We often want two or more things at once. Your boss and your peers might want different, conflicting things. Then you want things on top. As an engineering manager, it’s your job to clear up these conflicting goals. It’s not the job of the team or developer to solve these conflicting goals and then your job to hold them accountable for not reaching conflicting goals. This is not how it works.

For example, make holding deadlines and deliveries more important than throughput. You can’t have both. If you maximize throughput and have short deadlines, people will miss their deadlines, not deliver the things they committed themselves to. You need to decide what you want: Accountability or throughput. If you want accountability to commitments, deadlines need to have slack. Measure every sprint (“mini-deadline”) against commitments. Get to your goal, say 90% of sprints successfully finished. Put the current number on a big screen or put it into your video feed (Use OBS to put text and numbers into your webcam during meetings). If needed, it’s better to have 13 points delivered with >90% probability, than 18 with 30%. When they hit 90% of commitments, ask them if they could deliver more, repeat until they fall below 90%. If you favor throughput over predictability, don’t hacke developers over missed sprint throughput.

The same goes for throughput, time commitments, and code quality. From these conflicting goals, as a professional, I set code quality (not golde plating) as given, and expect everyone to act professionally. Just as accountants do not deviate from accounting standards, developers can’t deviate from development standards, e.g. skipping tests. You need to make clear that there is no conflict and where priorities are. Developers might give in to pressure from others, support them (“Send X to me.”). But also hold them accountable for their quality commitments.

Some more “tricks”:

Use the “echo technique”: Make your expectations clear then have developers repeat back their understanding of your expectations (people can’t meet your expectations when you haven’t talked about them and can’t meet your expectations when they haven’t understood them)
Create accountability buddies within the team - this might help especially junior developers or people new in their role
Set intermediate milestones and smaller deliveries for longer projects. Having full features and four-week sprints is great for developer productivity, but again, is Champions League final round level. Start with weekly sprints, and if everything is fine, increase to two, three or four weeks.

What to do if all of that doesn’t work with some developers? Have A-Mode and B-Mode. Like with this Game&Watch games from Nintendo, I grew up with (Greenhouse still the best). There was this “A” game-mode, which wasn’t too hard. And a “B” mode, which was hard core. You can be A-mode most of the time. When a developer doesn’t want to be accountable for their actions, switch to B-Mode.

Mode-A(90%)

What is Mode-A? Tell, explain, create an environment for motivated people, set clear expectations, keep checking in if needed (depending on developer/lead level), align, tell a story, clear language (“I expect you, … / my expectation …”), no ambiguous language. If things go wrong, developers might not fail commitments, they might just have misunderstood (or you have set conflicting goals again!) Developers, like everyone else, hear what they want. Everyone hears in meetings what they are open to hear and want to hear. Two people agreeing and leaving a meeting, asked about what they agreed upon will give two stories. Often these contradict each other! (write things down after meetings! when people read the “decisions” it’s harder to misunderstand or only hear what you want, or misinterpret things). Don’t blame people, especially not because you haven’t been clear on things. Mode-A is about supporting developers, explaining things, setting clear goals and boundaries.

Mode-B (10%)

If A-Mode does not work, as a developer doesn’t deliver on their commitments, switch to Mode-B. Set clear deadlines, reestablish expectations, don’t let it slip, clear language “I want you to do X until Y”, that doesn’t leave room for interpretations, don’t explain, don’t motivate, don’t align and be short. No sandwich technique someone has taught you. No long talks and sugar-coating, developers will hear what they want. If you don’t say so much, they can only hear what they need to hear. Endure silence! If you talk a lot and make many minor points, they might hear the wrong things. If you sugar-coat, they might think they don’t need to change. Write everything down. Create a paper trail when in Mode-B. Always have a next action and next check-in date in B-Mode. The developer can’t leave and say “the meeting is over, back to normal”.

With clear communications, clear expectations and not letting things slip (your mistake!), you can probably stay in Mode-A most of the time if not forever. If it does not work for some individual, switch to Mode-B before things are beyond repair. This way holding developers accountable should no longer be a problem.