Becoming a staff software engineer
I have seen (and still see) quite a few senior software engineers struggling to reach staff software engineers (L6/E6 at Google/Databricks/Meta/etc.). This is especially frustrating for those who quickly got promoted to L4 and then to L5 (senior software engineer) and are now hitting a wall.
Note that my work experience is at Google and Databricks, so my definition of a staff software engineer (L6) is mostly anchored from these companies – keep in mind that there are companies with a different definition of staff (see levels.fyi) or without a staff level (e.g. Amazon).
There are a lot of differences between L5 and L6 (e.g. more impact, more leadership etc.) but the main one is that
- A L5 owns and delivers a large project (usually with multiple engineers involved)
- A L6 owns their domain meaning that not only they can deliver large projects in this space, they will build a long term vision for it and handle whatever comes their way
There are a few consequences of the statement above:
- It’s significantly easier for a manager to help someone grow to L5 than it is to grow them to L6. They may give you a space to own, but you have to prove yourself worthy of it – ownership is after all not a right but a responsibility that others have to agree with.
- Ownership is not something you can just claim, others have to agree with it – you have to build trust from others. This means not only constantly delivering projects with no oversight, but also having enough soft skills to gain others confidence in your ability to lead.
- You have to build your scope: frame problems, identify solutions and execute with some given constraints (e.g. staffing). A common complaint I hear from L5s struggling to reach L6 is that their team doesn’t have enough scope for them. While it might be the case, almost every area has enough scope for someone to reach L6, either by going deeper into the technical domain or going broader. Everything that’s important for the company is fair game when expanding your scope.
This sense of ownership is the biggest and most common gap I see in senior engineers who want to grow. One of the advice I used to tell people is that they should first find something they are passionate about – if you care about a domain, it will naturally be easier to own it (polishing all edge cases, advocating for it against other priorities etc.)
One way I used to describe a software engineer career is similar to a hike: at L4 you can hike by yourself, at L5 you can hike a hard trail leading a few people, at L6 you have to learn to climb – it’s a completely different skill you need.
Last but not least, the easiest way to grow from L5 to L6 is to have a good mentor and/or good peers (in addition to a good manager).
Hopefully this was a helpful advice – if you are a staff or above and have other tips, please chime in in the comments