The role of a Development Manager can be a very stressful one. You are the "man in the middle'', being pulled in different directions by management, customers, sales, developers etc.. If you are doing your job well nobody notices: things work fluently, the work gets done without drama and everyone gets what they want. If things go wrong, no matter what the cause, then it is your fault.
The secret to being successful as a Development Manager is managing expectations and making sure everyone understands your role is the first step. Both you, and the people you work, with need to agree on what is expected of you as a Development Manager.
I have seen job postings for Development Managers that leave me shaking my head. One required in depth knowledge of a large number of a programming languages and environments, in another the position was 66% (why not 2/3rds?) programming, still others required PMO certification and this list could go on. While I agree the role of the Development Manager is sort of nebulous, job postings like these give me the feeling that the companies posting the jobs really have not thought about the role. This is a recipe for disaster for both the company and anyone hired under these conditions.
As Development Manager you have a number of responsibilities, but the primary one is to get a product out the door. Your goal is deliver results to the customer, or market, and do everything necessary to achieve this. To do this you need to make sure the development team is able to work as efficiently as possible and this means making sure they have clear goals, both short term and long term, and that nothing prevents them from doing their work. From the initial project scope to deploying the product out to customer sites, each step is your responsibility. You can, and should, delegate as much as you can but be ready to check that things are being done as you want and be ready to jump in if it is not.
Project Scoping
As Development Manager you need to know how to scope out a project. Depending on your organization and how you work with outside groups this could be a major part of your work. If you regularly take on projects on behalf of 3rd parties, then you should know how to respond to an RFP (Request For Proposal), complete with Deliverables, Time Lines, Budget etc.. Even if you only deal with internal projects, without a formal document system, you should get in the habit of putting together a Project Scope Document for every project. Also, if you are practicing Agile development, these documents need to be living things and maintained and updated as the project progresses.
Over Head Projects
This is part of Project Scoping, but it deserves a separate paragraph. I’ve heard people talk about “Over Head” projects that don’t need a budget and time line. This is so wrong! A failure to work out what the cost and deliverables are on these “Over Head” projects can stifle your team as they eat into your schedule and divert resources away from other work. Every project you undertake has at least an internal cost and at least one deliverable. You need to be able to negotiate both with the other stake holders for everything you undertake.
Managing Relationships
Remember, you are the ''man in the middle'' and any failures are going to belong to you, even if the cause is something beyond your control. You need to keep good and open relationships with the people involved.
Get to know not just your immediate boss, but who he reports to and the people who are on the same level. You also need to get to know other stake holders on the projects you manage. Make sure they are ''in the Loop'' and get regular status updates and have good visibility on what your team is doing.
Who handles customer relations? Besides your boss, this is probably the most important person you need to get to know. They can manage customer expectations, handle complaints (real or imagined) and provide critical customer contacts. On the other hand they can make your life miserable, making promises to customers without checking with you, posting bug reports that are unnecessary, pestering you to deliver on unrealistic time lines etc.
Get to know you team, how long have they been with the company, what are the individual strengths and weaknesses? Who works well with whom? How busy are they? Keep track of little things like birthdays, anniversaries, etc.. Just acknowledging these little things make for sense of community.
Making sure that management knows what you are working on and can see your progress is critical to keeping them happy. Communication and visibility are key getting this to work. I have used all sorts of tools to keep management in the loop and discover more all the time. Keep a tool box of programs, bulletin boards, white boards and anything else you can think of and keep them up-to-date.
If the stakeholders understand the challenges you and your team are experiencing then they are less likely have unreal expectation. I say less likely, but not never. Some management will never understand why things don’t just ''work''. In these cases it may be time to start looking for another job.
Project Planning
Unless you are working on a large project, you generally don’t need a separate role for a Project Manager. For small or medium sized project and using Agile methodology then you can take the role and responsibilities. However, one thing a Development Manager is not is a Certified Project Manager. Putting aside the debate over traditional Project Management and Agile Development, there is an inherit conflict of interest in between the Development Manager and the Project Manager. As the Development Manager your job is to get everything done as soon as possible, the Project Manager’s job is to say what can be done and when. It is balancing these two views that you have to be aware of. If your project is large enough that it needs the skills of an experienced Project Manager or Scrum Master, then you need a Project Manager or Scrum Master on your team, don't try to take this role yourself. However, one thing you should do, Waterfall or Agile process, is make sure that your project plan is a living document, continuously updated and keep tracking progress.
Process control
This is another critical part of the job. Whether if you are using Agile or Waterfall methodologies, you need to keep on top of your process and keep things on track. Remember you are paid to deliver and anything that affects this needs to be your top priority.
What is your development process? How formal is it? If people call it an “Agile” process check to see if it is really Agile (I like to keep a poster of the Agile Manifesto handy as a reminder to following it’s principles). How can your process be improved? No system is perfect, keep looking a ways to improve the process. A lot is made about Root Cause Analysis when you run into bad bugs, but more often it is a flaw in your process that allowed a bad design, poor code or a miss understanding of the customer requirements to go out the door in a product.
Delegation is good, but you have to follow up and make sure things get done. Great ideas often fail in execution because no one checks to see if things get done properly. I have taken over projects that had all the right pieces in place, but the execution was poorly done and things were falling apart.
Finally, you need to report the project status to various stake holders and these reports need to be based on some firm metrics. So have some way of measuring progress and summarizing it in a way that is meaningful to the people you are reporting to. Depending on your organization these reports could be daily, weekly or on an as needed bases. Be sure you are clear on the frequency, format and contents of these reports. Be aware of the people reading the reports and the level of detail they are expecting and target your reports to that level. Above all make sure your reports are clear, precise and easy to read. This will decrease the number of people who misinterpret your reports, but not eliminate it. Be ready to clarify and explain your reports without sounding defensive, the people reading your reports have a lot to do and may only skim them and read into them what they will.
Technology
This is one area that I see over and over again in job postings. Some companies are looking for Development Managers with in depth knowledge in particular areas. As a Development Manager you are NOT a tech guru! Leave that up to your Sr. and Lead Developers. You should be comfortable with your current technologies and be aware of new and upcoming technologies, but don’t let yourself become the expert or this will be a drain on your time and divert your attention away from other tasks. You do need to know enough about the tools your team is using to know if they are using them efficiently, and know when there are gaps in your team’s knowledge, but you should not be the ''go-to'' person. As tempting as it is you have to let go and delegate this role to the senior people on your team.
Development
Again, this is one area that you should be comfortable with, but not an expert. Great programmers are best programming and usually make lousy managers. You need to be able to tell good code from bad, but here you should be able to trust your team leads. When crunch time comes you should be ready and able to dive in and take over some development tasks, but remember you a have to keep the big picture in mind and be focused on getting the project done. You can’t afford to spend days buried in programming and forget about the rest of your job.
Automated Testing
I separate Automated Testing from Quality Assurance as I see them as separate functions. Usually they are assigned to the QA team members, but I find it helps to think of them as separate functions. Automated testing includes Unit testing and test scripts where as Quality Assurance is manually looking at the system not just for bugs, but for things like consistent look and feel, performance, User Interface and design issues. (see:Testing vs Checking).
Automated testing is one of those things that seems like a waist of time 99% of the cases, but the last 1% is the exception that proves the rule. Remember the Jell-O code rule, squeeze a system in one spot and it breaks in another. I have seen cases where everyone was sure the code change had minimal impact, only to have a dozen automated tests fail. This was only noticed because 90% of the code was covered by automated tests and we were lucky the new bugs were not just in the remaining 10%.
As a Development Manager you need to know what your test code coverage is. How much of your code base is covered by unit testing? How much by Automated testing? Is this value increasing or decreasing? A good QA Lead will be able to give you these numbers, but you should have a system in place for at least estimating this value. Decreasing code coverage numbers are almost inevitable and you can tolerate this for a while, but there are times when you will have to slow development so that the QA team can catch up. Not paying attention to your testing code coverage can result in buggy code going out the door.
Quality Assurance
I have seen this called ''smoke testing'', but that is a poor substitute for a proper QA process. Inconsistency, deviation from specifications, decrease in performance etc. are all things that need to be caught by QA. It is your job as Development Manager to make sure these tests are done and you have to be proactive here. Keep the QA team in the development loop so they know what is coming down the pipe. I open separate QA tickets for every development ticket and make sure they are assigned the same time as the development ticket. Linking the code change this way provides the developer a way to make notes on testing in a separate location from the coding notes.
QA testing can fail for a number of reasons, bad tests, code changes, misunderstood specifications, and network and system errors. To get to the root cause of test failure you have to get the developers working with the QA team. This is not so difficult if your QA people are part of the development team, but if they have their own manager, then you have to coordinate with their manager.
Release Management
Depending on the complexity of your project, getting a release out the door can be a separate project all together. In a simple system this could be as easy as doing a build and coping over the executable, in a complex system this could require building a number of packages (executables, assemblies, Jar files or DLL’s), adding database scripts and even some third party applications. Making sure you have the right version of every component can be difficult and time consuming. In very complex project you might have a designated BuildMaster, to track the versions. In any case, you need a common area to document components, the version needed for the next release and make sure everyone has access and can update them as needed.
You also have to mark the release in the code archive, prepare and test installers, write and distribute release notes and make sure the right people have access to the new release (and make sure old releases are at least renamed so that they are not confused with the current release).
Deployment
Deploying a release is often seen as part of Release Management, but I should be treated as a separate project.
This becomes more important if you have Beta test sites. Getting the site ready to receive the new release is a project itself. Who are your contacts? Are they ready for the new release and have been briefed on the changes? What is the procedure for reporting issues? Reporting praise? How long is the Beta period? Are you ready to roll back the release with minimal downtime?
Once past Beta, are your customers ready? All of the questions above have to be answered for every client before the release is rolled out.
Administrative functions
This is the part of the job that everyone hates, but it is part of the job and some of your most difficult decisions are going to be here. Budgets, hiring and firing people, competing for resources and space, writing reports, accounting etc. are all stuff you did not learn in school but hopefully picked up along the way. The most important thing here is to Know What You Don’t Know! I have seen so many good managers get lost here and you can get your company and yourself into a lot of legal problems by going on what you think you know. If you have the slightest doubt about what you are doing, do some research, seek help, and find someone how has the knowledge. I can’t emphasize this enough, a mistake here could result in a lawsuit against your company, with you to blame.
Team Staffing
This is part of your administrative functions, but deserves its own section. Having all the right team members in the right roles is an ideal that you will never reach, but that doesn't mean that you shouldn’t strive for it. Getting the right levels can be tricky, a large team will cost more and can be less effective than a smaller team, but you should not try to have everyone working at 100% capacity. You need to allow for slack so your team can respond to sudden extra demands without putting your projects at risk.
Don't sweat it if people need days off for family matters or other reasons. Personally, I don't track these days so long as the person is an effective team member. There have been plenty of studies that show that teams with high absentee rates (within reasonable limits) are more effective than teams with near perfect attendance. This is because team members are forced to learn different parts of the system when those people normally in charge are not there. So letting people have time off for personal reasons can actually make your team more effective.
Turnover is something that happens and can be a good thing. I tell young developers that they should change companies every 5 years. This gives them exposure to different environments and technologies as well as different processes. This is something I look for when reading resumes, so I also expect people on my team to move on. You need to plan for this; you don't want to be begging someone to stay because they are the only one that knows a certain part of the project or system. Make sure that information and knowledge is spread though out your team, not concentrated in one or two key individuals.
Eventually, every Development Manager will be faced with letting someone go. Whether this is due to financial considerations (team downsizing) or poor performance, you have to be ready and know your companies policies and procedures. Even then you should be aware of you legal responsibilities. In Canada there are statutory termination requirements when terminating someone without cause, but there are also Common Law rights to “Due Notice”: time to find another job without loss of income. Just meeting the statutory requirements can result in a Wrongful Dismissal lawsuit, so it is best to put together a package that you think the person will find acceptable from the outset rather than have them running to a lawyer. It also does not hurt to have a reputation as treating people well when you are ready to rehire.
Conclusion
This is a long list. You don’t have to be an expert on any of them, in fact it is best you are not. This prevents you jumping in and taking over when you have better things to do.
For me the best example how to be a Development Manager comes from the world of manufacturing and a story I heard about Bata shoes. In his original factory, in what is now the Czech Republic, Thomaz Bata had his office built in a freight elevator. Whenever there was a production problem on a particular floor, he could move his entire office to that floor and micro manage the situation until the problem was solved. Then he could move down to the main floor, out of the way, and get on with running the company without the distraction of the production floor. Micro manage when needed but get out of the way and let your team get to work the rest of the time, you have a lot of other things to do.
About the Author
Based in Toronto Canada, Robert McCabe has been working in the software industry for over 30 years as a Developer, Team Leader and Development Manager. As a consultant he has performed a number of project rescues, getting failing project back on track by improving processes and team effectiveness. He has worked widely in Canada, USA and overseas and has experience in a number of sectors including Financial, Insurance, Multimedia, GeoSpacial, Broadcasting, HealthCare and Government, and is currently seeking new opportunities. You can contact Robert McCabe here.
Are you an architect or aspiring to be?
Stay on top of trends in the industry with one monthly newsletter, written by architects for architects.
