Over-Communication Doesn’t Exist
I used to work with a project manager named Karlijn. She had this phrase she’d repeat constantly, almost to the point where it became her opening and closing line for everything:
“Over-communication doesn’t exist.”
I thought it was kind of annoying at first. Like yeah, we get it, communication is important. Classic PM energy.
Then one day on a big mobile app project, it clicked.
We’d split the work. One dev was handling the user-facing questionnaire. I was doing the admin UI. Clean division of labor, right?
Except we both assumed the other person was building the database tables.
We sat there for days, each waiting for the other to finish “their part” so we could move forward. It wasn’t until Karlijn asked us to literally state out loud what we were working on that we caught it.
I said what I assumed. The other dev said what they assumed. We both went “oh shit.”
That’s when her phrase made sense.
The Thing Nobody Ever Says
I’ve been an engineering manager for 3.5 years now. I’ve seen projects succeed and fail for a hundred different reasons.
Never once has someone said: “Wow, this project failed because we repeated that question twice.”
But I’ve seen projects fail because we didn’t ask the question at all.
Never once has someone complained: “So annoying Chris asked me if I saw that very important Slack message.”
But I’ve seen critical messages get missed, and it’s always catastrophic when they do.
The math is simple: The cost of asking twice is basically zero. The cost of not asking at all can be everything.
I’m Still Learning This
Here’s the embarrassing part: I still mess this up.
Recently I posted a comment to the general leadership on Slack about how communication wasn’t great in the RFC-to-PR phase. I pointed out all these gaps, all these things that weren’t working.
Then someone pointed out: “Chris, weren’t you supposed to be raising your own issues with it?”
I wasn’t doing the thing I was expected to do. I didn’t communicate my concerns. I just shifted blame.
I felt so dumb. But I learned a lot from it.
Even now, there are still assumptions about how things should work, who’s tackling what, who’s expected to send updates. It’s vague. I don’t nail it every time.
But I’m getting better at catching it.
The Weekend Three People Fixed The Same Bug
We had an incident on a weekend. Alerts went off. Three of us got pinged.
Nobody took the time to write in Slack “I’m on this” or assign themselves.
An hour later, we’d all three fixed the same thing.
What a waste of everyone’s weekend.
If just one of us had said “I’m handling this,” the other two could’ve stayed in bed. Or gone to brunch. Or literally anything else.
But we didn’t communicate. We assumed. And assumption is expensive.
The Flip Side: Nobody Taking Ownership
The other version of this is when nobody handles something because nobody was clearly assigned.
Who’s handling this incident? If you don’t assign someone, either nobody will touch it, or three people will do the same thing.
Who’s sending project updates? If it’s not clear, everyone will skip it. “I figured someone else would do it.”
Who’s building the database tables? “I thought you were.”
It’s silly stuff. But it derails everything.
The Questions That Aren’t Actually Dumb
Here’s what I’ve learned: If you make it okay to ask “the obvious” or restate things everyone should already know, people feel way less hesitant to ask the things they think are dumb.
And those “dumb questions” are never actually dumb.
Who are we building this for again? Can you reiterate the customer?
How many users do we expect? How many data points?
Does this need to be production-grade, or is a POC okay?
When does the client actually expect this by?
These questions seem basic. But they’re the ones that catch the misalignments before they become disasters.
And here’s the real power: When you over-communicate, you’re not just creating clarity. You’re building psychological safety.
When you restate the obvious without making people feel stupid for not remembering, when you check in on things that should be clear - you’re telling your team it’s okay to speak up. It’s okay to say:
- “Wait, I’m confused about who’s doing this”
- “I thought we were building X, are we building Y?”
- “Can you remind me what the deadline is?”
- “I don’t think I understand the requirement”
That’s the real value. Not just that everyone knows what they’re doing, but that everyone feels comfortable saying when they don’t.
How I Actually Do This
I iterate. A lot.
I’ll restate responsibilities in syncs. Then I’ll write them down on a Confluence page. Then I’ll reiterate them in Slack. Then I’ll keep reminding people about their tasks and what’s expected.
Does it feel redundant? Sometimes. But you know what never happens? Someone going “wow Chris, you’ve communicated this too clearly.”
Engineers might complain about one too many meetings or syncs. That’s fair. But with the right steering, that’s not what this is about.
It’s about making sure everyone knows:
- What they’re building
- Who’s building what
- When it’s expected
- Who’s responsible for what part
And then restating it. Because people forget. Or they weren’t in that meeting. Or they read it but didn’t internalize it. Or they thought they understood but actually had a different picture in their head.
What Karlijn Taught Me
Karlijn was right. Over-communication doesn’t exist.
Because the alternative - under-communication, assumption, hoping everyone’s on the same page - is so much worse.
I’ve never seen a project fail because we asked twice.
I’ve seen dozens fail because we didn’t ask at all.
So yeah, I’m going to keep asking if you saw that Slack message. I’m going to keep restating who’s doing what. I’m going to keep checking in on things that should be obvious.
Not because I think you’re incompetent. But because assumptions are expensive, and clarity is free.
And if that feels like too much communication? It’s not. It’s just enough.
Let’s connect on LinkedIn—I’m always learning more about this stuff and would love to hear how you handle it.