To "set the stage" for my answer, I have some thoughts around what a Staff level project looks like here. To add more color to that, I think leading core team-level roadmap projects is sort of the bare minimum for a Staff engineer. The more interesting one is coming up with projects that span across multiple teams, which I'll talk about more.
First off, it is effectively required to stay on a team for a while (1.5+ years) in order to get to Staff. I talk about this more (alongside what it means to be E6) in this discussion from a senior Meta engineer, and the gist is that Staff engineers need to have vision across a long time-horizon and in order to spot Staff-level opportunities, you need to have this org/product intuition that simply comes with being in it for quite a while.
Before I give any concrete action items, I want to preface this by saying that there is no such thing as a path to Staff. Staff is inherently very foggy, and everyone has to find their own path there. If there was some playbook, then this promo wouldn't be so hard.
That being said, here's some things you can concretely do:
- Be hyper-vigilant of problems - It's really easy, especially in a big, fast-moving company like DoorDash, to just respond to things with "That's just the way it is." It's totally normal that my build takes 30 minutes; that's just how it is in a big company. Don't think like that - Don't be complacent! 30 minutes is an eternity - See if you can make it 10 minutes or even 3 minutes. That's how a ton of people got to Staff at Meta: They found these big structural problems that people were just hand-waving away and they came in, dug deep into the problem, and made the situation way better after a long-fought battle. I'm sure these problems are everywhere at a big place like DoorDash - Just keep an eye out for them, and you will start feeling their pain after you have been in your org for a while.
- Build relationships with other senior/staff engineers - Do this especially if they're working on similar projects. Pretty much any senior+ engineer/TL working with me on a project, I would have a bi-weekly or even weekly 1:1 with them. This sets them up so you can work through them later on, and it helps you find these cross-org problems mentioned above. Here's an example:
- I worked on the mobile product side for IG Ads, and a senior engineer on the mobile infra side (one who I really got along well with) would just ask me every once in a while, "So what problems are you facing shipping products?". They would listen to me and push to get projects solving those big problems on their team's roadmap. We both got points for XFN collaboration, I was happy because my team gets this new infra to ship products faster, and they were happy as they get to empower product teams, which was their team's entire goal as a product infra team.
- Look at your current projects and see if you can expand them - Expanding scope is much easier than creating scope from scratch (i.e. coming up with some completely new project and trying to convince 2+ teams to buy into it). This should be very natural to you as an infra team as your goal is to build APIs product teams can work off of. Is it possible that your infra can be extended to more product teams within your org or outside of your org? I have a concrete example from my past:
- The infra team created this new platform that allowed us to test new story ad formats in Instagram very quickly.
- The idea is that it allowed designers to ship their templates/animations directly to the IG app through a powerful back-end protocol that was then picked up and decoded by the client into UI
- They realized the infra could be applied to feed ads as well and expanded it there and to other ad formats within IG.