How and When (If Ever) Should Software Engineers Move into Management?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
After a few years on the job, most software engineers wonder what the next career step is, and many think there is only one right answer: management. To get some perspective on the career choices software engineers have and what they might do should they decide to move into management, I interviewed two people who know all about the subject:
- Clark Waterfall: A longtime executive recruiter, Clark is managing director and co-founder of BSG Team Ventures.
- Eric Giguere: A software developer at Google, Eric has authored or co-authored several books, including Programming Interviews Exposed: Secrets to Landing Your Next Job [Wrox].
Do you recommend that every software engineer strive to move into management?
Clark Waterfall: Absolutely not. Software engineers may never want to go into management. There are those who wish to lead and manage, and there are those who don't. Really bright people often hate the requirements and restrictions of oversight, and the accountability of being responsible for others.
I don't know that moving up or moving into a managerial role is necessarily something that pays that much better, either—particularly if you are really good at software engineering and you don't want to manage others.
Besides, you might do better moving into an architect role and aspiring to become a chief architect. There you deal with the middle-tier, logical level. Let's say that throughout your career, you've coded really well. As a result, you have a really good understanding of the software your organization is building. You could be ready to move into an architect role, which is typically an individual contributor role. That's often a bigger responsibility than a management role in terms of building the software, but not bigger in terms of managing people.
Eric Giguere: I think most software engineers are tempted to go into management as they progress in their careers. This temptation may come about for multiple reasons. It could be that they think management is the best way to actually progress, or they want to gain greater influence over a project, or they're tired of coding, or [...] someone needs to be the manager and [they think] it might as well be them. The latter point is interesting, in fact, because taking on management responsibility is sometimes thought of as "taking one for the team."
I've tried management. The team I was on grew so big that the manager was having trouble keeping track of everything, so the team was split into several sub-teams and someone from each sub-team was asked to manage the new team. That's how I became a manager. I didn't actually ask for it; it was asked of me.
I managed that team for a couple of years. It ended when the entire project got cancelled and I was moved into another team as an individual contributor. A few years later I got to be a manager again. This time, too, it was out of necessity. I think my experience moving into management on those two occasions was a pretty normal way for first-level engineering managers to be developed.
You can't pick engineers at random, of course. Usually you go with one of the tech leads, who by virtue of being tech leads have shown that they have some people skills, [if you can] convince them that it's not evil to start managing their co-workers.
What would help software engineers figure out whether or not to go into management?
CW: Do they have children? If they have children, they are prepared. If they have never had children, that's a whole other issue. If you've had children and survived, then you probably have some of the rudimentary skills required for management.
Leading other software developers is not easy. Software developers are by definition really bright. They love problem-solving on their own. They love doing it their way. The expression "herding cats" certainly applies to the situation, because managing software engineers involves managing a bunch of independent people.
Think also about the kinds of hobbies and sports you have a passion for. If you like individual sports such as tennis, golfing, or squash—or if you like doing triathlons—you are probably individualistic, and it might be hard for you to move into a management role. If you lean more towards team sports, that's probably an indication that you are team-oriented, in which case you could fit right into management.
EG: First of all, do they have the necessary people skills? Getting along with others and having the respect of the team are very important qualities for prospective engineering managers. You will write very little code—maybe none—going forward. So you need to be able to motivate and convince others to write the code in your stead. In other words, you're taking yourself off the critical path.
Second, do you need to code? Managers tend to drift away from coding for very practical reasons. So if you need to code, management is definitely not for you.
Third, are you willing to do the unpleasant tasks that managers have to do—performance reviews, hiring, firing, motivating, dealing with personality conflicts, and so on? Managers have to do a lot of things that individual contributors can safely ignore.
Basically, you need to ask yourself if you have what it takes to be a good manager and if you'd enjoy it. If you can't answer yes to both of those questions, then you need to stay an individual contributor.
Do you think that there is a clear career path for software engineers who choose not to go into management?
EG: It depends on the company. The larger software companies tend to have career paths for individual contributors. This is true at Google, for example, and it was true at Sybase [when I worked there]. You can grow as a software engineer and take on more responsibility without having to manage others.
The flipside, though, is that it requires a much more impactful technical contribution on your part. As a manager you can grow based on the impact of your team, which means in some sense you're leveraging the work of many others to get yourself promoted. That's harder to do as an individual contributor.
For smaller companies, management might be the only path you have to get promoted beyond a certain point. This is especially true for companies that don't sell software or web services.
If a software engineer has ambitions to become a manager, what can he or she do to prepare?
CW: The first thing you can do to prepare for a management role is to find [... software managers] who are clearly able to manage and lead a team of bright people. See if you can get one or two managers you respect to actively engage in mentoring you.
The second thing is to internalize the idea of hiring and managing people who are smarter than you. There's the adage that if you hire a talent, you have to manage less and lead more. Management might be defined as measurement and metrics, establishing key performance indicators and check-backs. Leadership, on the other hand, is about providing vision, and motivating people to work towards that vision.
One person I placed recently told me that one of the things he learned after his first management role is to hire better. That makes the whole task of management so much easier. He told me that the first time out of the box in a management role, he was of the mindset to just get it done—just get a body in there. Since then he has learned to hold out and take the time to wait and search for quality people.
The third thing is to study. There are some good courses on leadership; there are also some great articles out there that provide tips on leadership. Most schools with an MBA program have courses on leadership—and even specifically for technologists. You can get these courses online or as massive open online courses (MOOCs), or you can attend night classes.