How do I manage multiple projects at once?

I once lead 3 multi-month projects concurrently and shipped all of them. This may sound impressive, but I frankly didn't do that much as lead besides being proactive on a few decisions.

• For project A (~2 months feature project), I had a pretty clear idea of how I wanted it designed but knew that polishing up the design takes too much time. When the project started, I gave technical ownership to a teammate and gave them my farily terrible initial design to improve. This allowed me to focus on non-technical parts of the project (logging, xfn) and coding up the Android portion of the project.
• For project B (~5 month feature project), I knew this was a critical and massively complex project. When my skip manager put this project on my plate and asked me who I wanted on it, I immediately stacked the project with the senior-most engineers. I knew that I wouldn't be able to efficiently juggle the xfn and technical specing across multiple projects, so I wanted engineers who could proactively fill the gaps I can't fill.
• For project C (~9 months infra project), I broke it down into milestones that we could easily drop and re-pick up. I also knew that feature work takes priority for my org, so I always worked with my managers on how we could sequence the projects. This project shipped late with 0 issues, but the 2 feature projects didn't ship late (so management was still happy).

For mid levels growing into a lead (my past self included), they often fall into a trap that to prove themselves as a lead that they need to do more. In reality, leads are simply held responsible for the outcome of the project: it doesn't matter how much or how little you did as long as you directly influenced the outcome. The most important outcome is: did the project ship sucessfully? As a lead, it's up to you to decide what success looks like. Success is a scale not a fixed target: you set the bar of what success looks like. If you try to treat it like a fixed target of doing everything perfectly (in terms of quality, speed, how much you did), everyone loses and all the projects will blow up in your face.

These are the guidelines I followed that I felt like helped me succeed at leading 3 projects concurrently.

• Prioritize the sequencing of each project based on impact (value/time) and time sensitivity. Work with your manager to figure this out and clearly communicate this ordering to xfn stakeholders. I like using weeks as a unit for how I'll use my time.
• The human mind is single threaded and in reality can focus on only 1 thing. Parallelizing simply means that you've broken down your work enough where your single thread is switching back and forth between projects. If your work isn't broken down enough, you need to spend more mental resources to switch between projects (switching more means that more time is lost to context switching overhead).
• Your time is valuable as a lead, but that doesn't mean you need to do everything. Proactively delegate to others so that you have more time available for you to use however you see fit.

Hope this helps!

Great question! There are many options here:

1. Ruthlessly focus and prioritize - Projects will usually have milestones on the weekly timescale, not daily. This means that the contract between you and stakeholders is that after every week, there is X/Y/Z% progress on every project. It doesn't matter how you get there, whether you do little bit of work across all 5 days (not recommended) or a lot of work on just 1-2 days (what I recommend), it's just important that you move the project forward. Is it possible to create focus blocks each week where certain days have deep work towards certain projects?
2. Delegate - I rarely had 100% (keep this 100% number in mind) leadership (i.e. actively chiming in on literally every single major decision) across 3+ projects back when I was a tech lead. I always chose 1-2 projects which were super important and for the remainder, I would put some talented L5 or high-end L4 engineer to lead a lot of the simpler stuff like giving the weekly status update or running data analysis. However, I would watch them like a hawk, thoroughly read their status updates, proactively give them advice, and sit in on major meetings. So it's not like I handed off the project to them entirely (i.e. I'm not at 100% leadership, but I'm also not at 0%), but I got to save a lot of time by abstracting away what was too easy for me. Is there an earlier L4 or even a precocious L3 you can delegate some of the work to? Check this out for inspiration: [Case Study] Mentoring Junior SWEs [E3] to Senior [E5] In Just 2.5 Years At Meta
3. Drop stuff - This is the absolute last resort, but it's often times the only option. I really doubt all 3 of your projects are exactly equal in terms of impact. If you see your projects struggling (i.e. missing deadlines, causing production outages) and the other 2 options aren't working, look into this.

I highly recommend this other discussion as well: "How to figure out what the most important projects are?"

This one's also relevant, but it's more about general context switching and not concurrent project leadership: "How to improve at multi tasking at work?"

Can be a good video idea.

It definitely is! When we create our productivity course, we'll make sure to include this as a section.

Jonathan gave a great answer. Here are some tactical tips that are related and might be helpful too.

Every morning, I face the question - "which one do I focus today?

One way to solve this is plan the day before. I like planning my day before since when I wake up, I want to dedicate the best of mind to the hardest parts of my work instead of prioritizing and planning. It usually takes about 30 minutes to schedule out the day ahead.

I try to give estimates by assuming my time would be equally divided among the 3, but its almost always unequally divided, meaning some product manager is let down almost always.

Estimation is a skill because we naturally tend to estimate as if everything goes well. I always add a 50% gap to my initial estimate and communicate a number closer to that since scope and dependencies can always come up and gives me a bit more room to work with.

It's natural to distribute focus across multiple projects unequally. There's always going to be some sort of priority ranking otherwise focus wouldn't be called focus. It's rare that all projects are equally important, so I'd prioritize according to the project's impact. If they are somehow equally important, my strategy would be to cycle through weeks of focus for one particular project at a time. Say week 1, Project A gets most of my focus, then B, then C, and week 2, Project B gets most of my focus, then C, then A, and so on.

If your PMs are being let down, I'd make a point to realign their expectations and communicate what changed compared to the initial expectations that were set up.

A lot of times, if I am focusing on project A for the day, if I get pings about project B a lot, then my focus keeps going towards project B, and I can't make progress on both project A and project B

If a ping is taking more than 2 minutes of my time to respond or is not urgent, I tend to avoid responding altogether and batch responses for those into a 30 minute chunk of time that I call "Comms" and respond to them all at once. I've never had anyone be frustrated with this. If somebody were though, I'd explain to them that my focus time is precious and that I'm happy to collaborate, but set up a meeting so you can have my full attention. Please treat my attention as a precious resource to use sparingly.