How can I come up with big initiatives, especially those at a Staff level?

To "set the stage" for my answer, I have some thoughts around what a Staff level project looks like here: "What are the common themes behind how engineers at Big Tech reach Staff+ levels when it comes to their project execution?"

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: "I've been on a lot of teams and wondering if I'm thinking about teams correctly."

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 Instagram

Related resources:

• [Case Study] Building A Meta Internal Tool To Empower An Entire Org: Staff Promotion Story
• "I would like to get more clarity on what a Staff-level project and execution look like."

Alex covered a ton, I can’t hit a lot else, but will mention this: In my experience and in a ton of examples in Larson’s Staff Engineer book… a “Staff project” is about 50/50 in promotions. Looking for such a project, and setting your sights on it, could end up not having as much impact and visibility than other cross-org or company programs you could set up, or work you could do. Focusing on a “big bang” project isn’t necessarily Staff behavior, doing the really challenging work that others won’t or can’t, seeing around corners, and making everyone better are. I know you didn’t say this would be all you would do, I’m just saying that if you’re doing everything else, and getting deep knowledge of product and team, a project opportunity may come up. If you are focused hard on finding a project you may not be doing everything else.

Alex and Lee have great thoughts, and I'll add some on top of those.

All staff engineer promos lie on a spectrum

• from, a deep tech contributor that solved a (or two) very hard problems
• to a proven lead of a big team, advancing the team over a long time horizon

What is a hard problem and where to find them?

I'll throw some examples, see if you can notice the patterns

• one liner in the mind of an org lead: "we have a reliability problem", "our subscription churn numbers look high". Just one line. No more. If you see that nobody can't articulate what the problem is further, forget solution, that's a potential problem. Anyway, talk to your leads, see what bothers them, volunteer to take on challenges. Albeit many of these would be risky problems to pursue without impact, but that's what a staff engineer does: entrepreneurial in approach, risk taker but also knows when it's time to move on.
• big top-down project, are you suited?: compliance, business critical and deadline projects are best for delivering impact and less risky. But they're often the most sought after too. So, how can you position yourself to be the lead? Be curious, participate cross-stack cross-team, build surface knowledge level of everything and deep knowledge of at least one portion of overall stack.
• what does the business need?: if your org doesn't have a "busy" charter with proven/low-hanging fruits, you need to become an entrepreneur yourself. Figure out how you can impact topline metric of your org (revenue/users/clients): brainstorm and collect ideas from product managers, EMs, UX, data science and your partner teams how you can create positive impact on your business. List down all the ideas; sort them by a function of effort, confidence and impact. Pick top 5 and voila, you have a strategic roadmap. Convince your leadership to fund it, execute on it and that's your staff promo.

These are some generic patterns, but each org and situation is different; and sometimes there's no bandwidth to do any of this (you're stuck doing someone else's staff projects). Patience and diplomacy with your manger is the answer there.

Good luck!