What does a development manager do anyway?

Hello folks, 

Today I would like to cover the role and responsibilities of the person assigned to manage a software development team. The development manager, software development manager, engineering manager, development director are some typical titles. From now on, I will only use the term development manager, and they manage the team responsible for delivering software. 

In this article, I will cover the core responsibilities of the development manager. I define these as things that the development manager must do to ensure the delivery of quality software that provides the highest value. I need to emphasise the part highest business value of this sentence. Every day we are not spending on delivering business value is a day wasted. That business is falling behind its competitors or unable to provide increased service to its customers. Either way, this spells trouble for the company and the people developing its software.

Primary responsibilities of a development manager? 

I like to think of the development manager as being similar to a sports team coach/manager. As a rule, they both need to ensure their teams are playing well and delivering results. They both cannot (or shouldn't) play the game for the team; they need to rely on their players. As a result, they are only as good as the members of their team. They need to guide and mentor their team, imbuing the team with their experience and expertise to avoid pitfalls on their journey. 

At a high level, the development manager needs to:

• Understand the objectives of the team. 
• Diagnose the health of the system.
• Have the right people performing the right roles.
• Know the key stakeholders.
• Understand what they want and when they want it.
• Ensure the team is delivering on what they committed to do.
• Manage the team daily.

Of course, there is more detail hidden in each of these areas, which we will dig into more as we move through the article, so let's get stuck into the detail.

Understand the objectives of the team

It is critical for the development manager to fully understand their teams' goals so they can ensure they have the right people, structure, and processes for the job. The structure of the team needs to align with the team's objectives. For instance, a team established to develop a new banking system will be very different than one formed to maintain the in-house timesheet system. 

Understanding the objectives of the team will inform many different factors, including:

• Size;
• Structure;
• Members skillsets;
• Processes and methodologies they follow

Back to our earlier example, the team is developing the new banking system. It would need architects (solution and technical), technical leads, specialised front and back end developers, an army of business analysts (BAs), and a testing team more substantial than the average size football team.  While a team is maintaining the company's timesheet system, it would only require a small group containing a BA, a couple of developers, and probably a single tester. The differences in these teams come down to the requirements (functional / non-functional) they need to fulfil.

Diagnose the health of the system

As a development manager, I like to understand the system's health early on so I can plan out any remediation work before I commit to feature releases. Once you know all the problems, you can allocate time to fix them in your future sprints. Sometimes you may find the issue is so bad that you may need to recommend starting again from scratch. A rewrite will affect your ability to deliver features. Reinforcing why it is essential to understand any issues and flag these to your key stakeholders before committing to a feature release schedule.

Ways to diagnose system health include:

• Analysis of the source code of the system: You need to check for well-structured and documented code. It is also essential to ensure the various 3rd party DLL's the code uses are up to date with their latest patching levels (necessary for the security of your code). There are many source code analysis tools available to assist here.
• Discussions with the development team: Who better to ask them the people that know where the Skeletons are hidden.? They will be able to discuss any technical debt that they have not been able to address. They will also be able to discuss any problems with their development/build process that will affect the team's development velocity. Velocity defined as the speed your team can develop the software. You are looking for ways to improve this.
• Reviewing the defect or issue backlog: This will often indicate underlying issues if there are high numbers of defects for the system. Typically for most healthy systems, the development team should keep the number of bugs to a minimum. 
• Reviewing documentation: Is the documentation complete and up to date? Do we have any gaps? 
• Interviews with key stakeholders: This will provide great insight into the health of the system. They will be able to give warts and all account of the system. 

Have the right people performing the right roles

For this article, we will cover the team and methodology required for a small squad maintaining an in-house system in reasonable shape. Now we have a clear understanding of the team's objectives and the state of the existing system; we can start to plan out the team and the processes we need to get the job done.

Roles vs. People.
It is important to note that there is not a one to one mapping for roles to people. In small teams, people may carry out multiple functions. A good example here would be a test lead who also doubles as the release manager. In bigger squad's, there may be numerous people performing the same role, e.g. a team with many developers or business analysts. In a perfect world, everyone would get to wear just one hat. However, we don't live in an ideal world, and it is ok for people to have multiple roles as long as we balance out this in our expectations for our delivery schedule.

Development team roles
So my take on the roles required for a small development team is below. The list is not exhaustive; however, it provides enough expertise to deliver quality software. 

• Development lead: Provides technical leadership and guidance, assigns tasks to developers, and monitors code quality. They also work closely with the development manager and business analysts around scope and estimation. Works closely with Quality lead around ensuring software quality. 
• Developer: Works to deliver code changes and works closely with the development lead around work items, code reviews. In a small team, the development lead and the developer roles could be the same person. 
• Business Analyst: Works with key stakeholders to understand business requirements and business value. Works to deliver these requirements to the development team in the form of user stories. In a small team, the business analyst will help run the sprint planning, retros, and showcase rituals. In larger teams, a product manager, scrum master or lead business analyst. 
• Quality lead: The quality lead is responsible not only for measuring and reporting the system's quality but also for setting the framework and processes to support the development of quality software. In small teams, the quality lead may even sit in the tester role. The quality lead works closely with the entire development team and especially the development manager, to ensure there is a firm bead on code health.
• Tester: The tester, as the name suggests, works to validate the software that is under development. The tester works with the entire team to ensure they understand the software being developed and effectively test it.
• Release manager: The release manager is responsible for ensuring that all the I's are dotted and the T's crossed for each release. The release manager will work with the development, quality lead and the business analyst to agree on the functionality that is ready for release. Ensuring it has been thoroughly tested, the documentation is up to date. They will also plan out the release and ensure the end-user communications piece is ready and executed. The release manager role can sometimes be held by the quality lead or the business analyst roles if the budget does not permit a separate role.

Processes
One fundamental responsibility for the development manager is to ensure the team uses an appropriate development methodology. This article won't spend a lot of time talking about methodologies. However, I wanted to make the point that it is essential to ensure a formal methodology defined for the team, and they follow it. Typically the software industry is moving more towards the agile space these days. However, a small team can start with a simple waterfall methodology if they do not have experience in following any formal development methods.

Tools and tooling
It is critically important that, like any professional, your development team has the right tools. In our case, this means PC' s/Laptop's at least two 22inch monitors and a decent keyboard/mouse. An ergonomic chair and a quiet workspace are also advantageous. As the team's manager, it is up to you to ensure your team has everything they need for their job.

So what is this tooling thing, you ask? In this case, tooling refers to the software tools used to build, compile, deploy, and manage the software development process. Depending on the choice of software, the language will mostly select compilers/code editors and building pipeline tools. There are a couple of essential pieces of software the development manager needs to ensure is being used. 

Issue tracking/development management
This software tracks your development work items, bugs, and can handle your release planning. Examples of this software include JIRA, Azure Dev Ops. These software tools enable you to implement specific methodologies, define user stories/test cases, and much more. Without this tool, your development management becomes very difficult. 

Documentation repository
The other important piece that a development manager needs to ensure is in place is some software to manage your document repository. Examples of these tools include Confluence and Sharepoint. Creating, maintaining, and sharing documentation is a crucial part of developing software. Software development creates reams of documentation that needs appropriate review, filing and classification.

Pre-existing teams
If you have a pre-existing team, you will need to analyse their strengths and opportunities for development to understand better where they fit into your ideal structure. It is critically important that the existing teams be reviewed and assessed early on. You will need to make changes quickly if you find behavioural or capability issues. 

Know the key stakeholders

Teams that develop software will have many different stakeholders who will want to guide and shape the software's direction, these include:

• Financial stakeholders: The people who pay the bills but may not use the software your developing. An excellent example of these folks is the finance manager for your department. 
• Key users: These folks are the people that will be using your system and will provide details on what functionality they require. 
• Support personnel: Will typically want to understand how to deploy and support your application. They will need to know how to troubleshoot common issues and will have a lot of contact with your key users as the first point of contact when problems occur.
• IT / Cybersecurity: IT Cyber/Security folks are employed to ensure the companies applications are secure. They will be keen to ensure your application follows proper AppSec practises. 

Depending on the organisation, there may be different stakeholders present. It is the role of the development manager to know who are the key stakeholders, develop good working relations with these folks, and understand their needs and drivers. 

Understand what they want and when they can have it

Teams that develop software need input from their users around what to develop; this goes without saying. Development managers don't typically get too involved with requirements gathering, as this is something that the business analysts would usually handle. However, the development manager needs clarity the delivery pipeline. 

Why is this important?   Having visibility on the delivery pipeline allows, the development manager to validate whether the requirements are realistic or whether there are other alternatives to consider. It also allows the development manager to get a good feeling for the progress of the development work, whether it is on track or running behind, enabling the forecast of completion and release dates. These forecasts are, based on team progress and other commitments made during the development cycle. It is ineffective for development managers to commit to delivery dates without having the buy-in from the team. 

Ensure the team is delivering on what they committed to do

Development managers need to ensure that the team is delivering on what they have committed to during the project. In bigger teams, there will be several project/delivery managers working to create and refine the project schedule. It is the job of the development manager to ensure the overall delivery of the team's delivery schedule. You will have help, however, if the team self regulates by the use of various agile techniques. These include sprint planning (commitments to delivery and review of past sprint delivery), retro's (what went well and not so well), and the showcase (showing off the teams achievements). 

Manage the team daily.

The last job of a development manager is the day to day management of the team---HR-related stuff around leave approvals, hiring, firing, etc. The development manager will also be distributing communications from the broader company and keeping their team informed of things that they need to know. 

Finally, a good development manager will also hold regular one on one meeting with their team members. These ensure they are tracking ok and provide an opportunity for them to raise any questions or concerns in a regular forum. These are a great tool to manage status and feedback discussions.

Conclusion I hope I have provided a good introduction to the role and responsibility of a development manager. Its a many varied role and can be different from company to company or indeed vary from team to team in the same company. 

Thanks for reading!