If you are a software developer contemplating a move into management, let me start by telling you that you are, in fact, a rare breed. Through my entire time as a developer I constantly heard other developers express their disdain for management responsibilities. When you ask about career goals for most developers, they lean towards the technical side: principal/staff engineer roles or architecture roles.

There is a vague notion that most developers hold of what exactly a manager does, and most want nothing to do with it. This includes things like constant meetings, generating weekly reports, and lots of Excel spreadsheets. Yuck. Why give up the joy of programming for any of that?

A switch into management entails a lot more than these superficial observations (although there definitely is an inordinate amount of Excel spreadsheets in my life now). It’s also a very rewarding career move that forces you to grow in unexpected ways. You can expect the following changes as you transition from the trenches to management.

Note: these points are most accurate in a medium-to-large company where you have 10+ developers reporting to you.

Change #1: Your Rockstar Status is Revoked

Chances are you were a rockstar as a developer. Or, at a minimum, an above-average contributor. When a new feature comes in, or a defect is reported, you could see it through to completion all on your own. Your team acknowledges and respects your mastery over the code. Years of practice and learning have given you the ability to contribute at a high level.

This prowess, however, slips away pretty quickly when you become manager of a good-sized team. It’s not that you forgot how to code as soon as your title changes to manager; rather, making meaningful changes to the code is no longer your responsibility. This is difficult for some new managers to accept.

Making meaningful changes to the code is no longer your responsibility.

Imagine that an urgent defect is reported, and the other developers most familiar with the code are out sick today. Do you assign it to the junior dev who will take 8 hours to research and fix it? Or do you fix it yourself in 1 hour? The answer to this question is likely very different for a developer vs. a manager.

As a developer, you confirm priority with product owners and start working on a fix. Maybe you even let the junior dev tag along to learn a thing or two. Why let a defect live in the wild for any more time than necessary?

For a manager, you need to consider other things. Your day is likely already full (touchbases, reports that other teams need, planning meetings), so you have to sacrifice something else if you want to help fix the defect. Furthermore, your role as a leader is to make your team grow, and assigning the defect fix to a junior dev is likely a great learning experience for him or her.

It is important to recognize that even if you could personally complete a task faster than your team (fix a defect, implement a new feature, etc.), even by a considerable amount of time, that does not mean you should do it.

A task that takes your team 8 hours to complete, but only takes you 1 hour to complete, still represents 1 hour of lost time for you. A more efficient use of everyone’s time would be to focus on knowledge-sharing about the code so that others could get closer to your 1 hour mark. You completing the task yourself in 1 hour doesn’t do anything to grow the team around you.

I can tell you from firsthand experience that if you try to actively fix every hot issue that comes up, you quickly fall behind on all of your other managerial and leadership responsibilities. This will cause frustration as you look at your growing “to-do” list and wonder why there isn’t enough time in the day to do everything.

Change #2: You are Measured by how Well Others Perform

This goes hand-in-hand with the previous point. As you can no longer be the rockstar solving all the defects and implementing all the features, you can also no longer be judged by your personal accomplishments. The nature of your professional expectations changes.

For example - a developer may put the following on his or her resume:

  • Migrated several projects from SVN to Git
  • Spiked and led effort to separate UI from backend on legacy project
  • Reduced memory consumption in flagship project by 50%, saving lots of money

A manager, however, should provide leadership and guidance to his or her team. Specific project accomplishments like the above do not embody the impact a manager should have on everyone around him or her. The following are good examples of what you would instead see on a manager’s resume:

  • Socialized Git to teams, held workshops, guided developers to migrate projects over
  • Championed tech-debt initiatives with business to allow dev team to make perf improvements
  • Worked with team to introduce ADA learning, development, and testing practices

As a manager you want to have a multiplier effect on your team. It’s one thing if you can personally write ADA-compliant front-end code; it’s another thing entirely if you can promote, educate, and train your team to do it, too.

In Conclusion

Moving into management is more than a title change and added responsibility. It’s requires a shift in mindset. It also requires a bit of reflection and selflessness that we rarely need earlier in our career. And it’s these exact qualities that make it such a rewarding experience.

This insight is a reflection of my experience at a mid-sized company with 15-20 developers under my watch. Your results may vary.