Taro Logo

What makes a staff engineer from a technical perspective?

Profile picture
Anonymous User at Taro Communitya year ago

I have about 5 YOE and trying to grow from Senior -> Staff engineer but noticing that the path is taking longer than I'd hope.

This is the case whether I try to speak to other companies and ask about interviewing at that level or try to grow within my own company.

Within my own company: Requirements unclear, seems to be more time based (just keep on shipping). Since we're on the smaller side, we don't have a clearly defined structure like FAANG.

Externally: Due to the YOE, usually discussion of Staff isn't even an option even though I think I'm doing Staff level work. In fact, they usually decline the idea before even having a chance to explain what I'm working on.

The projects I'm working on span the entire org (startup), I have multiple mentees, and org-wide impact. I will be honest and say that I don't think the projects I work on are necessarily insanely technically complex (not going out to millions of users, dealing with hyper concurrency issues, or needing to deal with large scalability issues), but they do have a large amount of scope and senior+ level management required to run them.

I think from the project management perspective, I have things nailed down pretty well.

So I wonder if I'm either missing...

  • YOE - Just some sort of arbitrary minimum that is being placed across the board for certain levels to be achieved
  • Technical expertise - I definitely admit that I'm not necessarily INSANELY technical. For example, I can admit gaps like: 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. Are things like this a requirement to be a staff engineer? To just be more aware or know right away how various systems like this are designed, without needing to do research beforehand?

I'm essentially trying to understand what my gaps might be, and the technical aspect is one I'm unsure about how relevant it is.

Would appreciate any thoughts, especially from Staff+ engineers, maybe sharing what they feel makes them a Staff vs a Senior and how much technical skills play a role vs other elements.



  • 34
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    a year ago

    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:

  • 8
    Profile picture
    Tech Lead/Manager at Meta, Pinterest, Kosei
    7 months ago

    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.

  • 5
    Profile picture
    Staff Eng @ Google, Ex-Meta SWE, Ex-Amazon SDM/SDE
    a month ago

    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?

A startup or start-up is a company or project undertaken by an entrepreneur to seek, develop, and validate a scalable business model.
Startups241 questions