You’ve been at your company a while, maybe as little as a couple of years, maybe substantially more, and the idea of moving into management has crossed your mind. The idea can occur for any number of reasons. Maybe you found out that there’s an opening, either internally or at a different company. Maybe someone from management has asked if you’re interested. Maybe you’ve been in your current position for a while, and it’s not as challenging as it used to be. Maybe you’ve been unimpressed with the management at your company, and you think you can do a better job. No matter what the situation, you’re suddenly faced with the idea of becoming a manager. Is jumping to management a leap you’re ready to make, and what are the alternatives if you don’t?
The standard path?
From the outside, moving from developer to manager can seem like a standard path. You did your time in the code mines, and now you’re rewarded with a new title (and hopefully a raise). What does that path really mean, though? Do you stop writing code completely and give yourself over to Excel spreadsheets and performance reviews? Looked at from that perspective, it might not make much sense. Fortunately, that’s an oversimplification. Depending on your organization, you might be a team lead or a project manager before moving into an entirely management position. There might be a training program to help you make the transition.
Whether such a position exists depends largely on the size of your employer, and how dedicated they are to the idea of promoting from within. A large company may have formal promotion tracks set up, and if you’re really lucky, with internal management training. A smaller, flexible company may allow you to define your own role. You might take on some management tasks in addition to your developer duties simply because there’s nobody else available. Or you could work with your manager to define the sort of role you want, and the transition path that’s best for you.
Is it right for you?
Before you make the leap, consider whether you have the disposition to be a manager. Code does what you tell it to do (even if that’s not what you really meant). Coders, on the other hand, tend to behave like people, rather than like computers. You’ll need some people skills, or at least empathy and willingness to develop those skills, before you can become a manager. Being a project lead can give you the opportunity to test out how well a management position fits on you before you accept.
In addition to having empathy, you should probably get specific training in goal-setting, mentoring, time management, conflict resolution, and assessment. You may not be used to training in “soft skills,” or you might think you can get by on what you currently know, but that’s setting yourself up for failure. Odds are you’d get training if you wanted to learn a new language or technical skill, so apply the same logic to your people skills.
What will you miss?
One of the realities of moving to management is that your day-to-day activities will change. You’ll have less uninterrupted time to code, and more time spent talking to people, attending meetings, answering e-mails, and troubleshooting. Management is what’s known as an “interruptible task” – at any time you may need to pull your attention away from what you’re working on to deal with something more urgent. Time-management skills become critical at this point.
Many of the people I spoke to about their transition said that the biggest thing they missed was the ability to be “in the zone” while writing code. Most programmers have experienced “the zone,” that period when you’ve got the headphones on, it’s just you and the code, and time seems to pass without noticing. The zone is an ephemeral thing, but no matter how skilled you are at entering it, odds are you’ll see it a lot less, if at all, when you’re dealing with management issues.
Deciding whether to take the step into management sounds like a personal decision, but whenever you’re talking about management, there’s a team to think about. Are you the kind of person who works best on your own, or do enjoy accomplishing things as part of a group? A lone wolf coder probably isn’t the best fit as a manager, but lots of people enjoy working with other programmers, generating new ideas, and helping the group to achieve their goal.
Another management stereotype in tech is the manager who has never been a developer and doesn’t understand the fine points of writing code, or even the not-so-fine points, like how long it takes. Everybody’s had one of those managers. If you don’t want to work for that manager, why not be that manager yourself?
You really need to be in touch with your own skills to be able to say “I’m not the best coder in the room, maybe I can be more useful in other ways.” If you can make an accurate assessment like that, you may have what it takes to be a good leader.
What if you don’t?
If you’ve been around a while, you may have been offered the opportunity and have done an honest assessment of your skills and temperament, and you’ve come to a conclusion: management isn’t your bag. Don’t let that be a negative, and don’t let anybody else tell you it is; you made the choice that’s best for you. Maybe you don’t want to give up coding. Maybe you don’t have the right personality for dealing with people. Maybe you haven’t learned everything you want to learn at your current position, or there’s some other career goal you haven’t achieved yet.
Some companies, but by no means all, offer a technical career track that doesn’t include management. It could be called “technical strategy” or “individual contributor” or something else; you may have to seek this track out. A technical track enables talented engineers to contribute substantially to the advancement of the company without necessarily managing people. A technical lead might be more involved in software architecture, or in strategy planning for the company’s larger goals, or be called in to advise when a problem gets really tricky. They might be encouraged to lead training sessions for other developers, or to do research that could be published as white papers, or even to work on side projects that could turn into major new products for the company.
The people I spoke to who weren’t interested in management said that the most important career advancement to them was a steady diet of new and interesting challenges. It’s important that companies realize that people skills aren’t the only skills that create high-level value for the company. People with different personality types have just as much to offer, but in a different way. If your company doesn’t offer such a track at the moment, investigate whether you can start one.
If you currently lack the opportunity to advance in a technical track, you can stay where you are. If your work is interesting enough, and the pay is right, the title you hold may not make any difference to you. If you’re happy with what you’re doing, perhaps by the time you’re ready for a change, your company will be more willing to consider a technical track, or leadership training, depending on what you want.
If that’s not working out for you, there’s always another position. That can be easier said than done, but if advancement is important, you can consider a position at another company that offers more growth opportunities. You could also consider contracting. Contractors are responsible for their own management issues, and still have the responsibility of writing code. Becoming a successful contractor is another discussion altogether, but it’s a step out of the traditional management track.
A good problem to have
No matter how the opportunity arose, and no matter what you ultimately decide to do about it, being in a position to consider moving to management is a good thing. Somebody within your company recognizes your value, and hopes that you’ll be able to help your co-workers develop their own careers.
Have you considered moving to management? Did it work out, or did you regret it? Do you have any experience with an alternative technical track? Tell us your story in the comments.
This post is part of our ongoing exploration into what it means to actually be a software engineer.
Public domain metal mesh image via pixabay.