How to manage difficult software developers?
/Software developers have a reputations for being “difficult”. But from my years of working with literally hundreds of developers I know that what is considered “difficult” is just a wrong way of looking at things. You can completely change the interaction and behavior of a “difficult” developer if you just adopt a few easy changes in your thinking and action. These “software people skills” are super easy and it’s really painful to see how many project managers or team leads don’t these. I’m going to do a series of software people skill going over them one by one. These are skills that are extremely easy to learn yet effective right away.
Instead of my usual of just listing them out, I’m going to make this series more hands on. I’m going to pickup pieces of conversation that are common between a manager and the “difficult” developer to show you the scenario and show you how you can completely change that conversation. You’ll notice that the manager will always be reasonable in his requests in the scenarios I talk about since I’m not talking about irrational or abusive interactions.
OK, to my skill #1
Software people skill #1: Always criticize code in private
Scene: Mr. Dev is in front of the his computer, Mr. Manager is standing next to him staring at the computer and speaking while pointing to the code. The last build of the product had some major bugs, most of the bugs on Mr. Dev’s area. Mr. Manger wants them fixed quickly so that they can meet the deadline (and also wants to air out his anger for the bugs hoping that the anger will make Mr. Dev create less bugs next time round). Other developers are within earshot.
Mr. Manager: Hey, there are way too many bugs in your part in this build. Can you please fix them asap so that we make the deadline?
Mr. Dev: You cannot blame it on me, I had way too many tasks, I told you they were impossible to finish and you are now seeing the result. So it’s your fault not mine and I’m not cleaning up your mess.
The mistake: Code is a developer’s craft. It is his creation, almost like his child and he will always identify with it. There is no way you can criticize his code and not get him emotionally affected and be defensive. And if you criticize in front of his peers and with his creation right in front of the conversation it is the worst you can make things for her. This will get you nowhere and will only make things worse down the line.
The solution: Know the sensitivity about criticizing a developer’s code. But that doesn’t mean you should not criticize or not take any action in the hope it will be sorted somehow. You just have to do it with some care.
Make sure you have the discussion in a private space away from the peers of the developers. Ideally your office or a meeting space with the door closed. The developer will appreciate your care about keeping it private and also feel the importance of the need to address the issue.
If the developer’s room is itself private, you should do the conversation away from his computer. This is purely from experience and a bit weird but there is definitely a psychological effect of receiving criticism right in front of the code that is being criticized.
You should use inclusive language like “we” “us” rather than direct “you”. This gives the developer some relief that he is not the only one involved - because in a lot of situation he feels (and he might be right) that he was not the cause for the failure. Inclusive language moves the interaction to a feeling of working together to fix the issue.
Softening the accusation a bit may help. This is case sensitive but the fact of live in software development is that people will make mistakes, there will always be some use case not thought out, some requirements will always be vague, etc. So once again if the language feels like you understand the complicated nature of a developer’s job, his reality of dealing with all kinds of unknowns and variables of a project, he will feel more understood and be less defensive.
