The team doesn't win because you did
Is your communication actually helping your team?
I used to think I was a great communicator. I talked about issues before they became blockers. I kept my teammates up to speed without them having to chase me. I turned in tickets on time, and I made it a point to push updates proactively. No one ever had to come looking for me.
That worked well. For a while.
What I had to reckon with is that those were personal traits, not team outcomes. I was doing my part well, but a team doesn’t win by singular effort. It wins collectively, or it doesn’t win at all.
I work across two horizontal team structures, a Marketplace team and a Platform team. Each is equipped to ship products and features end to end, each has its own goals and deliverables, and both are ultimately aligned to the same business outcomes. That means at the end of the day, both teams have to communicate progress, flag what’s working, and be honest about what’s not.
In environments like this, the cost of poor communication compounds fast. Timelines shift. People get blocked, sometimes for reasons entirely outside their control. What separates teams that stay on track from teams that spiral into fire drills isn’t talent. It’s how quickly and honestly people surface information.
Why wait for the daily standup to talk about a blocker? Why wait for your PM to come hunting?
The faster problems get named, the faster they get solved. That’s the entire premise.
What this looks like in practice
I’ve got three examples from my own experience that made this concrete for me.
The first happened when I was building a feature and waiting on a backend engineer to push API updates and documentation. I escalated to my PM, which was the right thing to do. But she didn’t have the full picture, because the backend engineer kept saying the updates were pending peer review on his PR. We missed the business deadline. When we finally sat down as a team and talked through it, the fix was obvious. The blocker needed to go one level higher, to the backend lead or the engineering manager, because the PR review itself was the actual problem. Nobody escalated that. I didn’t escalate that. We all assumed someone else had it handled.
The second example is about how bugs get handled. The instinct for a lot of engineers, especially early in their careers, is to panic, take the blame, or disappear into the problem until there’s a fix. That’s not communication. Effective communication is sending a holding message first: “I’ve seen this, I’m investigating, here’s a rough ETA.” Then keeping people updated as you work. It sounds small. It completely changes how a team experiences an incident.
The third is one I see often. A PM writes a PRD, an engineer reads it and starts building, and somewhere in the middle a question comes up. Instead of asking, the engineer builds what they assumed was right. I’ve done this. It feels efficient in the moment. It almost never is. Effective communication here means either stopping to ask immediately, or if you need to keep moving, building your interpretation and then explicitly flagging it to the PM and getting sign-off before you go further. One sentence of confirmation saves days of rework. More importantly, it prevents the kind of quiet misalignment that’s far worse than any individual mistake.
When everyone does this, the whole team moves faster
Something I’ve noticed is that the desire to communicate effectively makes you proactive by default. You start asking questions you wouldn’t have asked before, not because you’re unsure of yourself, but because you understand the cost of assumptions. Those questions change things. They unblock people. They surface problems early enough to actually solve them. Sometimes they change how the whole team works.
I’ve seen what it looks like when a team actually practices this. Blockers, technical and otherwise, get resolved before they compound. Features ship closer to when they were promised. Non-technical teams like marketing and sales feel included rather than surprised. Engineers get recognised not just for what they build, but for how clearly they articulate what they’re building and why it matters.
And the quieter benefit: you stop waking up wondering if anyone knows what’s happening. When communication is a team habit, everyone’s already up to date.
The performance review, the awards, being the strongest engineer on the team. None of it matters much if the team keeps missing deadlines. Someone always ends up carrying that, and it’s rarely the person who stayed quiet when it counted.
The shift that made the biggest difference for me was learning to think less about communicating my own status and more about what information the team needs to move. Those are related but they’re not the same thing. One is about you. The other is about the goal.
That’s where effective communication actually starts.