How to communicate internal delays to cross-functional partners?

How much of this should I communicate to our partner team's stakeholder?

Pretty much all of it but make sure to communicate diplomatically and not seem like you're throwing the E6 under the bus. You can just say something like "We're working through some tricky dependencies, so we'll be delayed by X weeks." Make everything about "We" and don't mention individual people.

Another E5 on our team told me that he doesn't like to air our team's dirty laundry outside our team, so he usually says everything is fine until the last week of the project when he suddenly flags delays. Is this a good strategy? Or should I be honest and upfront with cross-functional partners external to my team?

I'm going to be honest: I think this is a pretty bad strategy. Hiding issues is a prime recipe for disaster 99% of the time, and I have learned that the hard way repeatedly.

When it comes to unforeseen project blockers, my strategy is always to:

1. Communicate early
2. Communicate often

#1 is pretty straightforward, so I'll expand on #2. When I ran into a project blocker at Meta, my goal was to make sure that absolutely everyone was on the same page. The tricky thing is that important stakeholders like PMs, EMs, and TLs are super busy, so they can miss one-of updates here and there. So I would over-communicate:

1. Mention it in the working group project Work Chat thread
2. Make a Workplace post about it
3. Mention it in the working meeting (for every big project I took on, I made a weekly or bi-weekly meeting)
4. Mention it in the 1 on 1s I had with important stakeholders

I don't know how darkly political your organization is, but unless things are really bad, honesty should be the best policy. Sharing early and transparently brings the following benefits:

1. The partner teams might want to help - Maybe they finished their part early and have spare resources to shore up your end. You won't know this unless you tell them. Negotiating these resource loans is E6 behavior.
2. Dependencies don't fall apart - Maybe the project you're all working on together is actually required for your partner teams to build the rest of their roadmap on top of it. If this is true, delays seriously hurt them and everyone's performance reviews on the team. If you give them an early heads-up, they can plan around it by pulling stuff from their backlog or something.
3. Builds trust - People hate thrash. By communicating early, you are lessening thrash which is always good, especially at Big Tech. If you do it well enough, I'm sure you will build your reputation among the org.

Here's some additional resources to help with this:

• "Got hit with a last minute requirement on my project - How do I minimize the thrashy impact it has?"
• Alex's Guide To Effective Communication

Thanks, Alex! Plot twist: The E6 demoed a working end-to-end test of his infra code in a testing party with our team to show that his platform infra works. I told the TPM that my project is back on track. Afterwards, the E6 refused to share some of his code changes. He said one part was done in a hacky way, so he'd like me to give it a shot. Since this is a POC, I told him that a hacky implementation is fine. However, he still refused to provide that code. Now the project is delayed because I'll have to reimplement that piece myself.

I escalated it my EM with 2 options (I recommended option 1):

1. The E6 provides the code.
   • Pros: Project is back on track.
   • Cons: None.
2. I reimplement the code to unblock the POC.
   1. Pros: Unblocks the POC.
   2. Cons: The project timeline will slip a little.

My EM told me to go with option 2. He told me that the E5 expectation is that you unblock your project on your own. Does this sound right? Should I escalate to my skip? My skip had previously asked me why our team takes so long to execute and I had mentioned redundant work within our team. This is just another example of this. How should I communicate this to our partner team's stakeholder? In this particular case, I could probably get this project back on track by working an extra weekend, but not if this continues.

He told me that the E5 expectation is that you unblock your project on your own. Does this sound right?

This is technically true, but it feels like a cop-out response on the EM's side to avoid conflict. The real E5 bar is this: Unblock projects on your own properly. Duplicating work seems like a bad idea...

Should I escalate to my skip?

Yes, avoid wasting that extra weekend. However, a lever I would try to pull first if you haven't already is to have a meeting between the E6, your EM, and yourself. Make your case:

1. You don't have a healthy amount of bandwidth to mock up the infra again yourself
2. This is a POC, and the entire point of a POC is to prop up hacky code to validate (or invalidate) an idea quickly
3. Deadlines will be missed if the code isn't shared
4. We can always patch up the hacks later as a fast follow

Going to the skip on your own can make other parties feel like you're going behind their back, so I would try to resolve this locally ASAP (literally book an emergency meeting during lunch or something within the next 2 days). If local doesn't work, escalate.

Thanks, Alex. Miraculously, I was able to convince the E6 to hand over the code! Our TPM happened to attend our team standup, but my manager wasn’t there. In my standup update, I mentioned that we lost the code from the testing party last week, so the POC will be a little delayed since I have to reimplement it. The TPM said, “Wait, what?” The E6 said, “Let’s take this offline.” The TPM, however, said, “Wait, what’s going on? I want to understand what’s happening.” I said, “We’re missing part of the code from the testing party, so the backend engineer is blocked.” The backend engineer protested, “I’m not blocked.” The E6 said, “It’s a 5 minute thing to fix.” I said, “Oh, would you mind spending 5 minutes to take care of it in that case? It would really help out the POC project.” The E6 said, “It’s a 1-line fix. You can do it.” I said, “Oh, would you mind putting that in for us? It would take me a lot longer to figure out where that line goes since I didn’t write that code. It would really help us out and put the POC back on track.” At that point, the E6 realized that he painted himself into a corner and had a sheepish grin as he agreed to do it. I said, “Oh, when can we expect that by?” He agreed to have it that day. Surprisingly, he quickly followed up in our team’s slack channel as soon as he pushed his changes to my branch (it was not a 1-line change). My EM was completely useless, so I can probably claim that I unblocked this project on my own in my performance review. I assume the TPM put some pressure on the E6 though!