Should I try to take a lead on my own project or help another senior engineer on a larger project?

My immediate reaction is leaning "no" on this refactoring project and trying to come up with your own scope. Here's why I'm not too bullish on the rewrite effort:

• Refactors are hard to get right - First off, it's hard to measure the impact of a rewrite. It's not like adding more test coverage or shipping a new feature to production where there's a clear metric. Second, rewrites can easily get bogged down in things like rebase hell where the existing legacy code is still being iterated on (which can happen quickly and constantly at a big company like DoorDash), and you need to make sure you don't break it. Lastly, I feel like refactors fall into "shiny object" syndrome often, where it seems great on paper but less so in practice. It's a common trope where engineers at a large tech company will come up with some huge refactoring project "for the good of the codebase", and it's more of a play to get promoted vs. something actually beneficial to the codebase.
• There's already other engineers on it - Big projects are like startups: The earlier you join, the higher the rewards. How this works with projects is you will get more scope if you join early early and be able to call yourself a "lead" of more pillars on the project. I think if this project was currently a solo developer and you were being pitched on being the co-lead, it would be a lot more appealing.
• It's unlikely for a senior engineer to create multiple senior+ scope - So your goal as an E5 is to find scope on the higher-end of E5 or better yet, within actual E6 territory. I imagine some of the other engineers on this refactor are also E5, and are therefore looking for the same level of scope. It's just not likely this E5 engineer has made a project that has like 5+ engineers' worth of E5+ scope. The remaining work is likely to be base E5-level or even E4.

That being said, there are some reasons why you would want to take this on. Here are some questions to ask

• How much do you like the project lead? - If they're a great engineer and you genuinely love working with them, you might want to join the effort as a means of building social capital and deepening your relationship with this person. By helping them with their big thing, it increases the chance of them helping you with yours later on, either contributing work directly or just helping vouch for your ideas in meetings. If this engineer is on track to get promoted to E6 soon, they could also become a formal mentor of yours! Lastly, if you think they're just great, coworking with someone on a massive project is a super smooth pretense to set up a recurring 1:1 with them.
• Does this rewrite unlock feature potential? - I remember back when I was on Instagram Ads, there was a module that was so poorly written initially that we just couldn't extend it anymore, but it was literally powering like 25-40% of ads. If we wanted to run the slightest experiment on this ad type in Android, it would take months to put out the simplest UI change. So the ads infra team spent a lot of time, refactoring this entire module and not only did the code look better, it unlocked a ton of our product roadmap! So something to figure out with this rewrite project is whether it's just there to make code look better or is there some concrete feature/product work that is literally blocked until it's done. If it's the latter, this could easily truly be the highest-impact thing you can do.

I also have some thoughts on picking up a new project from the backlog:

• Projects are in the backlog for a reason - The thing for you to figure out is why. Are the projects in the backlog as they're genuinely lower impact than other opportunities or are they there because people haven't had the time/are lazy to fully evaluate the impact of these projects and they're truly diamonds in the rough? Or maybe they are high-impact, but it's the kind of work nobody likes to do - This scenario is really nice as you get to act as a gap-filler, the missing puzzle piece of the team.
• Improving oncall experience is a huge win - I really like projects stemming from empathy, so I just wanted to mention that making CD automatic instead of manual seems really cool to me. Something concrete I would do to gauge the impact of this project is how crappy the existing system is for the current oncall.
  • Ask people in oncall how much time they spend on it each rotation and how frustrating/error-prone it is.
  • If you have some sort of oncall retro, you can just ask there. You can also float the idea to see how excited people are about it.
  • Another option is to do some sort of survey, which you can extend to understanding people's perception of the oncall experience in general. This is risky though as engineers hate surveys.
  • When I think of manual process, I think of errors. Can you link the current manual process to actual production issues with your service, which would have been fixed with automation?