I was leading a project that was falling behind. I knew the architecture had problems. I knew we’d miss the deadline. But I kept waiting for someone to ask about it.
They finally did, three weeks later. By then it was a disaster.
Here’s what I learned: if you wait for people to ask what’s happening, they’ll assume everything is fine until it isn’t. Then they’ll wonder why you didn’t tell them sooner.
The Problem with Only Responding#
Most people communicate by responding. Someone emails, you reply. Someone asks for an update, you give one. Someone reports a bug, you fix it.
This feels efficient. You’re never wasting anyone’s time with unnecessary information.
But you’re also training everyone around you that they need to chase you for information. Your manager has to ask how the project is going. Other teams have to check if your changes will affect them. Leadership has to dig to find out if there are any risks.
Good engineers I’ve worked with get stuck here. They build great systems but nobody knows about them until something breaks. They solve hard problems but only after someone complains first.
I watched a senior developer spend two weeks refactoring a critical payment system. Beautiful code. Cut processing time in half. Nobody knew about it until six months later when someone stumbled across it while debugging something else. All that work, invisible.
Meanwhile, another engineer on the same team would send short updates whenever they shipped anything: “Reduced API latency by 200ms, here’s how.” Five sentences, maybe a chart. Everyone knew what they were doing. Guess who got promoted?
The difference wasn’t skill. It was communication timing.
What Actually Happens When You Don’t Communicate#
Let me be specific about what “waiting to be asked” looks like in practice.
You’re three days into a task you estimated at two days. You know you’ll need another three days. Do you say something now, or wait until the standup tomorrow when someone asks?
If you wait, here’s what happens: your manager built their plan assuming you’d be done today. The QA team scheduled testing for tomorrow. The product manager told the customer it ships Friday. Now everyone scrambles to adjust because you didn’t take 30 seconds to say “This is taking longer than expected.”
Or this: you’re changing how authentication works. You know the mobile app makes assumptions about the token format. Do you message the mobile team now, or wait to see if they notice?
If you wait, they deploy their app next week. It breaks in production. They spend hours debugging. Eventually they find your change. Now you’re the person who broke production without warning anyone.
This stuff happens constantly. And it’s always because someone knew something and didn’t say it.
What to Do Instead#
Tell people things before they ask. Not everything, just what they need to know.
Here are the situations where I’ve learned to speak up first:
When timelines slip. You estimated five days, it’s been three, and you’re maybe 30% done. Send a message now. “This is taking longer than I thought. Now looking at 8-10 days instead of 5. Want me to cut scope or push the deadline?”
Don’t wait for the standup. Don’t wait for someone to ask. The moment you know, tell them.
When you make technical decisions. You chose Postgres over MySQL. You went with REST instead of GraphQL. You added a new required field to the API.
These decisions seem local when you make them, but someone else is depending on them. Send a quick note: “Heads up, changing the user endpoint to require email validation. Goes live Thursday. Let me know if this breaks anything for you.”
When you spot risks. The database is growing faster than expected. The API is getting slower under load. The new feature works but the code is messy and will be hard to maintain.
Don’t wait for it to become a problem. Flag it while there’s time to fix it: “Noticed the response time creeping up on the search endpoint. Not urgent yet, but we should probably look at adding caching in the next sprint.”
Regular updates. I send a Friday email to my stakeholders. Takes 10 minutes. Three bullets: what shipped this week, what’s next week, anything I’m concerned about.
Most weeks it’s boring. That’s the point. Boring means no surprises. And when something does come up, they already know the context because I’ve been keeping them in the loop.
Why People Don’t Do This#
I’ve heard all the excuses because I’ve used most of them myself.
“I don’t want to bother people.” You’re not bothering them. You’re saving them from having to bother you. Your manager would much rather read a two-sentence update than schedule a meeting to ask you what’s happening.
“What if I’m wrong?” Then you send a follow-up. “Update: that thing I said would take 8 days only took 6, we’re back on track.” Nobody gets mad at good news.
“I don’t want to look like I don’t know what I’m doing.” Here’s the thing: missing a deadline without warning makes you look like you don’t know what you’re doing. Flagging a delay early makes you look like someone who manages risks.
“I’m too busy.” You’re not too busy to send a three-sentence email. And if you think you are, you’re definitely too busy to deal with the mess that happens when you don’t.
The real reason people don’t communicate early is because it feels uncomfortable. It’s easier to stay quiet and hope things work out. But hope isn’t a plan, and quiet isn’t professional.
When to Just Respond#
You can’t tell people everything ahead of time. Some situations need immediate response, not advance warning.
During an outage, fix it first. Send updates about what you’re doing, but don’t wait to write the perfect post-mortem before you stop the bleeding.
When someone’s blocked on your code review, just review it. They don’t need your weekly update, they need you to unblock them in the next hour.
When there’s an urgent question in Slack, answer it. Don’t make them wait for your Friday summary.
The pattern: use responding mode for immediate needs. Use telling mode for everything else.
What This Looks Like in Practice#
Here’s what changed when I started doing this consistently:
Fewer meetings. When people already know what’s happening, they don’t schedule meetings to find out. My calendar went from 25+ hours of meetings a week to maybe 15.
Fewer surprises. When you warn people about problems early, they stop feeling like problems and start feeling like things you’re managing. Nobody panics about a risk you flagged two weeks ago.
More trust. This was the biggest one. When you consistently tell people what’s happening without them having to ask, they start trusting you to handle things. Which means they give you more responsibility and more interesting work.
The promotion I mentioned earlier? Part of it was doing good work. But the bigger part was making sure the right people knew about the good work without having to dig for it.
How to Start#
Pick one thing you’re working on this week. Before anyone asks about it, send a short update.
Could be to your manager: “Making good progress on the API refactor. About halfway done, on track for end of week.”
Could be to another team: “Just changed how we’re handling user sessions. Shouldn’t affect you, but let me know if you see weird auth behavior.”
Could be to your team: “Fixed that bug in production. Root cause was a race condition in the cache layer. Added a test so it won’t happen again.”
Two or three sentences. Hit send.
See what happens. Usually one of two things:
- They appreciate it and you feel less anxious because you’re not sitting on information
- They don’t respond, which is fine because they know now and you don’t have to worry about it
Do this a few times and it becomes automatic. You finish something, you tell the relevant people. You spot a problem, you flag it. You make a decision, you share it.
After a few weeks, people stop asking you what’s happening because they already know. And that’s when things get easier.