The Role of Management in Software Development

Over the past 13 years I've worked as a software developer, team leader, and manager at seven different organizations. Each was different in size, industry, and organizational structure. I'd like to think that at each job I've learned from what they did well, and possibly even more so from what was done poorly. While software development is not a new profession, compared to that of others it's still in it's infancy. While there are many different areas that one could focus on, I think one of the more interesting (to me at least) is what the role of a manager in the software field should be.

Let me start off by setting a few things straight. In some organizations, especially ones in smaller companies, a manager may be involved in software development. However, I don't consider that person to be a true manager. The more appropriate term might be lead developer. If a manager is involved in software development, but that is not the focus of his or her role, then one has to question why they are developing software. Simply put, there's too much new technology to learn to be able to be a great software developer when that's not the focus of the job. Alternatively if focus of that individual's role is in fact software development, then I don't think that person is a true manager. Again, the title of team lead, or lead developer, would seem to be more appropriate.

With the above clarification in mind, I'd like to point out what I consider to be the key objectives that a manager of software development should focus on. This post assumes that the team is already producing quality solutions, using established methodologies, and in general doesn't haven't anything majorly wrong with it. (I consider that to be the "easy" part of creating a software team, and there's already a lot of published information on how to make that possible.)

• Communicate the value of the group to the rest of the organization. Unfortunately I've been in some environments where the team does great work, but the business simply does not understand the value that the team brings to the company. All they see is a group with highly paid employees, and have the goal of reducing the size of the group to save money. The reality is that none of us should expect nontechnical people to understand what a software development group does. It's the managers role to ensure that the upper management understands the value that is being provided. There are many possible techniques to use here, from showcasing software, to reporting metrics on increased efficiencies gained. Really the important thing is finding out what will work in the organization, and making sure that the message is delivered. In my view this is perhaps the most important part of managing a team. By properly communicating the team's value, the organization will be more willing to invest back into the team.
• Establish a vision. What is it that you want the team to do? Hopefully it's more then just maintaining some old software systems written in COBOL. Define a vision, possibly using a road map as a simple tool to communicate this out. The team should be able to best self determine their day to day work. However, they often won't know what the goal is for the next month or the next quarter. Of course this should be something flexible that will often change over time, but it's good for the team to know where you are headed and why. It certainly helps the team, and knowing the "why" also helps with team motivation.
• Encourage learning. No matter where you work, there will almost always be something that someone considers urgent and wants its as soon as possible. Of course everyone wants to produce quality work and deliver things on time. However, unless you want your team to be quickly behind the times, you need to provide the team time to learn newer technologies and also explore new ideas. Technical debt is a subject worth of it's own blog posting (or perhaps a it's own book) but the value of keeping your employees up to date should be obvious. Equally as important is that you want people to stay motivated and look forward to their day of work. Some of the best ideas don't come from the top down. Allowing your employees to be creative will often net unexpected results.
• Help foster an environment that focuses on collaboration, teamwork, and communication. This should almost go without saying, but unfortunately I've been in organizations where they consider these things to be a waste of time. I can just see those managers thinking "We don't have time for all this talking; we need to get things done!" Of course it's rather important that everyone on the team knows what's going on. While days of heads down coding may make managers feel better that work is being completed, at the end of the day a lot of time can be lost when not everyone has the same vision or goal for a project. Something as simple as basic UI inconsistencies can make a piece of software look unprofessional. Even worse, if each individual engineers' pieces that don't fit together properly you end up with buggy or non-working software. Believe me, I've seen this happen many times and the time saved by not communicating is lost in trying to fix all of the problems with the software.
• Focus on quality. Again, this should be another no-brainer. However, too many times I've seen some predetermined date on a calendar dictate when something needed to get done. (Of course if you're using proper software development methodologies it will definitely help mitigate those types of issues.) Management often will cave in to these pressures, and throw quality out the window to meet these predetermined dates. As was mentioned in my previous point, this is never a good idea. Simply put sometimes the manager of the software team needs to grow a backbone and push back on the business. Offer to cut features, ask for more time, or as a last resort even ask for additional resources. For some reason people tend to think software is a magical thing that can get done quicker, if the team only tried harder. But those same people would understand if they asked you to build them a bridge and you told them that in the time allowed you could only build them an unsafe bridge that was liable to collapse at any moment. Perhaps using that analogy might help your case.By all means don't give in to those pressures.

With that all said and done, it doesn't sound like that much for a manager to do on a day to day basis. You'll noticed I've left out anything about telling people how to do their job. A good team can sort that out on their own. (If not, you've assembled the wrong team.) The important thing is that a manager isn't just another worker bee that wears a tie or someone that cracks a whip. Unfortunately in my experience the role of a manager if often not properly handled. (I've had some great bosses too.)  At the end of the day I was much happier, productive, and produced better work when I had a good manager. Let your employees do the work; after all that's what you've hired them for. Trust their judgement, rely on their technical expertise, and create an environment for them to grow and thrive in.