Staff Engineer & TPM: A conversation about tech's two most unique IC roles
Post # 60 - Let's demystify tech industry's most unique & fascinating individual contributor roles and perhaps along the way give folks some new career paths to consider.
😊 This bonus post is being shared with both FREE and PAID subscribers given the unique topic of the post.
You are about to experience the most unique collaboration I have done to date. Two people who have been doing their respective roles for a long time, brought together through a serendipitous encounter will try to demystify the role of Staff Engineer and Technical Program Manager. I hope you find this post insightful and enjoy this collaboration piece with
as much as I did writing it.Onwards.
-Aadil
A Staff Engineer and A TPM Walk Into A Bar
Every large complex cross-functional product development team has a triumvirate leadership:
Product Managers
Engineering Lead
Technical Program Managers
There is plenty written about the product role on the internet, some really good stuff. I have written extensively about TPMs but I called in someone amazing to help me shed some light on a very unique engineering individual contributor role — Staff Engineer.
Introducing
, Senior Staff Engineer at Volvo.
Alex has been programming since 1999. Over the years he has worked at a wide range of industries while wearing different hats: PM, Front End, Back End, SRE and entrepreneur. He is a product-minded engineer who served as Staff+ in the past three companies and shares his learnings on technical leadership, growth mindset and software at
.When not writing code or docs, Alex vents his creative energy in pencil drawing and playing music. Currently Alex lives with his 2 kids and wife in Stockholm, Sweden.
Both the TPM and Staff Engineer role is a great recognition for many senior leaders out there that the career ladder for amazing technology workers doesn’t always have to lead to people management. Many people love and wish for a more senior and visible engineering role without direct people management.
The idea is simple:
We list some interesting questions about both roles
We answer the same questions for our respective roles
We post the answers to our roles to each other’s newsletters
Goal is to help
's technical readers become better acquainted with the TPM role and for you, my readers, to learn about the Staff Engineer role.I hope with this dual post, we share some of the excitement both of us have with our respective career journeys and for some out there, a new career trajectory for them to embark on.
Let's dive in shall we.
Could you give an elevator pitch for what Staff Engineering is about as a Staff Engineer?
The term “staff” comes from the military where a good soldier is set as an example without giving them any command or control authority. The role is pretty established at software companies like Google and Spotify as someone who has both depth and breadth in the technology and supports multiple teams.
Unlike ivory tower roles like “architect”, Staff Engineers are ready to roll up their sleeves and jump into code any given day of the week.
The term “Staff+” is sometimes used to refer to Staff Engineers and above. It depends on the company ladder and expectations at each level. When I use the term “Staff+” I exclude Principal Engineers because that’s a whole different league.
What are the most common confusions about Staff Engineering?
The role itself is vague by definition. There are at least 4 archetypes: Tech Lead, Architect, Solver, and Right Hand.
When the role is new to the org, people don’t know what to expect. Hire-promoting senior engineers as Staff Engineers to such an organization doesn’t help the situation either.
Staff Engineers don’t have any mandate over the product (unlike PMs) or engineers (unlike EMs);
They arguably have a mandate over technology, but the tech doesn’t listen or have an identity without the product. 😉In practice Staff Engineers spend a significant part of their time and energy to collaborate with the engineers and product.
The broad organizational scope and lack of formal mandate are the biggest source of confusion.
What is the main value proposition for Staff Engineering?
Staff Engineers are primarily technical leads operating on a longer time horizon. This involves strategic work but also setting standards, simplifying complex solutions, adding clarity and mentorship.
Personally, I don’t box myself in the title and certainly don’t represent a typical Staff Engineer. I’ve been told that I “lift the culture”, which is flattering but I tend to think of myself as an advocate of engineers and engineering. I do develop strategies, help with recruitment, spread knowledge about SRE (site reliability engineering) and serve as the trusted advisor to help leadership navigate tricky technical and organizational landscapes.
Not all organizations need Staff Engineers. You can go a long way with a well-oiled autonomous team with competent technical leads.
Where it really starts to get tricky is when a product spans across multiple teams, especially if those teams enjoy a good degree of autonomy and their reporting lines don’t match the product and technology. Here, Staff Engineers can help build alignment, share best practices, and define and implement a technical strategy toward a common goal regardless of the organization shape or technical landscape.
Coincidentally this is where I meet my TPM peers. If Staff Engineering is about technical alignment, TPM is about product alignment. The two roles have a lot in common but attack the problems from different angles which complement each other.
What is the difference between the TPM and Staff Engineer role?
There are a few differences:
Technical depth: Staff are deeper into the tech to be able to drive the solution. TPM is deep enough to understand technical obstacles and communicate a well-defined problem.
Time horizon: Staff operate across a longer time horizon (i.e. strategy) and need to think about maintainability of the solution long term whereas TPMs operate across a larger problem space and do what it takes to deliver great outcome with a controlled risk. I’ve recently written about how we tamed tech debt by investing 10% in payback. Technical Program Managers are more focused on risk, deliveries, and products.
Problem/Solution angle: Staff Engineer, as the name implies, roams in the realm of the engineering a solution while the Technical Program manager is heavier toward the delivery side and defining the right problem to solve.
What are the similarities between the TPM and Staff Engineer role?
There are more similarities than differences:
The scope: we operate across the org regardless of the boundaries of teams, clusters, etc.
The authority: we don't have formal direct reports. I call it “learn leadership the hard way” because without the mandate one needs to work hard to earn the respect and trust of the organization.
The soft skills: we heavily rely on the buy-in from engineers and product and we use a variety of techniques like follow-me leadership, delegation, negotiation, and influence. Clear and timely technical communication is key in both roles.
Company maturity: not every industry has these roles, but those who do usually have them both.
Technical competence: both roles are quite technical to be able to communicate with engineers and guide the solution.
The reporting line: both have dotted reporting lines to drive alignment across a large org.
Seniority Level: both roles are high up on the career ladder where you would expect lots of experience and impact.
What’s the best part about Staff Engineering?
The lack of authority over people is the best perk of the job, in my opinion. Staff Engineers don’t have direct reports, yet their impact depends on other people’s cooperation. One needs to learn leadership "the hard way" and be good in soft skills.
This lack of formal mandate also helps people open up in ways that they wouldn’t open up to their manager. Working relationships are not polluted with the risk of performance reviews, salary, or vacation approvals.
By the way, leadership skills just happen to be the only thing standing between many great senior engineers and their promotion to Staff level.
What’s the worst part about Staff Engineering?
The role is very rewarding when driving impact, but there are a few frustrations:
Balancing org-growth vs self-growth: Another downside is that there is less time to work with the tech and sharpen the axe. One of the main value propositions of the Staff Engineer is the engineering part, yet a big part of the time is spent on writing (strategies, documentation, etc.), architecture diagrams, and building alignment with various stakeholders. The technical skills can quickly rot if one doesn’t make a deliberate effort to keep up to date. Yet, it is the key to have the respect of the senior engineers and engineering leadership. So, the worst (or hardest) part is to find a balance between the two without having to sacrifice the work/life balance and overwork.
Dotted reporting lines: as the Staff Engineers roam around the org, it is quite common to come across impactful problems to solve. The dotted-report lines means that there are many stakeholders who want something done. I use an impact-mapping framework to prioritize my tasks based on impact/effort equation. I recently opened my TODO list across the org which helped me communicate my priorities. The results were fantastic, and I’ll write about it in the coming weeks in my newsletter.
Sole credibility: a lot of what technical leaders do relies on the collaboration of the group. One cannot take the sole credit for the success of an initiative. The impact might be large in scope but is usually less deep than pure individual contributor work on something tangible like a repository.
Setting expectations: The ambiguity that’s inherent in the role makes it very confusing to interact with some people. Hence, this post! 😄
How deeply do you need to understand the tech to be able to do your job effectively?
Staff is a technical leadership position, so pretty deep. The main difference between Staff Engineer and pseudo-Tech Lead roles is that we are expected to code or at least understand it without handholding. And we’re not just expensive coders; This ability helps build trust with the other engineers and ultimately contribute to our impact.
More importantly, Staff Engineers need to be great at systems thinking and system design. To use the right tool for the job, Staff Engineers need to be familiar with the latest trends in the industry. I personally have hundreds of “hello world”-type projects where I get my hands dirty with new technologies to be able to use it when the need raise.
How do you keep up with technology?
I’ve written an old post on that topic but that’s when I was an individual contributor (IC) and had much more time. These days I mainly read blogs, curated newsletters, books and listen to podcasts.
I’m a heavy LinkedIn user and have an upcoming article about how to set it up exactly right to serve as a free learning platform.
My main coding experience comes from my hobby projects and the proof of concepts (POC) that I do every now and then. I spend between 10-20% of my time sharpening the axe but it’s not sustainable and I’d like to spend more time on personal skill development to be able to be more effective at supporting my organization.
What kind of AI will deprecate Staff Engineering?
I do believe that AI will deprecate most cognitive jobs in their current form; When it comes to Staff Engineering, there are broadly 2 categories of skills:
Hard skills: Copilot and Code Whisperer already produce satisfactory results and from here it is only going to get better. Computer code is AI’s home turf. As a tool, it helps one developer achieve the results of an entire team, but I don’t think it will completely eliminate the need for engineers who can translate all sorts of human problems to technical solutions and validate it. Not in the short term at least.
Soft skills: AI has shown a fairly good ability to amuse and even influence us. But I believe there’s still a long way to go to be able to fully lead humans. In western philosophy, we separate the brain from the rest of the body. But there is a deep connection between the mind and our organic body with 5 senses. That is the kind of experience that is hard (if not impossible) to replicate in non-organic consciousness and body. That’s what I’m betting on my future.
That being said, if we see AI as a tool, it is very powerful, and I can already see it helping my role as a Staff Engineer. For example, an important part of my job is to bring clarity. I need to ingest lots of documentation and code. LLM (large language models) can accelerate that investigative process by an order of magnitude. It can also help me be effective in other parts of my job like producing technical documentation or system architecture.
AI will definitely make companies more efficient so they’re going to need less developers, less designers and of course less Staff Engineers. But I believe as long as we’re building products for people, we need at least some humans and that’s the niche I’m aiming for.
Will I be successful? Time will tell but my approach is adaptation, not fear.
What are the other roles you typically interact with and how?
My closest interaction is with the engineers and the TPD trio (tech, product, design):
I work with engineering leaders to implement the strategy and understand the execution side of the technology.
I work with the product managers to explore the problem space and bind the tech strategy to the product strategy.
I work with the designers to evaluate the technical aspects of implementing their design.
And of course, I work with engineers on a variety of surfaces from security and maintenance to re-architecture and monitoring to guide the technical improvement
Staff Engineers are known to have dotted reporting lines and I’m no exception. In fact, I have the least amount of face time with my direct manager who gave me the freedom to browse the problem space and make an impact where I can. A better question would be: who wouldn’t you typically interact with? And I’m not sure I have an answer for that! 😄
What kind of person thrives in this role?
Someone who is good at both hard skills (coding, system design, operations, etc.) and soft skills (technical communication, influence, negotiation, investigation, mentorship, etc.). Staff Engineering is a leadership role and the few things that make a good leader also makes good Staff Engineers:
Being organized and having a system to be able to run multiple parallel initiatives
Being comfortable with ambiguity and approaching the unknown in a methodical manner
Being positive and helping people see the light at the end of the tunnel
Building alignment and influencing an org larger than one’s formal circle of support
When does a company know that it needs Staff Engineers? When is it fine to use other roles that overlap in scope and responsibility?
The rule of thumb is — “if you don’t know what it’s about, you probably don’t need it”.
Staff Engineers are useful once the organization reaches a certain size and level of maturity and long-term thinking that requires depth and breadth. Having a Staff Engineer for a team of 6 engineers is an overkill. But it wouldn’t surprise me that half of the engineers in a startup are Staff Engineers due to title inflation and the growth mindset.
The key value proposition for Staff Engineers is alignment across a large scope and long-time horizon. Staff Engineers are not necessarily more technical than the Senior Engineers or whatever level comes before them on the career ladder. But they are leaders for sure.
It is also highly likely that the engineer managers are deeply technical and can cover the needs of their team, but when the org reaches 50-100 engineers who need alignment at the technical level, it’s a good idea to add a Staff Engineer and measure their impact in reducing wasted effort and engineering frustration.
Staff is not a silver bullet though. If the source of frustration is poor program management, a TPM may fit the bill better. See Aadil’s answer to this question!
What is your methodology to self-onboard when you’re new to a domain?
I’ve previously written how to onboard Staff Engineers effectively. I also have an upcoming post about it. Feel free to subscribe to my newsletter to get that post when it is out. To give a sneak peek it is about:
Having a prioritized list of people to meet & greet
Deep dive into the technology in use
Working with the TPM (or other leadership roles) to identify key obstacles and getting to work to build trust
What does your average day look like?
It depends.
Some weeks, there are many meetings due to a new product being conceived. Some other weeks, it’s mostly silent and I get to roll up my sleeves and work with the tech. Regardless, I usually try to keep one day completely meeting-free so I can read and do deep work. I also drop by the office 1 day a week for networking and onsite meetings. I’ve talked more about it on my post about Return To Office policies.
What path do you recommend to people who want to grow into the Staff Engineer role?
Will Larson’s staffeng.com is a great resource to learn about the role. His podcast guests are also great.
I also find Steve’s A Life Engineered channel inspiring. He’s a principal engineer at Amazon and shares many interesting tips about a high-level engineering career.
I know there are other books and resources, but that’s not something I personally had a need to consume so I can’t recommend. I read 5 books per year and am pretty picky about what I read.
How do people get in touch with you and follow your work?
Hey, it’s Aadil here again 👋.
Wow, what a post, am I right? 🤩 I hope you enjoyed reading Alex’s answers.
I would appreciate it if you’d share it within your circles or social media to raise awareness about the Staff Engineer role.
For me, working with an amazing Staff Engineer level lead can completely change the game when it comes to product development and delivering large complex engineering programs. They may not have the title but you may have already worked with someone like Alex in any number of your programs.
Do sign up to Alex’s amazing newsletter and it’s one of the few that I recommend on my substack.
Don’t forget to check my answers to the exact same questions for the TPM role on Alex’s blog!
Until next time 👋!
-Aadil
How was this week’s newsletter?
 | A guest post by
|