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?

  • 1
    Excellent summary to remind one about what an engineering manager does. Put it on your desktop and revisit it when you are having doubts, or are in a tough situation while managing your team.
    – jkk
    Commented Jan 30, 2014 at 4:31

1 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.

  • 3
    A late +1 for a great answer I found useful. Commented Mar 8, 2011 at 10:39
  • 3
    This has been added to my list of "To Read" with the note "over and over again." Wise words. Commented Feb 22, 2013 at 17:25
  • 1
    I'd like to talk a bit about something you've said, namely: "in general you're too hands off to remain current for long". I have a slightly different idea of what a development manager is all about, but in this regard I think that a dev manager should at the very least be aware of what the latest-and-greatest is and understand it at a high level. I'm the first to admit that drinking from the firehose without spilling a drop is infeasable but the fact is, there are very few new concepts that hit us on a day-to-day basis.
    – Eric Smith
    Commented Jun 5, 2014 at 8:55

Not the answer you're looking for? Browse other questions tagged or ask your own question.