There’s more than one way to progress your software engineering career

Author Vivek Ravisankar, Mashable

The stoic, traditional career ladder is pretty much nonexistent in the world of software engineering.

The best engineers have choices: You can venture into the unfamiliar domain of management, in which your biggest challenge is getting all hands on deck to achieve an exciting vision. Or, if you deeply enjoy the art of coding, you can reach incrementally higher peaks as a distinguished individual contributor (IC). The truth is, there’s no real hierarchy etched in stone.

True success comes from playing to your strengths — not manager titles. There may have been a sense of prestige associated with a managerial position in the past. But, like any highly specialized field, developers can grow to become more influential and respected in their technical roles.

Back in the 1980s, Microsoft execs asked their best engineers to run projects, but some engineers didn’t want to stop coding for managerial duties. So, to retain and reward their best engineers, Microsoft created a formal technical progression. Several decades later, the dual track is still going strong. In fact, many other tech companies have created their version of the tech track since then, including Google and Facebook. But the underlying equality of the dual track is prevalent throughout the entire field, no matter where you work.

Don’t fall prey to the Peter Principle

It’s worth hammering home why great engineers often find themselves in management positions against their desires. The answer is famously outlined in the classic 1960s The Peter Principle, which observes the natural inclination of promoting your best employee until he or she has to practice skills beyond their competency.

“There is much temptation to use what has worked before, even when it may exceed its effective scope.”

The book is a satire, but studies show that there’s truth behind this commentary. You’re a great engineer, but managing engineers requires a host of brand new people-management skills that aren’t typically required of engineers. So, if you’re deploying high-quality code and are asked to run a team, there are compelling reasons to take a step back and consider if management is truly your ambition.

You’re not climbing a ladder, you’re climbing a tree

Par Trivedi, engineering manager at Uber, says he runs across many engineers who think they want to be managers, but end up hating the job. And I can understand why this happens.

Often times, young engineers can’t quite shake the feeling that, in order to move “up” and get better pay and recognition, they have to become managers. But this idea is completely false. In fact, the path isn’t set in stone. Even if you’re already in a manager position, Trivedi makes a great observation: “There are plenty of engineering managers who decide to go back on the IC route later.”

So, what does a senior IC look like? Ben Pfaff, principal engineer at VMware is a great example. As one of the first creators of OpenFlow and Open vSwitch, he’s undoubtedly one of the trailblazers in the entire field of network virtualization. As a result of his vision and strong performance, he could have easily become a manager, director of engineering or even started his own company. Instead, he’s driven by the exciting problems he can solve hands-on as a principal engineer. Network virtualization is how the world runs today, and by taking the more specialized track, he’s earned high prestige without a managerial title.

Comparable compensation

If you don’t work at companies like Microsoft with a clear dual career track in place, you can make a strong case to carve out an IC path with comparable compensation. First of all, the market value for an engineering manager is just about the same as a senior staff engineer. Again, it’s not really about the syntax — it’s about the level of work, responsibility and creative influence that comes with each promotion.

So, why are non-managerial roles paid just as much as managerial roles in software engineering while most of corporate America doesn’t operate this way? There’s a widely cited stat: A truly good programmer can be up to 10 times more productive than an average programmer.

A truly good programmer can be up to 10 times more productive than an average programmer.

Soham Mehta, founder of Interview Kickstart, and former director of engineering at Box, offers a great rule of thumb for determining the best technical aptitude for engineering managers:

“On a scale of 1-10 — 10 being the best technical skills — engineering managers should be about seven or eight. If you’re the best technically, you could very well be an awesome manager, but that just means you have a choice: Do you want to get into the management ladder or do you want to stay in the technical ladder? Often times, ’10’ engineers are most impactful to the company in a technical role. And anything less than a seven means you can’t gain the trust of your team.”

In other words, if you’re the best programmer at your company, you have a strong case that it is better off with you writing code and raising the bar of innovation. Plus, some of the best senior ICs are likely to develop the most sophisticated and patent-worthy technologies to help the bottom-line through innovation.

Equal respect and influence

So, what about prestige? Are ICs considered “less” influential than managers?

It’s quite the opposite. If you’re higher up in the technical field, you’ll often have more influence on the direction of the company. Since you’re the most apt in-house specialist, everyone will come to you for suggestions.

If you’re higher up in the technical field, you’ll often have more influence on the direction of the company.

What most people don’t realize is that in software engineering, you rarely have a firm hierarchical dominance over one another. Trivedi explains this dynamic perfectly:

“Most people perceive their manager to be their ‘boss,’ but rarely does an engineering manager decide many things that affect an engineer. Engineering managers work closely with other teams to hammer through integration issues, help unblock projects and keep the project roadmap up to date. But the engineering manager doesn’t usually decide what the team will work on — that comes from the product team. And the engineering manager doesn’t decide deadlines — that usually comes from the sales teams.”

The technical track tends to be more familiar for engineers who prefer to dive deep into their discipline. Your scope of influence in creating amazing technology grows larger. It encompasses taking on bigger technical challenges: the very thing you first fell in love with. Managing engineers, however, is extremely difficult because the job isn’t well-defined and you have to learn as you go. Unlike coding, it’s about being able to manage what you can’t control: People.

The skills that make a great engineering manager

Managing engineers is a challenge worth taking if you enjoy communicating, interacting and problem-solving across departments. I recently had enlightening conversations with both Mehta and Brent Jenkins, senior director of engineering at Ticketfly and previously director of engineering at Oracle, that helped drill down to the foundational roots of the best managers.

They have strong tech skills, but don’t code often: Strong technical skills can’t be emphasized enough. If your skills aren’t strong enough, it is nearly impossible to gain the trust of your team. It’s also the ammo you have against lazy engineers who project outrageous ETAs for small bugs.

At the same time, most, if not all, engineering managers agree they should never check in mission-critical code. As a manager, you can only contribute to code with a team of small or very senior engineers. If you’re coding after your team grows to seven or eight people, you become the bottleneck. Not only will projects be delayed but you’ll also be forced to rush through your code, lowering the bar for your whole team.

As you transition to the managerial role, you might find it difficult to cope with no longer coding on a regular basis — but there are incredibly powerful benefits that come from no longer coding. Some engineers worry they’ll stagnate in managerial roles, but realize that learning people skills is a challenge in itself. Think of it as a new domain to master. It took you 10 times to build the system perfectly; likewise, it’ll take you 10 experiences to master people problems. You’re developing a different part of your brain.

You also get a more holistic and fascinating picture of what your code actually does. How does one bug cost the company millions of dollars? Why are tradeoffs important? Rather than getting look through the trees, you can see the whole forest.

They learn to develop strong people management skills: Most of your problems as a manager are going to be people problems, not technical problems. Dive in and get your hands dirty — there are no shortcuts for this. No matter what deadlines you’re given or benchmarks you need to meet, remember that — above all — your singular focus is to align your team.

Mehta eloquently explains that if you can get everyone aligned and inspired, you can push out features on tight deadlines with no problem. But it’s definitely the hardest part of managing engineers. After all, he says: “Code doesn’t change its mind, people do. Code doesn’t leave you, people do. Code doesn’t misunderstand you, people do.”

They keep developers aligned and focused: Jenkins brings up another important hurdle that new managers often have to clear: Prioritizing is tougher than you might think. Most engineers are quick problem-solvers. It’s easy to get fixated on one bug or feature for days without taking a step back and looking at what’s really important.

“We hear requests or calls for improvement and we immediately start to think about solutions,” says Jenkins. “There are a lot of things that compete for our time, and as an engineering manager you always have to be conscientious of what should really come first.”

“There are a lot of things that compete for our time, and as an engineering manager you always have to be conscientious of what should really come first.”

They’re able to manage their friends: For Mehta, learning to manage former colleagues was one of the biggest hurdles he faced as a new manager. The same people he worked alongside became his direct reports. This can be really awkward at first.

He pushed through it by biting the bullet. “Just do it,” he says.

They can distill what’s most important: Resist the urge to add fire to the flame. As soon as you become a manager, you’re privy to a lot of information you may previously have been unaware of. Things are constantly changing in any given organization and — it’ll be tempting — but you can’t relay everything to your team. The best litmus test on filtering the bureaucratic noise: Does this information help my team stay aligned to our vision? If not, then resist the urge of spilling and keep it to yourself. It’s harder than it sounds.

Software engineering teams have a fluid, collaborative hierarchy. Whichever engineering adventure you choose, whether it be to bring out the passion in other engineers or to pour your soul into your unique specialization, one is not better than the other. If you’re feeling stuck as an engineering manager, remember you have other options. Companies will equally value your contributions in a senior technical role. There’s infinite room for both leaders and creators in the world of software technology.