When Communication Breaks, So Does the Work

Finding the balance between noise, silence, and real accountability

By Jed May ·

This week I was knee-deep in an API upgrade initiative. We’re moving everything over to v2, updating model contracts, tightening things up across the board. It’s a big project, so I partnered with our Business Analyst to knock it out. But I had enough context that, honestly, I just ended up writing most of the tickets myself. Felt like we had a good rhythm going. I used a word doc provided by a team that explained all of the new endpoints, contracts, everything. It was actually a decent guide.

When I finished, I was really proud of the details, strategy, the works. These tickets were written in a way that, I hoped, anyone would be able to take off and get things going.

As luck had it, I got was the first to work on them. I hit the very first endpoint, and of course, that’s where things broke. I couldn’t get it to work at all. I retraced my steps, double-checked the contracts, combed through logs—nothing. After way too many pings across different teams, I finally got the answer:

“Oh yeah, that endpoint? We retired it. Swagger’s the truth table now. Just go off of it.”

Cool. Thanks for the heads-up.

That moment told me everything I needed to know: the problem wasn’t the endpoint, it was the silo. A change that big, with dependencies that wide-reaching, shouldn’t be something you discover by accident after hours of debugging. And yet, here we are.

Here’s the thing: communication in software is tricky. Too much of it and it becomes noise. Teams/Slack fills up with “FYI” posts no one reads, emails go unopened, and everyone tunes out. Too little of it, and people are blindsided by missing endpoints and last-minute pivots. Somewhere between those extremes is a sweet spot—but we rarely hit it.

So how do you prevent the next surprise? My take is pretty simple: every team should have true product champions. Not managers, not PMs, but actual hands-on people who understand the work and own the responsibility of sharing critical updates across team boundaries.

Why champions?

  • Signal over noise. Instead of 20 people half-sharing updates, you have one accountable communicator per team. The rest of us know where to look when something changes.

  • Built-in accountability. If a dependency gets dropped and no one hears about it, the gap is obvious. Champions can’t hide behind the noise.

  • Recognition where it’s due. Good communication is invisible until it’s missing. Champions create space to recognize the people who keep the gears turning smoothly. Champions themselves are also recognized for the exceptional work done on projects that are fairly complex.

I’m not talking about standing up more meetings or adding layers of process. I’m talking about identifying the folks who naturally bridge the gap between builders and stakeholders, then making it their job to keep that flow clear.

Because Swagger might be the truth table, but it doesn’t explain why something changed, or who should care. That still requires a human voice.

The endpoint I ran into this week wasn’t the end of the world; I just had to pivot and send the whole root object instead. But the hours lost chasing down an answer? That’s the real cost of silos. And unless we solve for communication, we’re going to keep paying it.

An unhandled error has occurred. Reload 🗙