Management should not be the only option for engineering advancement, or even the default one. So how can we support our leading engineers to follow the career path that they truly want?

Great managers make great teams, and organisations are rightfully eager to find engineers with manager potential. But management should not be the default career path for engineers. Many of the “leadership” skills that make for good managers (e.g. setting a clear direction, caring about other humans, understanding the business, building consensus, communicating ideas) are also the ones that make stellar senior, staff, and principal engineers. If we require these skills at senior engineering levels, we’ll boost our ability to complete difficult projects, make better technical decisions, and bring up the skill level of our whole engineering organisation. 

The ‘technical track’

While career progression for a software engineer often involves management, many companies provide a parallel ‘technical track’: a job ladder for engineers who want to continue to focus on their technical skills. 

There are many variants of this career path, but a common one is a senior engineer getting promoted to staff engineer, and then to principal engineer. 

Just as on the management track, seniority on the technical track reflects the impact of the role i.e. how much more successful they made the engineering team or the business as a whole. However unlike the management track, this impact is usually achieved without direct authority. While some folks do straddle the line between engineer and manager, staff and principal engineers typically don’t have a team of reports who can be deployed to solve problems. This doesn’t mean that they work alone though. 

Not an individual contributor

The technical track is often called the ‘individual contributor’ track, but few senior engineers should be true individual contributors. Most should be responsible for clear improvement across their team or organisation. 

This improvement comes from creating compelling technical strategy, executing on projects that wouldn’t have succeeded otherwise, and influencing other engineers to do their best work. I believe that these three axes are how we can describe success for senior roles on the technical track.

Strategy

It’s easy for software engineers to focus on immediate problems. Our most senior engineers should be able to see beyond those immediate needs and prepare for future needs too. By staff level, an engineer should be planning at least a year ahead: understanding how technical changes now (or staying with the status quo) will affect the team then. This means always having a ton of technical, business and industry context, and using that knowledge to predict risks, opportunities, scaling cliffs, and so on. When the way forward is too ambiguous, they should notice which decisions are being avoided and either chase down consensus or make a compelling case for a particular technical direction.

Execution

Our senior engineers most likely got to their role because they’re skilled at executing and completing projects. By staff level, they should be able to lead projects that are too broad, ambiguous or contentious for most engineers to tackle. Engineers leading these projects will use a mix of technical and organisational skills. They need to have enough time and mental bandwidth to dig into the details and make big decisions, enough self-confidence to ask the ‘obvious’ questions that will shake out misunderstandings, and enough organisational clout to influence the technical direction of multiple teams without stomping on their autonomy. 

Good influence

We learn from our own mistakes and successes, but each of us only has a finite number of our own projects to reflect on. We need to learn from each other’s mistakes and successes too. Our most senior engineers have seen some things and likely broken some things too, and those experiences shouldn’t go to waste. Staff engineers can set explicit standards for their organisations, for example by creating guidelines and best practices, by leaving thoughtful comments on code and documents, and by having a high bar for what gets deployed. But they also set implicit cultural norms through their own output. Managers can bang the drum for quality, but if the most senior engineers don’t write tests then you’ll never convince the juniors to do it. 

These three aspects of a stellar senior engineer (strategy, execution and good influence) all need skills that we often recognise as “management” material. The good strategic ideas, the project solutions and the thorough reviews will carry little weight if they’re not communicated clearly or if nobody is convinced to follow them. Without the ability to build consensus across teams, we’ll choose solutions that may be optimal inside a single team but don’t interoperate well, or that duplicate effort. Without business context, engineers will make flawed technical decisions or will waste their time working on something with little value. Without empathy for other humans, review comments may reduce the confidence of junior engineers instead of boosting their skills. 

Of course all this work needs technical depth and technical judgement too. We want our strategies to be sound, our project solutions to actually solve the problems, and our review comments to make code and designs better. But technical knowledge is not enough on its own. Impact at this level means being a force multiplier. 

Not just for extroverts

I want to be clear that I’m not saying all staff and principal engineers need to be “people people”. Influence doesn’t have to be loud or extroverted. Leadership can come from designing “happy path” solutions that protect other engineers from common mistakes. It can come from reviewing other engineers’ code and designs in a way that improves their confidence and skills, or highlighting design proposals that don’t have a genuine business need. I’ve seen excellent staff engineers who would never describe themselves as leaders but who raise everyone’s game as they quietly set the direction for their technical area. 

It’s possible for engineers who prefer to work alone to still make the organisation better through their judgement and good influence. There are a lot of ways to have impact. But contrast those folks with senior engineers who make the people around them worse. No matter what their output is, it’s hard to imagine how they can have enough impact to compensate for the reduced output and growth of other engineers, the effects on employee retention, and the projects that will fail as a result of their unwillingness to collaborate across teams.  We set ourselves up to fail if we promote this kind of engineer to a level where they’ll be seen as an exemplar.

Grow more IC leaders

If we recognise the need for leadership attributes in our most senior engineers, we should cultivate those skills. That means hiring and promoting for the skills we want, finding engineers opportunities where they can lead, and reducing the emphasis on management as the only career path.

Don’t promote for code output

No matter what leaders describe as the company culture, the skills that are shown to be valued are the ones that are getting people hired and promoted. We need to require strategy, execution and good influence from our senior engineers. If we promote a staff engineer who churns out code but can’t work with other people, that becomes the implicit definition of a staff engineer. On the other hand, if our most senior engineers are modelling leadership skills and making everyone better, we’re setting up a virtuous cycle. Mid-level engineers will strive to emulate the same behaviour, and leadership skills will grow throughout the org.

Every project, every initiative and every crisis is an opportunity

Every cross-team project or messy ambiguous problem is a training opportunity to bring an engineer up a level. While we will sometimes want to deploy our reliable heavy hitters on a project that can’t afford to fail, we should take every opportunity to invite another engineer to try leading a project that’s slightly too big for them. 

If they’re set up for success through mentoring, coaching and lots of support, we’ll build the next generation of heavy hitters. The vast majority of our learning happens on the job, so long as we make sure the learning opportunities are available.

Management is a lateral move

Management is a different job from engineering. Though on my earlier diagram of an engineering job ladder it is a clear step up, we shouldn’t be treating it as a promotion. It should be considered a lateral move to another role. Thinking of management as the obvious “next step up” treats it as a prize to be won, rather than a skill to be honed. The best managers I know are the ones who want to be great managers, not the ones who merely want to climb a rung on their career ladder. 

Our technical track ladder should be a genuine parallel path to our management ladder, with the same status and recognition, and it should be explicit about the leadership skills and business context needed at each level.  Moving back and forth between tracks should be normal and encouraged. Skills built on either side will be valuable on the other.

In conclusion

We’ll always need excellent managers and it’s great to encourage engineers to manage if that’s what they’re drawn to. However, it shouldn’t be the default career path.

When we push our engineers with leadership skills into management, we’re sifting those abilities out of our engineering pool. We can end up without the skills that we need to make our projects successful. 

Experienced engineers on the ‘technical track’ raise everyone’s game by modeling what good engineering looks like. They have the mix of engineering and organisational context that’s needed to drive projects that most engineers wouldn’t be able to tackle. And they talk to each other, ensuring that our technical decisions make sense even when looked at through a global lens. As new projects, new crises and new technical initiatives arise, we’ll be glad to have engineers who we trust to take on the responsibility.

Whichever path they may choose to follow, we should invest in our senior engineers and give them opportunities to learn and grow. 

Thanks to Joel and Robert for talking through some of this, and Ellie for working magic on it.