How to align multiple cross-functional stakeholders & keep them updated?

Feels like an over-reliance on standups to keep people up to date. Standups are best effort, and intentionally short, so it's not an effective way to get a message out.

I like the idea of "weather reports" which the TPM sends out as a high-level pulse on the project. On top of that, I think it's also worth identifying particular workstreams or areas where there needs to be more focus (some may call this a war room or perhaps an ad-hoc pod).

If the issue is serious enough, you should be getting the relevant engineers together and then providing updates in some written way, so interested parties can follow along (and keep folks accountable)

From my understanding, you're on a giant, complicated project with a loosely adhered to spiderweb of processes that aren't strictly followed, leading to stuff falling through the cracks.

I went through a similar experience at Robinhood, working on their spending card. The product was sort of a mess, but it did go out the door on-time-ish and overall, the product is not a disaster There was a process we used that I think may help you: Leads Weekly Sync. Here's how it worked:

• The project was split up into workstreams, similar to your pods. I was the leader of a workstream, particularly the waitlist for the Robinhood spending card.
• A very senior IC (for our case it was a Staff PM) drives a weekly meeting where the leader of each pod comes in. This IC was the overall project lead.
• There was a giant project document with a spreadsheet. In the spreadsheet, each workstream had a row and each column represented a week in the project's execution. The goal of the meeting was to add another column to the spreadsheet to capture the status of each workstream.
• During the meeting, each lead gave their update. They said if their workstream was red/yellow/green and described why. It was encouraged for leads to write this in beforehand to optimize the meeting discussion. If a workstream was struggling, the group would talk more about it and capture action items and alignment into the doc.
• After the meeting, the project lead collated all of the workstreams' information together and shared a public overall project update, posted into a big shared Slack channel. Things that aren't going well were called out in particular to draw people's attention to them, so they could chime in with something helpful if they wanted to.

You mentioned that your TPM had standups, but it seems like it's not as heavy and structured as the process I described since:

1. The TPM doesn't even attend all of them
2. When I think "standup", I think a lightweight 5-15 minute meeting. Our Leads Weekly Sync was essentially a standup on steroids and would take 45-60 minutes. We really wanted to make sure that all the nuts and bolts were working together, which is super important in a larger company like DoorDash or Robinhood.

This weekly sync was a major event, and it was a huge force keeping the team together for this very ambitious project with a tight deadline (I imagine your project is similar):

• All relevant tech leads attended it alongside EMs and even directors of engineering. For one of them, the cofounder Vlad showed up, and there was another instance where the VP of Product was there. This wasn't just some random standup you could just skip out on.
• The cool thing is because the meeting had so much star power, all relevant players were heavily incentivized to show up: It's crucial to look good in front of this audience to build your profile, scope, and performance/promotion packet.
• Because this meeting was a forcing function for all the major players, it was very good at producing alignment and preventing stuff from slipping through the cracks (which seems to be the case for your project).

If your project doesn't have something like this, maybe you can try proposing it? You can float it to your pod lead and EM and see what happens. Being the alignment champion on projects like these is generally good IC6/IC7 scope.

Thanks, Rahul!

I like the idea of "weather reports" which the TPM sends out as a high-level pulse on the project. On top of that, I think it's also worth identifying particular workstreams or areas where there needs to be more focus (some may call this a war room or perhaps an ad-hoc pod).

If the issue is serious enough, you should be getting the relevant engineers together and then providing updates in some written way, so interested parties can follow along (and keep folks accountable)

The TPM sends his "weather reports" to the entire company. He only reports high-level red/yellow/green status and doesn't provide details. Would it be weird for me to send my own "weather report" for only my workstream? Should I send mine only to the TPM, EM, pod lead, stakeholder team's POC, and stakeholder team's EM then? Would this offend the TPM, since this implies that his weather reports aren't sufficient? How do you hold folks accountable for scope creep? Is there a certain way I should phrase things? For example, the POC told me that some things were not needed, but I later discovered that they were blockers for my workstream. This delayed my workstream and stakeholders were surprised by the delay.

Separate comment to address all the follow-up questions:

The TPM sends his "weather reports" to the entire company. He only reports high-level red/yellow/green status and doesn't provide details. Would it be weird for me to send my own "weather report" for only my workstream?

Entire company scope is huge, wow. It would be very weird for you to do the same, but I think it could still make sense to publish your own sort of update. I would run it by your pod lead first; if they're already publishing an update, you can roll your section into theirs.

To help with this, here's my very in-depth thoughts on how to write an incredible project update.

Should I send mine only to the TPM, EM, pod lead, stakeholder team's POC, and stakeholder team's EM then?

This seems good to me. You generally want to over-communicate when it comes to this stuff. As these are all important people, make their lives easier by making your writing super succinct and impactful.

Would this offend the TPM, since this implies that his weather reports aren't sufficient?

If they're reasonable, no. You are operating at different altitudes. It seems like the TPM's job is to communicate very broad strokes, high-level status if they're sending their update to literally all of DoorDash. Your updates should be more targeted and in the weeds, calling out tricky nuance on your project slice that may be in danger.

How do you hold folks accountable for scope creep? Is there a certain way I should phrase things? For example, the POC told me that some things were not needed, but I later discovered that they were blockers for my workstream. This delayed my workstream and stakeholders were surprised by the delay.

First, I recommend this very in-depth discussion around dealing with unreasonable timelines, which are produced when scope creep happens.

In general, my main advice is to not take it lying down. Don't just let requirements balloon and burn yourself trying to get everything done regardless. Try to extend the deadline, reduce scope, bring in more resources, find a way to boost overall productivity - Something has to give when project scope increases.