I coordinated 5 teams for 2 Months. Someone else did the demo.

The context

The project was a banking integration, the kind that touches everything. Five different teams had to work together to get one flow working end to end: the transaction data had to arrive correctly, get matched, and turn into something a finance team could actually reconcile. My product was where all of it had to come together and actually work.

For 2 months, that meant chasing down blockers between teams that didn't usually talk to each other. Asking the questions nobody else was asking. Untangling the technical assumptions that didn't quite match between two systems. None of that shows up in a changelog.

When it finally worked, one team demoed their small piece of it, the piece that fed into everything else at a company-wide meeting. Not mine. In that room, that's what people remembered.

Why the coordination work disappears

This isn't really about credit for its own sake. It's about what gets remembered when it's time to talk about what you actually do in a review, in an interview, in your own head when you're tired and wondering if any of it mattered.

The work that's easiest to talk about is the work that's easiest to see: a shipped feature, a demo, a number that went up. The work that holds everything together, the alignment, the friction removed, the decision that kept five teams pointed at the same outcome, doesn't have a natural place to live. Nobody writes a ticket for "prevented three weeks of miscommunication."

Where to start, this week

I didn't fix this by trying to get more credit in the room. I fixed it by changing a few small habits — nothing that needs a tool or a template:

3. Name what didn't happen. The bug that never reached a client. The rework that didn't happen because you caught a mismatch early. This is the hardest category to remember, because success looks like nothing happening — write it down anyway.

4. Say it once a week, briefly — as it happens, not after someone else's demo. Not a report, not a self-promotion campaign — one Slack message, posted in the team channel the same day it happens: "Unblocked the DSP2 flow this morning — there was a mismatch between our implementation and [team]'s that no one had caught." Said in the moment, this reads as normal visibility. Said the week after someone else's demo, it reads as chasing credit — same fact, different timing.

1. Keep one running note. A single doc, dated entries, nothing fancy. Every time you make a call, unblock someone, or catch a problem before it becomes one — one line, same day. Memory is the enemy here, not effort.

2. Write outcomes, not activities — even when you don't fully understand the technical details. You don't need to follow every technical exchange to document that you made one happen. On the banking project, I didn't understand every detail of what the two teams were debating — but I know I onboarded both sides, set up the recurring sync that hadn't existed before, and kept the conversation moving. That's a real outcome. The coordination is the work; understanding every technical detail underneath it isn't the job.

When it's stuck and you don't know what to do next

Sometimes there's no outcome yet to write down, just a conversation that's stalled. Teams talking on Slack, nothing moving, and no one sure what happens next. That's still worth documenting: not as a failure, but as a real, current constraint. "Teams A and B have been discussing X for two weeks with no resolution" is a legitimate line in your notes. It shows you're tracking the work even when it isn't resolved yet.

When a conversation stalls like this, it's rarely because the problem is unsolvable. It's often because no one has mapped where the information actually flows. Sketching the full lifecycle, what's received, where it goes next, who consumes it, where it ends, usually does two things: it shows exactly where the real gap is, and it reveals whether every team involved has actually accounted for their piece of it. You don't need to understand the technical content to draw the boxes and arrows. You just need to know who's supposed to talk to whom, and what's supposed to pass between them. Often, the block turns out to be that no one was clearly responsible for the decision ; not that the problem itself was hard.

The hardest part isn't doing this work. It's naming it out loud without sounding like you're inflating your role. The trick is to describe the function, not the activity. "I sat in on some meetings" is an activity. "I was the one keeping two teams aligned so nothing fell through the cracks between them" is a function and it's one people recognize, even if it's not in your job description.

A few ways to say it, depending on who's asking:

How to explain it, even when it's not technically "your job"

In a performance review or resume line:
"Acted as the connection point between five teams with no natural reason to coordinate, surfaced misalignments early and kept the project moving without needing to own the technical detail myself."

To your manager, in a 1:1:
"A lot of my time on this project wasn't building anything, it was making sure [team A] and [team B] stayed on the same page. Without that, we'd have shipped with a mismatch nobody caught until production."

To a teammate who wasn't in the room:
"I'm not deep on the technical side of this. My job was making sure the right people were talking to each other and that we didn't lose weeks to a misunderstanding."

None of these apologize for not understanding every technical detail. They name the actual function: finding gaps, keeping people talking, catching what falls between teams. That function has names in other roles, cross-team enablement, dependency management, stakeholder alignment and calling it that, even informally, helps other people recognize it as real work instead of "just helping out."

None of this requires anyone else to change anything. It's just deciding, going forward, that the coordination work gets a written trace, even if nobody else is going to write it for you.

If you're in the middle of this right now, doing the work that holds everything together while someone else gets the spotlight. It's a hard place to sit, and it doesn't mean you're doing anything wrong. Making your work visible matters at every stage of a career, not just when you're chasing a promotion. It's worth the effort even when no one's asking you to make it.

I'm working on more around this topic. Jow PMs make invisible work visible, without turning into a self-promotion machine. If you'd like the next piece when it's ready, you can leave your email below. No pressure either way, everything above is enough to start with on its own.

Get notified about the next piece

Your email is only used to send you this checklist. No spam, unsubscribe anytime.

I'm a product manager sharing what I use to spot and fix broken user journeys.
This is a free resource, no strings attached.
Questions? pmworkflowlab@proton.me