What makes a staff engineer from a technical perspective?

I don't know how to design a concurrent document editing system like Google docs, or I wouldn't be able to write a live streaming service without reading up on the proper documentation and understanding better how those systems work.

Guess what: I don't know how to do that either! I'm 99% sure Rahul also doesn't. 😛

I actually think Staff is the level at where the mentality is inverted (maybe this is one of the mindset shifts you need to make to grow to Staff): It's less about what you know and more about your fundamental ability to dig into what you don't know.

I have seen so many L3 - L5 engineers (junior -> senior) focus on acquiring more knowledge:

• They don't know about blockchain, so they'll read up on that because it's hot.
• They don't know about short-form video, so they'll do some video-streaming coding tutorials because TikTok is trendy.
• They don't know about LLMs and ChatGPT is taking over the world, so they'll read tomes upon tomes of MLE blog posts.

I feel like this reactive "learning" is fundamentally shallow as acquiring knowledge isn't hard. Engineers aren't rewarded for being bigger Wikipedias than other engineers. Promotion is about behavior change.

Every L6+ (Staff+) engineer I have ever worked with on the other hand completely embraced their lack of knowledge, focusing on becoming holistic gap fillers instead:

• The org is really bad about fixing bugs and learning from them? I'll become an operations expert and completely revamp the entire oncall system.
• We can't ship anything because all our designers and PMs are arguing? I'll hybridize as a product manager and unblock us through expert communication.
• All the engineers on my team move like molasses because our internal tooling sucks? I'll temporarily abandon the feature work I'm used to doing and create a massive engineering efficiency workstream that adds sorely needed internal tooling.

By the way, these are all mostly based on real case studies we gave here in Taro! You can watch them here:

• [Case Study] Revamping Oncall For 20 Instagram Engineers - Senior to Staff Project
• [Case Study] Building XFN Alignment Across Multiple Orgs (w/ Staff Engineer Cat Chen)
• [Case Study] Building A Meta Internal Tool To Empower An Entire Org: Staff Promotion Story

Guess what: I don't know how to do that either! I'm 99% sure Rahul also doesn't. 😛

Just wanted to say this is correct 😇

Knowledge of technical systems is important as a Staff Engineer, but it's only part of the story.

Another (equally important) area of knowledge is the organizational system. In some teams, this may be more important than the technical. I consider this to be:

• Knowing what problems are worth solving.
• Knowing who you can loop in to help/advocate to solve those problems.
• Knowing how to frame the problem and solution correctly.

This is much more than just project management.

The technical leadership track is not about becoming more technically proficient in some stack, or knowing 3 more patterns, or nuances of your favorite languages compiler. Designing something important, and being able to manage dependencies, other engineers (and make their work better because you’re there) contributions, launch with clear metrics, and maintenance without a huge human cost matter much more than you, individually, designing extremely complex systems.

I will note that collaborative editors seem scary, and there are weird edges for sure… but most documents are written by one person. When there are multiple editors it is a few to a few dozen. I honestly don’t know what 500 people actively editing one document looks like, but that’s rarely v1. Ten in-flight edit operations with sane resolution mechanics is probably enough to get started. The scale for docs is a lot more about breadth (billions of documents) than concurrent editing of a single document. One of these is much, much harder than the other. And once you solve one for a smaller number of in-flight operations, scaling that may not be as crazy. Note I don’t work on docs, but imagine dispatching the 200 in-flight edits to different hosts in bundles based on nearness in the edit point, then recombining the results after these are all resolved, push that state back to clients, etc. I’m sure this isn’t how it’s done, but you don’t have to know either. You need to have common sense design skills for the domain you’re working in.

You listed 3 things you’re doing: Org-spanning projects Org-spanning impact (through projects or other behavior?) Multiple mentees

Ok. That sounds like seniorish behavior. Are you scaling mentorship so that other senior or mid level engineers are learning from you how to effectively mentor, and setting up a cross-team matching program to get more people mentored and mentoring? You need to scale yourself. 3-4 mentees is a lot, but priming 3 new mentors every 6 months, then moving on to teaching the original batch to teach others in a year or so means multiplicative impact. What you do by your own hand isn’t enough, you need to multiply impact through systems, programs, and elevating others to do what you can do.

With org-wide projects… that’s cool. Did you design it from the bottom-up? How much responsibility did you have for delivery, how many engineers’ efforts were you directing during implementation, how many course corrections did you make to stay on track, how many stakeholders did you keep informed on a push basis, etc? The project matters, but your behavior matters more. How a junior, mid-level, senior, staff(+) handle similar work is different. Considerations are not the same. How it never has to be done again, or made less painful happens at higher levels.

Years of experience is a poor metric, but some companies will gate on this if there’s no clear guidelines and more senior people to assess candidates for promotion. Have you asked for differences between you current behaviors and what a promotable candidate would look like? Have you asked where your manager thinks you are, and how far you have to go?

I will note 5 years is… a good start. I know folk have grown to staff quickly. These wunderkinds are not the standard. I worked in smaller companies for almost ten years, then worked another 8 or 9 years in FAANG before getting to Staff. While YOE is not a good proxy, I think you should be realistic about your progress. What opportunities are being gated by this promotion? What will be different if you get there in 1 year versus 3 years?