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...
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.
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:
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:
By the way, these are all mostly based on real case studies we gave here in Taro! You can watch them here:
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:
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?