BA 52/52: How to manage multiple programs at the same time
As the name implies, Technical Program Manager, it does become necessary for us to lead more than one project or in some cases programs at any given time. Is that humanely possible? Yes and No.
As the name implies, Technical Program Manager, it does become necessary for us to lead more than one project or in some cases programs at any given time.
Is that humanely possible? Yes and No.
Have I ever managed multiple programs in my career? Yes, numerous times.
Here is the secret — don’t multi-task. Ever.
No human can multi-task. Unfortunately, we have a single threaded processor called a brain. It’s great at holding numerous thoughts, information, and processes at any given time but can focus only on one thing at a time. What it’s really great at is context-switching. That is how the best of the TPM manage to work on multiple projects/programs at the same time.
‼️ Every software development project has a standard set of activities:
Identifying the work to do (meetings, slack chats, engineering discussions, etc)
Estimating and planning the work identified (project plans, engineering documentation)
Doing the work (design meetings, engineering working sessions, roadblock issues, coding etc)
Verify and deploy the work (QA, testing, fixing failed tests, release notes)
Communication to stakeholders (status reports, exec reviews, steering committees, demos, etc)
TPMs throughout the project duration are driving, but not limited to, meetings, comms, documentation, project artifacts etc throughout the working week centered around the above activities.
Here are a few strategies that I have developed to get good at context switching between projects and programs as a TPM:
Reactive Switching — this is the simplest method where you react to the project that needs your attention in the moment or has a deliverable due. You will be very interrupt driven and unable to do any advance proactive management. This works great when you are clear on the project scope and the scope itself is limited. If you have any 0 to 1 projects in the pipeline, you will be quickly overwhelmed and struggle.
Focused Switching — in between attending to meetings and comms for all your project, you prioritize one project every week to focus on with your free cycles. What this does is free up those cycles to do deep focused work on a single project with limited context switching. This works great when you have one or two big project that needs constant attention.
Scope Driven Switching — Identify the project with the largest or most important scope and focus your open cycles on that first as well as your teams. If possible, move all non-essential projects or programs to default keep alive, as in, commit no new scope beyond maintaining existing code base while other priority projects are ongoing.
The main point here is to recognize your own limitation and plan to work with your single-threaded brain instead of stretching it out of its capacity. Plan ahead as much as you can, prioritize the right projects and tasks, focus on your proactive cycles and manage your reactive cycles with agility.
As with any project management role, priorities can change quickly and you need to continuously review and update your plans based on new information and requirements.
The most projects I have ever managed during a single year was at Apple during iOS 10 when I was the lead TPM for:
Expanding 2FA for all iCloud Users.
Apple iCloud Advanced Data Protection
iOS Home App v1.0 (App only)
NetApps — collection of Stock, Calculator, Weather apps.
Apple Pay on Mac, Apple Pay on the Web, and Japan release (Client side only).
I leveraged the Scope Driven Switching to survive that brutal and most rewarding year I had at Apple. I worked with my EM partner to freeze the scope of NetApps and put priority ordering on the remaining projects.
Even the best of the TPMs I worked with, mentored under, and reported to never multi-tasked. Their secret was mastering the art of context switching. They always knew when to focus on what project — context switching with agility was more important than doing everything everywhere all at once. How did they stay on top of it all?
One of my Apple mentors kept a journal of everything they did in the day and reviewed it at the end of the day to pull out the important bits and todo items for the next day and week. This was a reverse todo list. Instead of a todo list, they looked at what they accomplished in a day and drove insights from that.
Another EM swore by the bullet journal method and added bespoke additions. They were extremely disciplined about this. Other people walked around with laptops. I never saw this person in a meeting with anything except their notebook and pen.
Another TPM I worked with kept a Google Doc for every project they worked on where they kept adding information about said project as they received it including important meeting notes and other information. This project journaling (maybe a post on this later in 2023).
Another EM I worked with kept mindmaps of all their projects. This was by far the most novel approach I saw to managing multiple projects. Some of the nodes on the map were risks, blockers, progress, milestones, important notes, among others.
Hope this helps to give your some foundation to build your own strategy for dealing with multiple projects and programs.
Last thing, and by far the most important thing, if you feel overwhelmed at any given time, discuss it with your manager and figure out a resolution. For me at Apple during that crazy year, I kept my manager aware of which project I was not going to pay attention to this week so they knew that if I missed something, it wasn’t incompetence but rather an unfortunate consequence of being stretched thin.
Until next time 👋!
-Aadil
How was this week’s newsletter?
Hi, Aadil, truly amazing to see you churn out all these posts with live experience and meaningful insights through the year. Thank you for sharing and Happy New Year!