I recently became a staff software engineer at Google, 1.5 years after reaching the senior level. In this post, I'll share a few things that helped the most with my growth.
This is not a post about the "requirements" for a staff engineer. But I do want to start by emphasizing a few things that I find crucial for a staff engineer to do well:
Starting around the senior level, you'll inevitably face some degree of organizational politics whenever you try to work toward the next level. Hopefully, your organization isn't too toxic and the "politics" is no more than simply a different dimension of the puzzle you need to solve.
Ask yourself:
If you have these mapped out in your head and keep them updated, it makes reasoning about organizational puzzles surprisingly easier.
Read more about this in Chapter 2 of The Staff Engineer's Path by Tanya Reilly.
I've worked with a lot of senior and staff+ engineers by now. Apart from apparent gaps in skills and scope, one of the key differences in their mindsets is whether to make it a habit to take a step back.
Looking at the bigger picture is how you avoid tunnel vision and find the best leverage point to direct your efforts. The tricky part is there isn't always a bigger picture -- sometimes tunnel vision, or shall we say focused execution, is exactly what's needed to solve the problem. But the fix is simple too: just make it an atomic habit to always look for the bigger picture. The downside is trivial -- at worst you lose a few minutes thinking and maybe asking questions about it.
You could do something simple like asking the 5 whys. For example, if a proposal or an existing design feels odd, dig into why. 9 out of 10 times, there are good reasons and historical context behind it. But from those you might just find the idea for your next big project.
This one is straightforward. Be the bridge between teams, organizations, and functions. Make things flow between them. However, some of its nuances are not always appreciated.
Usually you become the bridge when you own the full scope: you know everything about the system so you become the natural representative when collaborating with interested parties. But there is a reason why you need bridges to cross a river instead of simply jumping over.
Take cross-org collaboration as an example. Different organizations usually have different and potentially competing priorities. They also have different planning and execution processes. Hell, they even use the same terms to refer to diametrically opposite things! It's very easy for a collaboration to get off on the wrong foot if everybody comes in with their own assumptions and biases. And when there are more than two organizations involved, the complexity compounds drastically.
So what do you do? Be tactful and thoughtful: identify key persons from each side and work offline with them on biggest contention points before meeting in larger groups, define and promote the use of a common vocabulary, organize in-person collaboration time to flesh out details that require a higher communication bandwidth, etc. These are just some examples and I don't really have a system for it. The point is that bridging often entails much more than merely connecting point A with point B.
Being the bridge is usually very rewarding while not requiring a lot of expertise and time -- you just need to be sincere and smart about it. It's one of the highest leveraged activities I'd recommend staff+ engineers to do.
Looking back at my time since I became a TLM, I often found myself in working groups where I was the person with the lowest level and years of experience. While it definitely feels scary and screams of imposter syndrome in the beginning, I now view it as a very positive thing to be the "dumbest" person in the room.
Much of "what you should do when you become XXX" is best learned by observing and mimicking a role model. This is especially true at staff+ levels where there is no more "standard path" and in generally less materials available. It is thus immensely valuable to watch how people at higher levels act in real settings.
There is almost always a reason you are in "the room where it happens". So be confident and cherish those opportunities. Note that you'd want to have a reasonable amount of interaction and make some contribution to the group if you want to stay in the room. And if you can continue pulling it off, you'll be growing at a faster rate than yourself might realize.
Growing in scope and responsibilities eventually shifts your day-to-day into an interrupt-driven pattern. But as an engineer you still need blocks of time to get things done. How? Protect your calendar, relentlessly.
There is no shortage of opinions on this. For example this is a more radical take that I recently read.
For engineers who are also people managers, this is a common rookie mistake. Good managers all get attached to their team to some extent. But we need to remember that our reports are not our peers.
You peers are your fellow staff+ engineers or equivalent functions. You collaborate the most with them, you will be evaluated by them, and you find role models among them.
This is not to say that you should stop caring about your team or growing them. It's just that what you spend time on with your team vs. with your peers will and should be different activities. It's important to keep the distinction in mind.
As my manager used to tell me, "the stars have to align" for you to become a staff engineer. In most companies, going above the senior level is usually not guaranteed even with a lot of YOE. Not to mention that the only constant is change -- strategies shift, projects get canceled, and people move around.
Staff engineers also operate at a longer time frame since we usually own larger projects. Some of these could easily be measured in O(years).
No two staff engineers are the same. A fast promotion is almost always not replicable (but learnings can!). In a world where not much is certain, the only certainty lies with growing yourself. The title is just one thing. Skills and experience matter too, if not more.
If you are like me and enjoy learning these kinds of things from books, I highly recommend The Staff Engineer's Path by Tanya Reilly mentioned earlier and Staff Engineer by Will Larson. P.S. I have previously recommended the latter on this blog (notes) but I find the former to be more practicable.