Company Leadership: Refactoring a Software Development Department

This essay addresses what is required to “fix” a failing software development department. There are two major failure points in a software department: the people and the processes. Either or both can have problems that directly affect the success of product delivery and quality, and team cohesiveness. Warning signs include:

• Missed dates.
• Abundant bug counts.
• Employee turnover.
• Employees shorting hours.
• Low moral.

To overcome the obstacles, management has to first identify the specific problems. The identification process is much like debugging an application. It’s important to remember that the root problem(s) may not be visible in the identified problem set. But the relationships will be there. It is management’s responsibility to discover the problems and fix them. If you are an engineer working for a manager that will not address the issues; you can either try and fix the problem or find a new job. My recommendation is that if you don’t have any power and can’t get any power...then leave. I have tried to fix problems without the support of the management team and got nothing but frustration and stress for my efforts. NOTHING is worth your health.

As the manager you must also consider the possibility that YOU are the problem. You must lead. Not manage. Even if your title contains “Manager”, it doesn’t make you the leader. You can not build a team unless you have their trust and respect. To accomplish this you must lead them. You must make sure that you talk to them, address their concerns, and shield them from the crap that is rolling downhill...on you.

Assuming that you are a proactive manager and you’ve identified the root problems. You have to play out different scenarios before attempting to implement a fix. Every action has a reaction. So even if you have identified that one person is a disruptive influence, firing that person may not be the best solution. You have to take into consideration the contributions the individual is making to the team and the project as well as the group dynamics. If the disruptive individual is considered a leader then it may be in your best interest to turn that person into an ally. If you handle the situation carefully you can transfer the other's leadership position to yourself. Remember, you can NEVER take leadership. It is earned.

If you have serious problems you should fix any glaring process problems first, deal with the people next and then finally finish up the smaller process problems. Engineering folks tend to have very high intelligence so don’t try to bullshit them. There is a good chance they are way smarter than you when it comes to understanding systems and processes, it’s what they’ve been trained for. By focusing first on the processes that are getting in their way you have taken action that will let them know that you are there to support them. This will help you start to win their trust. Most engineers are happy building and creating. They don’t like office politics and they don’t like rules that don’t provide any value. Clear the way for their success, earn their trust, and they will deliver for you.