“I don’t know what’s next in my career” is a sentence I hear frequently from senior engineers.
In fact, I hear this question so frequently that I decided to write this series of articles to address it.
When I ask those senior engineers how they have approached their career planning until now, what I hear is “I thought if I just worked harder and wrote more code, eventually someone would notice and I’d get promoted to staff engineer.”
Unfortunately for so many senior developers, this type of thinking is a major misconception on so many levels. Just writing more code isn’t going to get anyone promoted. Just waiting to be noticed isn’t going to get anyone promoted. Also, there is more than just the individual contributor or managerial path as possible career paths for engineers. And finally, getting promoted—like other forms of external validation—shouldn’t be the ultimate goal in anyone’s career, because it’s not fulfilling.
In this article, I am making a recap of the most realistic career moves from the senior engineer position. I’m dividing the possible moves into the four categories from the diagram. For each category, I will cover what it’s all about what it would require to get there.
- Staff Engineer => Lead or Principal Engineer
- Architect => Senior Architect
- Senior Site Reliability Engineer => Staff Site Reliability Engineer
- Senior DevOps => Staff DevOps
- Specialist => Senior Specialist
The first and most logical route for a senior engineer is the individual contributor career path. This means, sticking to the pure technology path and growing into it.
There are several ways this can go. For example, most companies have the next step of staff engineer after the senior position, which later pipes into a lead engineer or principal engineer position. The trap for a senior engineer is to think that just doing more cool projects and producing more code will lead to a promotion.
That’s the most common misconception I find in seniors. Becoming a staff engineer, and later on, principal engineer, requires that one not only has rock-solid technical skills and in addition to that, solid communication skills and relationship skills.
A staff or principal engineer doesn’t just produce code and tech assets alone, he has to influence teams and people in his own area and in the surrounding areas. Andy Grove put it better than anyone else in his book High-Output Management: staff and principal engineers as middle managers because their output is not measured just by what they produce individually, but by the sum of the outputs of the organizations and people under their influence.
Specialized software engineer
One could also decide to do a side move by specializing, for example by becoming a payment or banking engineer, a geographical information systems engineer, a chemical industry engineer, and so on.
Those specializations often require learning about a particular domain of knowledge. With a higher specialization, one might become rarer and more expensive. But the flip side is that often those specialists end up cornering themselves into the domain knowledge they’ve picked, their skills slowly become obsolete, and they don’t see a way out. This risk can be mitigated, you should read my other article about how to keep tech skills fresh while having a full time job.
SRE / DevOps
One specialization that’s hot at the moment is SRE, or Site Reliability Engineer, which is software engineering applied to the domain knowledge of infrastructure and distributed systems.
And unlike other specializations such as chemistry or other hard sciences, the chances of ending up cornered in an SRE path are small. Something similar would be to become a DevOps.
Finally, the individual contributor route can also go the way of becoming an architect, either a software architect or a systems architect. The architect differs from the staff and principal engineer route: the staff and principal engineers make sure that things work correctly, whereas the architects look after how those things connect and fit together.
Becoming an architect also has to do with having increased communication and relationships skills, on top of solid tech skills, as generally, architects have to deal with larger groups of people across multiple teams and organizations.
Resources to go further:
- The difference between software architects
- Engineering Manager => Senior Engineering Manager => Tech Director
- CTO at a small startup (initially a team of 10 or less)
The next option in line for senior engineers is to go the management route. That’s often the only option that some people consider, mainly because it’s sometimes the only path that their companies offer as a career progression and as recognition.
But be careful there. It’s not because you’re good at writing code that you should become a manager. Management is a whole different ball game, and what might seem like a promotion is in reality more like a change of career.
When you become a manager, your inner reward value shifts. As an engineer, you used to feel reward based on things you directly produced, and as a manager, this changes into feeling reward from the work produced by the people and teams who report to you. This requires an internal rewiring, and that’s not for everyone.
If you feel that management is calling you, then definitely give it a shot. You can still revert to being an engineer later down the line if you figure out that management is not for you.
Often, from a senior developer position, you’re going to enter an engineering manager position, and later on, you would grow into a senior engineering manager, a director of tech or director of software, and so on.
The one limitation that you’ll find in growing and getting to the next level is that the number of available management positions decreases logarithmically: there is often one engineering manager for 6-10 engineers, then one senior engineering manager for 4-8 engineering managers, and so on. Therefore, your promotability and growth will be limited mainly by the size and functional needs of the organization you’re in.
An alternative within the managerial scale is to branch out and become the CTO of a startup.
Although, keep in mind that if you’ve ever only had experience as a senior engineer, or maybe as an engineering manager, then you won’t be able to pretend to be the CTO for a large start-up or even a scale-up.
But CTO of a small startup, initially a team of 10 or less, and then growing your skills as the company grows, is a realistic option.
Resources to go further:
Business / Process
- Product Manager => Senior Product Manager => etc.
- Technical Program Manager => Senior Program Product Manager => etc.
A less sought-after path by senior engineers is the one of a product manager, also called product owner. Well-structured engineers can make excellent technical product managers, granted that they can develop adequate skills such mostly in communication and process management.
The risk with engineers turned product managers is that they want to tell the engineers on the team HOW something should be implemented when the role of a product manager is just to tell engineers WHAT to do. If you’re an engineer transitioning to a product manager, just be aware of it and can put safeguards in place to avoid falling into that trap.
The career progression from a product manager is to become a senior product manager, and from there, a director of product and later on a VP of product.
At the level of director or VP of product, the day-to-day job is very close to the one of director of tech or VP of tech, except that the headcount is smaller and that the content and domain to manage are not about tech but the industry expertise of the product at hand. Here when I say industry expertise, I mean expertise in things such as e-commerce, security, facility management, and so on.
Technical Program Manager
Yet another route is to become a TPM, or technical program manager. A TPM is responsible for coordinating and driving multiple projects that often span across multiple teams or organizations.
The most important tasks of a TPM are to make sure that the roadmaps are clear and communicated regularly, that dependencies are known of everybody and prioritized in the right order, and that the collaboration points between teams are working without friction.
Like for product managers, a TPM will have to develop strong communication, process, and relationship skills. Then a bit like the difference between principal developers and architects, the difference between product managers and TPMs is that the product managers will care about what’s inside of a team or org and what that org produces, whereas TPMs will care about how well the teams within a project are collaborating to deliver on something.
Resources to go further:
Business and Sales
- CEO at a small startup
- Solutions Engineer
- Sales Engineer
- Developer Advocate
If the pure tech route, the managerial path, and the product way aren’t cutting it for you, then there is still business and sales. Jobs in this area are the ones I know the least, which explains why this section is smaller than the others.
The first transition I want to talk about is being the CEO of a small startup. There are many startups whose CEO has a software engineering background, and we all have heard of those success stories, thus I don’t think I need to dive deeper into this one. As a career move though, it’s a rather risky one: the chances of success of startups are fairly low, and for every unicorn, there are thousands of failures.
Then, as someone with engineering skills, there are a few other jobs related to sales that one can transition to solutions engineer, sales engineer, and developer advocate.
A solutions engineer is someone who works closely with the sales team and salespeople, to discover what are the main problems that customers are facing, and act as a bridge between those customers and their needs, and the internal product teams.
A sales engineer is someone who meets with customers and presents them with technical solutions, often going the extra mile of customizing those solutions to make them fit the customers’ needs. The main goal of a sales engineer is to help the salesperson close the deal with the customer.
A developer advocate is someone who creates demos to showcase the potential of a product. It’s also someone who spends time writing blog posts, who presents at many conferences and events, and who makes sure that the user’s needs and feedback are being looped back into the development teams. To do this job, you need to enjoy social activities, spending time with people, and presenting.
Resources to go further:
I hope that with this article I was able to give an overview of all the possible realistic next career moves that are within the reach of a senior engineer, and that it will help you make your mind in case you found yourself stuck.
Did I forget a career move that you think is worth mentioning? Then drop a comment below to help others as well!
I have other articles that I’m preparing around the theme of career development in tech, including how to think about career planning when you’re an engineer or engineering manager, and also how to develop soft skills in order to match the next career levels and get promoted. Join my mailing list below to be notified.