How to break the “senior engineer” career ceiling
I have met many engineers whose career progression seemingly stops at “senior engineer”. It happens for many reasons:
- They found their sweet spot. Many engineers simply don’t want to be promoted. They love the project they are working on and enjoys being the subject matter expert in their domain. All they want is more of the same.
- There’s no career path after senior engineer. Many startups or SMEs have a flat hierarchy and do not offer career progression in the traditional sense (i.e. via title promotions).
- There’s too much competition for promotion. Even in large organizations there aren’t that many tech lead or principal engineer positions available.
- They don’t know what they need to do to reach the next level.
I have taken the role of tech lead or principal engineer at a number of companies over many years. This post is a rendition of my thoughts and experience for those who are in the last category.
But first…
Disclaimer: the role of a tech lead or principal engineer can vary between companies and can change with time as a company faces different challenges. It’s a generalization of the expectation of the role, rather than the specific responsibilities you will inherit.
2nd Disclaimer: while tech leads and principal engineers are generally better compensated, it doesn’t necessarily make them better jobs. Just as there are many reasons not to become a manager, there are many reasons why you wouldn’t want to become a tech lead/principal engineer either!
Optimize your impact, not output
This is the single most important difference between a senior engineer and principal engineer.
As a senior engineer, you are an important individual contributor (IC). You are an important cog in the wheel that keeps the company running. Your success is judged on your personal output and your impact on the overall business.
Did you make the order service more scalable and handled the largest Black Friday traffic the company has ever seen?
Did you increase availability from two nines to three nines?
Did you cut the running cost for your services by some significant amount?
Or perhaps you delivered an important feature on time and on budget?
Writing more code or releasing more features alone doesn’t make you a better senior engineer. It’s about your ability to deliver a meaningful business impact through your execution. This is the change in mindset that will set you on your way to the next level.
As a principal engineer, your success is no longer judged upon your output, but your impact on the output of those you work with. You’re not tied to specific delivery teams and are often working with multiple teams at once.
As an IC, you have a wide range of technical skills — programming paradigms, languages, frameworks and tools. You are highly respected within the organization as well as in the wider industry.
As a problem solver, you are adaptable to different situations and can quickly identify root causes and formulate suitable solutions.
But most of all, you are patient, helpful and not one to judge others.
Remember, your job is to help others become better versions of themselves, not to make them become you!
You need to show, not tell. And use your power of influence to level others up. Help other engineers improve their decision making and their ability to execute effectively. This can be slow and challenging and 80% of what you do is communication.
But the impacts you create by helping 10 engineers be 10% better would be an order of magnitude greater than your maximum output as an individual. That impact is also cumulative and longer-lasting as you help more and more engineers level up.
It can be highly rewarding. As you’re entrusted to tackle the most challenging problems and can have a big impact on your organization.
My personal experience
Before transitioning to being an independent consultant, I worked as principal engineer or tech lead at a number of companies. Most recently as DAZN from April 2018 to June 2019. Within two weeks of starting, I realised that the biggest problem facing the engineering team was not our process or technology. We simply didn’t have enough engineers to execute our vision.
The recruitment team had struggled to hire anyone for months. Despite being a multi-billion dollar company, we were not live in our home market and engineers in the UK had never heard of us! And on top of all that, our reputation was tarnished. Our recruitment partner at the time targeted candidates overly aggressively.
The most impactful thing I can do for the business was to fix the recruitment problem. We needed to repair and rebuild our brand in the developer community, and establish a hiring process that delivers the skillsets we need.
To that end, I delivered 50 public speaking engagements between April and December 2018. I interviewed hundreds of candidates. I revamped the assessment criteria and established our interview process. I trained the first few waves of new joiners on how we conduct interviews and assess candidates. They shadowed me during interviews and were gradually integrated into the process. Until eventually they would carry out interviews independently and go on to train the next waves of new joiners.
I was fortunate to have the backing of the senior management. And working alongside my good friend Bruno Tavares and many others, we ramped up our Amsterdam office from 0 to 150 in under 12 months.
In the meantime, my personal output as an IC was the lowest it has ever been. And that’s OK, it’s kinda the point — you need to optimize for your impact on the business. Sometimes that means sacrificing your personal output as an IC.
There might not be a recruitment crisis at your organization. But as a principal engineer, you can maximize your impact in many other ways, for example:
- Drive adoption for better engineering practices that promote better automation and safety.
- Create tools that ease everyday pains that your developers experience.
- Help teams tackle the most challenging technical problems.
- Bridge contrasting practices between teams and bring shared values to your discipline — e.g. we value security over new features.
- Create a culture of learning within your discipline. Start guilds, book clubs, facilitate sharing/show-and-tell sessions, etc.
- Mentor other engineers.
Why you wouldn’t want to become a principal engineer
It’s often said that a good manager can yield both the carrot and the stick. As a principal engineer, you likely have neither!
You are not responsible for setting the teams’ priorities and have no line management authority. Your only weapon is your power of inspiration, to inspire others to want to do better and to follow your lead.
It can be very frustrating at times.
Behaviour changes don’t happen overnight. People digest new information at different rates, and you have to be patient. And sometimes the improvements you want to see need to make way for more urgent business needs.
You also need to be empathic to different people’s needs and constraints. The “right way” may be too far a stretch for some. It’s not your job to judge others for not reaching your lofty standards. But it is your job to help others improve, even if it means taking baby steps.
And the funny thing about pushing people out of their comfort zone is that you can only push it so far in one step. Try to force someone too far out of their comfort zone in one go and they’ll likely reject and resent you. Do it gradually and over multiple steps then you’ll be surprised how far they’re willing to go.
Wrap up
If all you want is to write code and be a subject matter expert (SME) on your system then you might not enjoy the role of a tech lead or principal.
In many organizations, moving into these roles require you to change from a do-er to an enabler. And your success is no longer judged on what you produce yourself, but how much more you enable others to achieve.
To succeed in these roles, you need to be more than a great technician. You need to be a strong communicator too. By that, I also include listening well, which is an often under-appreciated skill of a good communicator.
Most of all, you need to change your goal towards optimizing your impact on the organization, not just your personal output.
If you enjoyed this article, why not follow me and get even more?
I would appreciate your support on Patreon too. And in return, you can get direct help from me via a private Slack channel and 1–2–1 mentoring.
Hi, I’m Yan. I’m an AWS Serverless Hero and the author of Production-Ready Serverless.
I specialise in rapidly transitioning teams to serverless and building production-ready services on AWS.
Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.
Check out my consulting services.
Check out my new course, Complete Guide to AWS Step Functions. In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. Including basic concepts, HTTP and event triggers, activities, callbacks, nested workflows, design patterns and best practices.
Come learn about operational BEST PRACTICES for AWS Lambda: CI/CD, testing & debugging functions locally, logging, monitoring, distributed tracing, canary deployments, config management, authentication & authorization, VPC, security, error handling, and more.
You can also get 40% off the face price with the code ytcui.
Originally published at https://theburningmonk.com on November 6, 2019.
