Wondering how to be a good dev manager? If you’re not running interruption interference, you need a new game plan.
I’ve said for a long time that developers should only be managed by other developers. You should not bring in a “professional manager” (is there such a thing?) to manage your development team. I get a lot of pushback on this statement but each and every time I’ve seen this play out – without exception – it has ended up being a bad work environment for the developers.
The reason is simple. Only another developer can understand how software development works enough to have empathy for developers.
“If you have never been a developer, you have no business managing developers.”
– Cal Evans
Understanding is part of the key
Software development is challenging even when things are going well. Most of the time developers have to hold two or three threads of thought in their head simultaneously. They have to be able to work on one piece of code while understanding how it will interact with other pieces of code. Some of us call this “getting in the zone” because it takes a while to get there. Once a developer is in the zone, they can begin to flesh out the code that will bring the ideas of their stakeholders to life.
Walking by and asking how their day is going, asking them a “quick question about the system” or asking them anything at all will destroy “the zone” as quickly as a pin will burst a balloon. At this point, all the time spent getting into the zone was wasted and the developer has to do it all again…after answering the question.
Non-developers don’t get this. Some will pretend to, and a few honestly believe that they do, but unless you’ve been “in the zone”, no, you really don’t understand. Managers who have been developers do understand because they have been there.
Empathy is part of the the key
Once you have understanding, you can have empathy. Once you know that it takes a developer a while to get in the zone, then you can empathize with them when someone drops them out of it for “Did you see the sports-ball game last night?”
Once you have empathy then you understand the other thing I say a lot:
“A manager’s #1 job is to be a poop-shield for their team.”
As a developer manager, it’s your job to protect your developers from outside interruptions:
- Phone calls
- Drive by meetings
It’s not that other people hate developers and want to keep them from getting their job done. Just like non-developer managers, they just don’t understand. It’s your job to help them understand.
Honestly, this part was a lot easier when we were all in the same office. As a manager you could sequester your team, and protect them. Now that many developers work remotely, you have to learn new tactics. Things like you have to empower your developers to shut down slack, close their email client, and shut down social media. They have to know that you’ve got their back if they go dark for a few hours”. These days giving your developers the power to decide when they don’t want to be disturbed is how you protect them.
This is not the fun “bossing people around” job a lot of people think of when they think about management, but it is the truth. You have to take the hit, answer the questions, attend the random meetings, and do everything you can to keep your developer’s focused and in the zone.
If you show your team you care for them by keeping them safe from interruptions, they will understand that you care about them. People don’t leave jobs, they leave bosses. Specifically they leave bosses that don’t care. Show them you care and you’ll see your turnover drop, and your developer productivity increase. Both of those metrics reflect well on you and your team.