A few years ago I was in a meeting trying to explain why a "simple" feature would take three weeks. The PM looked at me like I was making excuses. "It's just a dropdown menu," she said. "How hard can it be?"

She wasn't wrong to be skeptical. From her perspective, I was the guy who always said things would take longer than expected. And I was failing at my job - not the coding part, the communication part.

That dropdown needed to pull from three different APIs, handle various permission levels, work offline, and sync when connection returned. But I never explained any of that. I just said "it's complicated" and expected her to trust me.

The meeting ended badly. Later, I learned to do this differently.

Why "It's Complicated" Doesn't Work

Non-technical people hear "it's complicated" as "I don't want to explain it" or worse, "I'm padding my estimates." They're not dumb. They just don't have context.

Think about it from their side. They work with software every day. They install apps, they click buttons, things happen. Why would adding another button take two weeks?

The gap isn't intelligence. It's that they can't see what's under the surface. Our job is to make the invisible visible - without putting them to sleep.

The Analogy Trick

I've started using more analogies. Not because they're perfectly accurate, but because they create shared understanding.

When explaining refactoring: "Imagine we're a restaurant. The kitchen works, but everything is disorganized. Chefs keep bumping into each other, ingredients are hard to find. We can keep cooking, but eventually someone's going to burn something. We need to reorganize the kitchen before the dinner rush."

Technical debt becomes financial debt: "We borrowed time to ship fast. Now we're paying interest - every new feature costs extra because we have to work around the shortcuts we took. We can keep paying interest forever, or we can pay down some principal."

Are these analogies perfect? No. But they're close enough to create understanding. And understanding is what gets you buy-in for the work that needs to happen.

Estimates Are Probabilities, Not Promises

Here's a conversation that has burned me before:

PM: "When will this be done?"
Me: "Friday."
PM: [tells stakeholders Friday]
[Tuesday, something unexpected happens]
Me: "It's going to be Monday."
PM: "You said Friday!"

The problem is that she heard "Friday" as a commitment. I meant it as "probably Friday if nothing goes wrong." These are very different things.

Now I give ranges: "Best case Friday, but there's some risk with the third-party API integration. If that causes problems, it could push to early next week. I'll know more by Wednesday." This sets expectations properly. It acknowledges uncertainty. And it gives them something to tell their stakeholders that isn't a lie.

Focus on What Matters to Them

Nobody outside engineering cares about your tech stack. They care about outcomes.

Bad: "I migrated the authentication service from Express to Fastify and implemented Redis session caching."

Better: "Login is now twice as fast, and users won't get randomly logged out anymore."

The first one might be technically impressive. The second one tells them why they should care. Always translate implementation into impact.

This applies to status updates too. "Still working on the database migration" is useless. "Database migration is 70% done - user data is moved, still working on transaction history. No user-facing changes yet" tells them something they can actually use.

How to Deliver Bad News

At some point you'll have to tell someone the project is late, the feature isn't working, or something broke in production. How you deliver that news matters a lot.

I use a simple structure: what happened, what it means for them, and what we're doing about it.

"We found a bug in the payment flow. It's only affecting about 2% of users, but those transactions are failing silently. I'm working on a fix now - should be deployed within the hour. We'll need to manually process about 50 affected orders."

Notice what's not there: excuses. Long technical explanations. Finger-pointing. Just the facts, the impact, and the path forward.

If they want more details, they'll ask. Usually they don't. They want to know it's being handled.

Saying No Without Saying No

Sometimes stakeholders ask for things that are technically possible but wildly impractical. "Can we add a chat feature by next week?" Sure, technically. It would also be buggy, insecure, and we'd spend the next six months fixing it.

Instead of "no," I try "yes, and here's what that means."

"We could add basic chat by next week. It wouldn't have message history, file sharing, or notifications - just real-time text. If we want those features, we're looking at six weeks. Or we could integrate with Slack's API in two weeks and get all of that for free. What matters most for this use case?"

This puts the tradeoff decision back on them. Usually they realize the quick version isn't worth it. But sometimes they surprise you - maybe basic text chat really is all they need. Either way, it's their informed choice.

Building Trust Over Time

None of this works if you don't follow through. If you give ranges and you're always at the worst end, people stop believing your estimates. If you promise updates and don't send them, people stop asking you.

Trust is built slowly through consistent behavior. Deliver when you say you will. Communicate proactively when things change. Admit when you're wrong. Over time, people start giving you the benefit of the doubt.

That PM who didn't trust me? We worked together for two more years. By the end, when I said something would take three weeks, she'd just nod and update the roadmap. Not because I got better at estimates (I didn't), but because I got better at explaining why things take time and keeping her informed when they changed.

The Payoff

Clear communication isn't just about avoiding conflict. It's about getting resources for the work that matters. Technical debt never gets prioritized if you can't explain why it's slowing you down. Infrastructure improvements don't happen if leadership doesn't understand the risk of the current system.

The engineers who get to work on interesting problems aren't always the most talented. They're often the ones who can explain why those problems matter.

It took me years to figure this out. I hope you figure it out faster.

Back to Developer Productivity

Back to Home