The function of the development manager

The development manager is a job with a higher pressure. As a "middleman," you need to juggle the roles of management, customers, sales, developers, and more. No one will notice how good your job is: Everything is working well, the work is progressing smoothly, and everyone needs it. But if things fail, whatever the reason, it's all your fault.

The secret to becoming a successful development manager is to manage expectations, and the first step is to make sure everyone understands your role. Those of you who work with you should agree with the development manager's expectations.

I've seen a lot of recruiting information from development managers, but I don't quite agree with the above description. There is a requirement to drill down on a large number of programming languages and environments, and one requires 66% of the time to program (why not write two-thirds directly?) , there are some requirements for PMO certification, similar requirements. I admit that the function of the development manager is a little blurry, but recruiting information like this makes me think that the company that publishes these positions doesn't really think about the function of the development manager. This situation is a recipe for trouble for the company and the people employed.

As a development manager, you have to bear a lot of responsibility, but it is important to release the product. Your goal is to take all necessary steps to ensure that the product is delivered to the customer or market. To do this, you need to ensure that the development team works as efficiently as possible, and that they have clear goals (both short-term and long-term) to remove all obstacles that hinder their work. From the initial project scope to the deployment of products on the customer's website, each step is your responsibility. You can (and should) delegate things to subordinates as much as possible, but check to see if things are the way you expect them to be, if not to invest in them.

Project scope definition

As a development manager, you need to know how to define the scope of the project. Depending on the situation in your organization and how you collaborate with external groups, this may be an important part of your work. If you are regularly responsible for third party projects, you should know how to respond to RFP (requirements proposal), including deliverables, schedules, and budgets. Even if you only do in-house projects and don't have a formal documentation system, you should develop the habit of writing a project scope statement for each project. In addition, if you are engaged in agile development, these documents will continue to be maintained and updated as the project progresses.

"Total Top" item

This is part of the scope definition of the project, but it should be explained separately. I've heard people talk about "total-top" projects that don't require budgets or timetables. It's a mistake! If you're not sure how the costs and deliverables depend on these "top items" projects, it could kill your team because these "top-up" projects can delay progress and consume resources that other jobs require. Each project you undertake must have at least one internal cost and one deliverable. You have to negotiate with other stakeholders about what you're doing.

Manage relationships

Remember, you are the middleman, and any failure is your fault, even if the cause of failure is something you can't control. You need to maintain a good, open relationship with the people involved.

You should not only let your direct boss know the situation, but also let his superiors and other peers know. In addition, you have to make the project more relevant to other stakeholders. Make sure they're all in the "message Circle", get status updates regularly, and know what your team is doing.

Who handles customer relationships? These people are the ones you need to know in addition to the boss. They can manage customer expectations, handle complaints (real or imagined), and keep in touch with customers. On the other hand, they can make you miserable, do not check with you to give customers promise, submit unnecessary bug reports, pestering you to follow the unrealistic timetable, and so on.

Know your team, how long have they been in the company? What are the advantages and disadvantages of each individual? Who can collaborate with them better? How busy are they? Pay attention to their birthdays, anniversaries, etc. ... Although it is a trivial matter, but the significance is serious.

Make sure that managers know what you are doing and can see your progress so that they are satisfied. Communication and visualization are key. I've used a variety of tools to keep managers abreast of status and find more information. Use the Program Toolbox, bulletin board, Whiteboard, and any tools you can think of to get the latest information.

If stakeholders understand the challenges you and your team face, they may be less likely to mention unrealistic expectations. I said that they might not mention it, not never. Some managers will never understand why things can't be "working". You may have to find a new job in this situation.

Project plan

As long as you are not in a large project, you generally do not need a separate project manager. For small or medium projects, and for projects that use agile methods, you can assume the role of a project manager and be responsible. But the development manager is not a certified project manager. Aside from the controversy between traditional project management and agile Development, the concerns of development managers and project managers have been conflicting. As a development manager, your job is to do as much as you can, and the project manager's job is to determine when the content will be completed. You have to strike a balance between two starting points. If your project is large enough to require a professional project manager or Scrum Master, find one for your team and don't try to play the role yourself. However, whether it's a waterfall model or an agile process, you should make sure that the project plan is active, keep updating, and track progress.

Process Control

This is another key part of the job. Whether you're using an agile method or a waterfall approach, you have to take control of the process and keep things in the process. Remember, delivery is your job, and anything that affects delivery requires your highest priority.

What is the development process you are using? What kind of form is it? If you say it's a "agile" process, check to see if it's really agile (I've kept a handy quick manifesto poster to remind myself to follow the agile principle). How has your process improved? There is no perfect system and there is a constant search for ways to improve the process. We've done a lot of work to deal with the root cause analysis of bugs, but more often the process is flawed, resulting in poorly designed, poorly coded, or misunderstood customer needs so that the product cannot be released.

Entrusting others is a good thing, but you have to follow up and make sure things are done. Great ideas are often unsuccessful in execution because no one examines the results of the process. I've taken over several projects, and it's all good before I take over, but bad execution leads to a mess.

Finally, you need to report to various stakeholders the status of the data based on the exact metrics. So you need to measure and summarize the process in a meaningful way for the person reading the report. Determine the reporting frequency (daily, weekly, or on-demand) based on your organization's situation. Be clear about the frequency, format, and content of the report. Pay attention to the details of the people who read the report and the level of detail they expect, and reach that goal. All of this will make your report clear, clear, and readable. This reduces the misunderstanding of the report, but does not mean that it eliminates misreading. The person who reads the report has a lot of things to do, may just skim it, or understand it in their own way, so be prepared to clarify and explain, but that doesn't sound like an excuse.

Technology

I have seen this request many times in my job position. Some companies require the development manager to gain in-depth knowledge of specific areas. As a development manager, you are not a technical expert! Leave this requirement to senior developers and lead developers. You should be familiar with existing technologies, understand new and upcoming technologies, but don't let yourself become an expert, which can take a lot of time and distract you from other tasks. Be aware of the tools the team is using, see if the team members are using them effectively, and know when the team will be in the knowledge gap, but you shouldn't be the one to "fill" it. You have to let go and entrust the team's senior developers with the knowledge of the vacancy.

Development

This is also an area where you need to be familiar with, but need not be, an expert. Great programmers can write the best code, but it's usually a bad manager. You have to be able to distinguish between good and bad code, and you should trust your team leader. You can invest in and take over some development tasks at critical moments, but don't forget to have a big picture and focus on the completion of the project. Can not be immersed in several days of programming, forget their work.