What makes a staff engineer from a technical perspective?
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.
Discussion
(1 comment)- 4 months agoTech Lead @ Robinhood, Meta, Course Hero
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:
22 Likes
