When you do a great job as a developer, you often get promoted. The irony is that with most promotions, what you do often changes from what you previously did. One of the most important things you can do when offered a promotion is to become aware of the changes that are expected in what you will be doing. It is important to know what additional tasks are likely to be added to what you are doing as well as what tasks you have been doing that you will need to give up.
There are some promotions you can receive that have minimal impact. For example, some organizations will promote a developer from a junior status to a regular status, and then later to a senior status. This type of career progression often has less change in expectation; however, this progression also has a more limited career path.
It is when a promotion shifts you to a role that involves management that larger changes can happen in what you do. This would include promotions such as going from developer to team leader or from developer to development manager. It is this kind of promotion that many developers strive for; however, it is also this kind of promotion that can lead to the Peter Principle, or to putting you into a position you no longer care to do.
One of the things you can do to avoid being promoted into a position that is beyond your ability is to be aware of what you are good at doing. Knowing your strengths and weaknesses is core to understanding if you are likely to be able to succeed at something.
Knowing your strengths and weaknesses will also help you to avoid getting into a role that you don’t find enjoyable. Equally important is understanding what you enjoy doing. Developers that get promoted into a position they don’t care to do often end up leaving a company even if they would prefer to simply be demoted back to their previous role.
In both cases, the best way to make sure you continue along a career path you enjoy is to be aware of the impact a promotion is going to have on what you do. With that in mind, the following are several changes that can occur in what you do should you be promoted into a position that includes developer management.
Change 1: Less Coding, Architecting, or “Hands On”
While many developers don’t like to do testing, most like to code. Along with coding, developers tend to like to do the architecting and other hands-on tasks related to creating programmed solutions. After all, these tasks are what put “program” in programmer.
The reality is, most developers would prefer to spend more time coding than they currently do. They find that other tasks such as meetings can get in the way. As such, one of the biggest changes to be aware of is the redirection of your time away from coding.
Change 2: More “paperwork”
There are many opportunities that can happen when you are promoted, and many are covered in the following sections. One of the most grating tasks that tends to come with a promotion is more “paperwork.” Such tasks can include little things such as tracking a team’s time off, approving vacation days or being the person a team member calls when they are sick. It can also include bigger tasks, such as writing reviews, doing performance management tasks or reporting the status of the team’s projects.
The bigger your team, the more time administrative tasks are likely to take. Because these tasks tend to be driven by a human resource department and pushed down by upper management, they tend to be visible. Thus, they are tasks that tend to have to be done if you expect any future promotions!
Change 3: Thinking more strategically than tactically
As a developer you might not see everything happening within a business. Often the focus of developers is to deliver a solution that meets a set of requirements. Their approach is often tactical, using a set of predetermined tools to derive a solution that meets a defined set of needs.
As a manager, the role can become more strategic, with a focus on the business rather than just the solution. In general, the focus expands beyond just your own projects that have been assigned. It can become necessary to be aware of what the business is doing beyond just your own group. Depending on the size of the organization, you might need to understand what the business units around you are doing or what the business as a whole is doing. As a manager, it will be more important to understand how you and your team’s actions fit within the larger strategy.
This begs the question; how do you learn the business?
Often developers understand a portion of the business better than many of the otherwise involved. This is a result of having built business rules into the applications that are driving the business. Unfortunately, while a developer might understand a segment in extreme detail, that doesn’t mean they will know the business rules that other developers have coded or of how those rules apply outside of the applications they’ve done. As such, when you are promoted into a higher-level position, it is common to find a need to expand your understanding of the business. To accomplish this requires time and effort – time that comes from other tasks that could be done.
Change 4: Changes in the amount of control
Many developers mistakenly believe that they will have more control if they are promoted. While this can be true for some areas of responsibility, there is an equal potential to have less control.
As a developer, you likely controlled your time. You were likely given tasks to do, and you controlled getting them done. You either got them done, or you didn’t. If your task required something from others to complete, then while that could impact your delivery, it was outside of your control. This provided a reason for missing a delivery.
As a manager, you have tasks you are given as well. Some of these tasks you will do while some of the tasks you will delegate to team members. You gain control of how you get the tasks done as well as how you allocate them across your team. You are, however, at the mercy of your developers to accomplish the tasks. If one of your team members doesn’t deliver, you don’t have a reason for missing the overall delivery.
A development manager is generally a part of a larger team as well. While you have a team you can leverage to accomplish tasks, you are also a part of a team with a leader who is leveraging you as well. This means that while you can control those below you, there are likely those above you that are assigning tasks to you. Often the control you gain of those below you is outweighed by what is required by those above.
Change 5: An increase in responsibility
With an increase in control generally comes an increase in responsibility. Often as a manager, you are not only given a higher level of responsibility over managing people, but also a higher level of involvement in delivering what is needed for the business. The increase in responsibility often requires that you lead people that report to you, as well as to work closer with your peers and those above you.
Because of the higher level of responsibility, it is not uncommon to be put into a position where you need to say “no” or to indicate something can’t be done within the constraints that you and your team are operating in. As a developer you were likely asked to deliver seemingly impossible tasks. In a developer management role, you now have developers that say “no” to you for the very same reasons. At the same time, you might be asked from those above you to complete tasks that you believe would be irresponsible to take responsibility for. You might have to still say “no” as well. Just as if you override a team member’s “no,” your superior might override yours. The difference is, if you’ve been given a task to do and your team members say no, you are still responsible for getting the task delivered.
Change 6: More time resolving issues
It should be no surprise after reading the previous changes that another area where you will be impacted is in issue resolution. In a perfect world, everything goes smoothly. As a developer, you should already know things don’t always go smoothly. As a development manager, there are several areas where you’ll be likely spending additional time resolving issues.
As a developer, you likely addressed scope creep on projects. As a development manager, you’ll not only be managing this common issue from those above and around you, but also for the members of your team. Not only will you need to manage project requirements being expanded by the business users, but you’ll also need to manage what your own team members are doing. Keeping your own developers focused so as to avoid adding scope or features is equally important. When that developer wants to add the new animated button that isn’t needed or budgeted, then it is likely that you must reign the project back.
In addition to features and scope, you might also be given more responsibility to manage budgeting and the issues associated with it. This can include determining new allocations as well as cutting existing ones.
A third and more common area that gets added to responsibilities at a management level is the resolution of personnel issues. Whenever two or more people are involved in a task, chances are issues will arise at some point. If you have a team, then any issues that arise with its members often become your responsibility to resolve.
Change 7: Toeing the company line
One of the changes that many developers can find hard to accept is the need to balance personal opinion with what is best for the company. Developers often suggest better ways to accomplish tasks. They will suggest newer, more innovative ways to accomplish something. Suggestions might be for better products or tools that could be used. As a manager, in the best interest of time and the company, you might need to say no, even when you agree with the developer.
There are times when you might have to make or support decisions that you feel are not optimal. As a manager, it is important to consider what is in the best interest of the business. This can include weighing the level of work to be done against relative to what the business gains. Often this requires making a decision on what is “good enough” versus what is the best solution available.
Similarly, while many developers believe that a promotion will lead to the ability to replace the underlying systems within a company with a better solution, this is often not feasible due to risk, finances, or a variety of other reasons. As a manager, you might have to support what is in place already. This can give the impression of ‘toeing the company line.”
Change 8: You become “one of them”
Part of being included in making decisions at a higher level is an expectation and responsibility to keep things confidential. As indicated in Change 7, you often gain access to additional information that helps you to better understand risks and costs. While you are gaining insight into more of the details, your subordinates are not, nor are you always able to share what you know.
As time passes, the changes that occur in the transition to a management role will cause relationships to change. This can result from the difference in authority created when you were promoted. The result is that developers that report to you might be more reserved knowing that you are responsible for reviews and other impactful decisions related to their careers. Your previous peers might not include you in conversations that you previously were a part of.
Change 9: More meetings and more communications
While it isn’t necessarily always true, in general, most people end up in more meetings the higher they are promoted in an organization. This should not be a surprise since the higher you progress in a company, the more you tend to rely on those reporting to you for tasks to be completed and the business to be moved forward.
Of course, it is possible to limit formal meetings; however, you will need communication to flow so you can stay aware of where things stand. You’ll need to keep the communication flowing with your own team members. You’ll also have to continue to keep the flow of information happening with your boss.
Change 10: Potential for more external relationships
The role of a developer could be accomplished without interacting with very many people. Depending on the specific development role, this could be working with other developers, an analyst, a manager and very few others.
Developers that get promoted into management roles tend to be those that interact with a wider range of people. Once promoted, in addition to communicating with many of the same people you interacted with before, it is common to interact across a broader array of people within the organization. In large companies, this might include interacting across more technical teams as well as with other managers. In smaller organizations, a promotion into a development management role might also include more interactions with business units, external users, and higher levels of management. It might also include time spent working with external vendors and peers in other organizations.
Conclusion
As you are promoted, most roles will push you towards using more interpersonal skills rather than technical skills. If you are a developer that prefers to be head-down writing code and avoiding other people, then a promotion to a position that involves more management could be brutal.
Every role is different, so not all the above items will change if you are promoted. It is wise to ask about the expectations of a promotion. By being aware and by communicating, you have a better chance of avoiding the Peter Principle or a promotion into a role that makes you want to leave. Better yet, by understanding the expectations of your new role, you’ll be better positioned to excel and then possibly be promoted yet again!
