The Written Roles of Software Development Manager [closed]

Question

We all know what a software development manager does, but I'm afraid that we only know it vaguely. We think we know what he is doing, but to exactly list down what is the job scope is a bit hard.

In your opinion, what are the roles of a software development manager?

Answer 1

Speaking as someone in the job (who has also been a developer), the key things I have to do are:

• Keep the development team on track (and happy where possible) - move things out of their way that are stopping them work where possible, explain why it's not possible where they can't be moved to try and reduce any resulting stress (people are more likely to accept things if they at least understand them). Ultimately if there is a conflict between the project and the team that can't be resolved, normally the project will win. That's doesn't necessarily make you popular with the team but you're paid to deliver projects/products, not as a union leader. The obvious skill is in minimising how often this happens.

• Make sure that the team are communicating with the customer the right amount. This tends to be equal parts keeping the customer away from the team, and making sure the team are asking the customer about things they don't understand fully (rather than just making assumptions which may be incorrect). Developers are very big on making sure that the customer doesn't disturb them and occasionally forget that the customer might have something useful to add.

• Project planning and prioritisation of resource conflicts, customer demands, support issues and the like. I tend to be the person who says this customer takes priority over that one, or that this bug has to be fixed before it ships but that one can go out as a known issue.

• Manage the commercial side of development - that is making sure that things that should be charged for and being charged for and that we're not trying to charge for things which should be covered under support.

• Be the voice of the team in the business and the business within the team - help everyone understand the other's position and help resolve differences where they arise. This largely tends to cover cultural conflicts between the teams needs/wants and the larger organisations, and budget matters. This is actually pretty shitty as it means when there are disagreements you're everyone's enemy.

• Work with the team to ensure sufficient processes and tools are in place to meet the requirements of the business and customers. Make sure that these processes are being followed and adjusted as needed. Some of this is making sure the team define processes (for instance for technical things they understand better than I do), some is defining them myself (for things I understand better than they do - planning, estimating and so on). The important word here is sufficient - you don't want process for process sake but there are things that have to happen and process is the best way to achieve that consistently.

• Ensure that every member of the team is working to at least a reasonable level, and ideally beyond that. Work with them to help resolve any issues that are preventing them reaching this level. I'd love to say that my role is making them be the best they can be but while this is true to a degree other demands (project, budget, time) mean that this will almost always be compromised to a greater or lesser extent.

• Doing all the administration and stuff the organisation (and the law) demand

Overall it's part mentoring, part secretarial, part project management, part account management and part PR (for the team). There's a lot of picking up things the developers don't need to think about or don't think about doing, and some making sure they do things they need to do but don't want to do.

What it's not about is being the best developer (generally you're too hands off to remain current for long so you need to accept that people will know more than you - the skill is in knowing where your longer but outdated experience is more relevant than their shorter but more recent experience) or being some sort of dictator. In that respect the best way to think about it is not that you're more senior, just that you have different responsibilities. Sometimes this will involve making the final call on something (which may go against the views of the team) but more often it should be about consensus or compromise.