Beyond Staff Engineer
Some call it "Senior Staff", some "principal", others "technical director", but what comes after Staff Engineer? What are the challenges and toolset to handle higher complexity across a larger org?
20 months ago, when I accepted a job as a Senior Staff Engineer, I had no idea what I was getting into!
I thought to myself:
Sure, I’ve been a Staff Engineer before; how hard could the “Senior” part be?
As it turns out, very! 😮
Before taking the job, I thought Senior Staff would be like Staff but more! This is what I was prepared for:
More people to serve, more organizational surface to cover
More technologies to master, and at more depth
In theory, this model is ideal. In practice, it misses a few important nuances and can easily lead to feeling overwhelmed.
Before unpacking Senior Staff Engineer, let’s have a look at the regular Staff Engineer role because as we’ll see ambiguity is a theme in both roles.
The role of Staff Engineer
The term “staff” is used in the military to promote great soldiers as role models without giving them extra command and control responsibilities.
Staff officers assist the commanders in planning, analysis, and information gathering. The commanders have authority and accountability over their subordinates. Staff officers don’t.
The tech industry sometimes refers to the Staff Engineer role with alternative names like Principal Engineer (e.g., Amazon or Microsoft) or Tech Lead. But the common part is the same: it is an IC (individual contributor) role without management responsibility over people.
Promoting the best engineers to management positions is not necessarily productive or desired (few examples from ChatGPT). Modern career ladders acknowledge this fact and provide an alternative between focusing on people or technical responsibilities:
In a career ladder, the change in title is often coupled with a change in expectations and impact. Staff Engineer is not “more engineer” than Senior Engineer but adds a different dimension as we discussed in the previous article:
Just like their military counterparts Staff Engineers:
Serve as role models for other engineers
Act as trusted advisors for engineering leaders
Have no direct reports and mandate over people or product
Not every “commander” needs a “staff”. Patrick Kua defined 5 archetypes for engineering managers, some of whom are technical enough to lead their area without needing a Staff Engineer to act as a trusted advisor.
However, when the engineering managers are responsible for a larger organization, they often have less time to spend on the tech part. As a result, they end up with a more abstract and outdated view about what’s going on at the technical level. This technical gap is something that the Staff Engineers can perfectly fill.
Unlike frontend, backend, mobile, or data engineers, the role of the Staff Engineer varies depending on the needs of the organization and potential of the individuals.
It is not surprising that there are at least 4 archetypes for Staff Engineers (some count 6!):
Right hand: borrows the authority of the leadership to make technical decisions
Solver: is very deep in a particular technical area that spans across multiple teams
Tech lead: acts as the technical representative of a large team with complex solution
Architect: designs technical solutions in relation to user/business requirements (note: I don’t believe in the value of this archetype, but that’s the story for another post)
Let’s switch gears to the level that comes after Staff Engineer.
The Senior part!
Some companies call it Senior Staff, some call it Principal Engineer (yes, confusingly the same term is also used for Staff Engineer), while others prefer Technical Director.
Regardless of the title in a particular career ladder, we are talking about the level that follows another individual contributor technical leadership role.
If Staff Engineering is about technical leadership, the level after is about doing that at scale.
Senior Staff Engineer really takes its meaning in relation to the Staff Engineer role:
It is still technical, but different. You need to be more comfortable with the unknown. The higher level usually translates to fewer opportunities and time to work hands on with the code (except for the solver archetype). You need to be better at building trust, finding relevant information, verifying what you find, and streamlining the decision-making process. You must accept that you don’t have all the answers and instead work effectively with people smarter than you.
It is still a leadership position, but different. Your ideas often go through other hands to be implemented. You need to be more comfortable at delegating and building alignment through setting standards, coaching, mentorship, sponsorship and developing strategies.
It is still an individual contributor (IC) role, but harder. There are more interactions, expectations, and dotted reporting lines. A common complaint by Staff Engineers is that the lack of mandate over people slows them down. I call it “learning leadership the hard way” and have an upcoming post about all the tools that I have picked up over time to lead without mandate.
It is closer to C-level: You are expected to act as a bridge between the CEO; CTO, CFO, etc. and the engineers working at the leaf nodes of the organization tree (technical solutions). Sometimes you act as a representative for the developers, sometimes you act as an ambassador for the company leadership.
It still interacts with teams, but it is more ephemeral. One of the best ways to get a good understanding about the technology in use is to work with teams. Don’t let your level on the career ladder shield you from reality. Personally, I dive deep into 1-2 clusters (50-200 people) every 2-4 months. This allows me to get to know people I’m supposed to serve, but also work closer to the problem areas. It is hard to make an impact without having a good grip on the technical solutions. So far, I haven’t found a better way than working closely with the teams to gain first-hand experience with technical capabilities, limitations, requirements, and how they fit together. As a bonus, my temporary involvement with those teams allows me to see the big picture and cross-pollinate best practices.
It is still a strategic role, but over a longer horizon. When I was a Senior Engineer, a good day meant that I released good code. When I became a Staff, I had less of those days and instead the definition of good day changed to taking a step in the right direction towards a quarterly or yearly objective. As a Senior Staff Engineer, I rarely see the immediate impact of the initiatives I’m driving. It feels more like building a staircase than climbing a step at a time.
There is still autonomy, but more. Senior Staff Engineers have more autonomy than Staff Engineers. You need to be better at managing expectations, juggling tasks, and your energy to have a sustainable impact. One of the things that helped me to communicate my accountability is to have an open TODO list and calendar visible to everyone at the company. I’ve been taking notes to share about that experience and how it helped me manage expectations, as a side effect!
Communication is still important, but different. You spend more time in the room with upper management. Sometimes you must talk about complex technical topics to a less-technical audience. Other times, you must break down high level decisions to actionable technical directions for teams and individuals. And you must do all of that on a scale. The sheer number of people in my network is easily 10x the number I had to support as a Staff Engineer. At this scale 1:1’s, slides or meetings don’t work as effectively.
Writing, videos, delegation, and temporary task forces are a few ways I handle communication at scale. In an upcoming Note, we’ll dig into a full list of the tools to lead at scale.
Your level difference is a higher risk: Senior Staff Engineer has no authority over Staff Engineers or Senior Engineers. In Senior Engineer to Staff Engineer I mentioned that the level difference can cause confusion and jealousy. That risk is even higher for Senior Staff Engineer because now you have other leaders (Staff Engineers) below you. Leadership skills are powerful, yet hard to measure. My advice is the same: this higher level does not have higher authority, but higher responsibility and requires servantry. Your impact depends even more on the other engineers who are closer to code. You need to be service-minded and put the interests of the other engineers and the product ahead of yourself. Being transparent about your extra responsibilities can help diffuse jealousy and misunderstanding to some extent.
You’re closer to “business”. You will be closer to how the money is made and are expected to fit the technical solutions to business problems. You get used to reading the numbers and interpreting it to technical improvements. Service levels are powerful tools to connect operational data to business insights. This is my current engagement.
That’s a lot, but that’s not all. As you can see, there’s a theme here: if Staff Engineering is about technical leadership, Senior Staff Engineering is about scaling that skill over a larger org, longer time horizon, and wider technical portfolio.
Examples
Let’s dive into some examples from my own career.
I was responsible for migrating the infrastructure behind the face of Discovery Plus a few years ago. The stakes were high, and many things could go wrong.
That program required tight collaboration across 5 teams (old infra, new infra, frontend, edge, QA). I was fortunate to work with a seasoned TPM. Together, we managed to pull this off in 6 months. That’s the kind of initiative that Staff Engineers should be able to drive multiple teams, in a few months.
As a Senior Staff Engineer, I have been involved in completely diverse types of initiatives that span anywhere from non-technical (launching our engineering blog), to semi-technical (writing strategy), to very technical (rolling out service levels across a large organization).
I’ve mentored enormous potential, sponsored staff-level initiatives for senior engineers, and helped shape our recruitment process and career ladder. A substantial portion of my time goes to synchronizing across the org, yet I must find time to work closely with the engineers who do the main chunk of the work.
However, the size of the organization (1600 people) is so large that I cannot afford to visit everyone in every hub on a regular basis. Writing and creating videos have helped to scale myself across to scale my initiatives.
Objectively, I spend less time coding than coaching.
My role enjoys more visibility, but it comes with heavier responsibilities.
And the definition of a good day? I have none! Most of my tasks are long running across a quarter or year:
A good quarter is when we are on track executing a strategy and the engineers I serve have grown in their skills, careers, and passion.
A good year is when we have increased efficiency and effectiveness solving business problems.
Yeah, it sounds fluffy. But there’s no better way to sum up the wide range of challenges and impact at the high level.
The definition of fun changed. When I was a senior engineer, I loved working only with computers: they're logical, quick, accurate and predictable. Humans are emotional, slow, inaccurate, and have their own agenda.
Now I enjoy connecting a large number of people and computers.
The learning curve has been steep (like when I was learning React) but it's more rewarding because as it turns out most engineers either don't want this career path or don't know where to start.
The tech lead section of my newsletter is primarily targeting the latter.
The [updated] model
I hope by this point, it is obvious that my initial mental model was wrong. Unless you have superhuman abilities (I don’t) or crazy IQ (I don’t), it’s not a realistic expectation to be deep in all technologies across a larger organization.
There needs to be a trade-off. The sweet spot varies depending on the needs of the business at different times.
20 months into the job, this is how I see the difference between the role of Senior Staff Engineer in relation to the Staff Engineer:
We all have the same number of working hours, and it is up to us how we spend that time. Some become deeper in a few key technical areas while others cover a larger organizational surface. The “senior” in the title does not mean more years of experience. After all, “year” is fundamentally the wrong unit of measurement for experience.
The “senior” part carries more expectations, larger scope, and longer time horizon. This requires a different toolbox to deliver higher impact, and at scale.
I already talked about writing and videos. In a future article I will share my notes about all the tools I’ve picked up along the way to deliver impact across a larger organization without being burned out.
Conclusion
There are a lot of similarities between Staff Engineer and Senior Staff Engineer. The differences boil down to the size of the organization, technical depth, and time horizon to drive impact.
If you are looking to grow your career beyond the Staff Engineer level, you may need to focus on scaling your current toolset and picking up new methods to increase your reach and useful bandwidth.
🟢If you are curious, have a growth mindset, and are flexible, you’ve got this.
🟠If you take this role for the prestige or pay, you’re in for a tough ride
🔴If your goal is to move away from code, please stop! I have an upcoming article about Ivory Tower Staff Engineers and the damage they can inflict on a scale!
