Engineers Started Respecting Me When I Stopped Conjuring Urgency
Engineers started respecting me more when I stopped doing magic.
I mean when I stopped conjuring urgency out of thin air.
I used to be a Product Manager who took his personal thoughts on estimates and the engineer's estimates too seriously. Then I would start questioning and chasing them about every delay, every slip, every missed commitment. Only after many years did I realize this was causing unnecessary friction.
TL;DR: Before questioning engineers about delays, ask yourself: "What is the business impact?" If there's no real impact, the discussion doesn't need to be intense. When you base urgency on business impact instead of assumed importance, engineers respect your judgment. And respect drives velocity far more than pressure ever will.
The mistakes I used to make
Mistake 1: Questioning based on assumptions
As a Product Manager, you may be capable of estimating at a high level. You see a task, you have a rough sense of how complex it "should" be. And when reality doesn't match your mental model, the instinct is to question.
"This is just a UI change. Why isn't it done after 3 days?"
The problem: You're just assuming a UI change won't take more time. You don't know about the responsive edge cases. The design system inconsistencies. The state management complexity hidden behind a "simple" interface change. The testing required across multiple browsers.
Your estimate was based on how it appeared to you. Their estimate was based on how it actually is.
Mistake 2: Treating estimates as contracts
"You guys committed to completing this in 2 weeks. Why didn't you deliver? What went wrong?"
This framing treats the estimate as a promise that was broken. It implies fault. It puts engineers on the defensive.
Challenges pop up anytime. Dependencies surface. Requirements change. Technical complexity reveals itself only during implementation. A "2-week estimate" given during planning is a best guess with incomplete information, not a blood oath.
When you frame delays as failures, engineers learn to:
- Over-pad estimates (so they never "miss")
- Under-commit (so they always "deliver")
- Hide blockers (because admitting them feels like admitting failure)
None of these make the team faster. They just make the numbers look better while actual velocity stays the same.
Why the questions were aggressive
If I honestly ask myself why those questions were negatively framed, the answer is uncomfortable: assumed urgency.
I was treating every task as if missing the deadline was the end of the world. As if every delay had catastrophic consequences. As if my credibility as a PM depended on everything shipping exactly on time.
But most of the time? The delay didn't matter much. No customer was waiting with a signed contract. No launch was at risk. No revenue was being lost. The urgency was entirely in my head.
I was conjuring urgency out of thin air. And that manufactured urgency was poisoning every conversation with engineering.
The question that changed everything
The first question you should ask yourself before questioning engineers "too much" is:
What is the business impact of the delay?
This single question transformed how I work with engineering teams.
If the answer is "a customer is waiting and might churn," then yes, the conversation needs to happen. Urgently. With appropriate seriousness.
If the answer is "no real impact, I just wanted it done by now," then the conversation can still happen. But it doesn't need to be serious or long. A simple "hey, noticed this is taking longer than planned. Anything blocking you? Need any help?" is enough.
| Situation | Business impact | Appropriate response |
|---|---|---|
| Feature delayed by 3 days, no customer commitment | None | Brief check-in, offer help |
| Feature delayed, customer demo next week | Medium | Discuss options, scope adjustments |
| Critical bug, users affected now | High | Immediate triage, all hands |
| Sprint item slipped, internal deadline only | None/Low | Note it, discuss in retro |
What happened when I changed
When I stopped treating every delay as a crisis and started basing urgency on business impact, several things shifted:
Engineers started being more honest about timelines. They weren't afraid of my reaction anymore. If something was taking longer, they told me early because the conversation wasn't going to be aggressive.
Blockers surfaced faster. When raising a problem doesn't trigger an interrogation, people raise problems sooner. I started hearing about issues on Day 2 instead of Day 10.
Trust built up. Engineers saw that I only raised alarms when there was a real business reason. So when I did say "this is urgent," they believed me. The urgency meant something because it wasn't the default.
We actually moved faster. Counterintuitive, but removing artificial pressure let the team focus better. Less anxiety. Less context-switching from defensive conversations. More deep work.
The right way to handle delays
When something takes longer than expected (and it will, regularly), here's the approach that earns respect:
First, try to understand what happened. Not with "why didn't you deliver?" but with "what came up that we didn't anticipate?"
Ideally, you shouldn't be asking the status only at the end of the 2-week window. Regular check-ins (non-judgmental ones) prevent the surprise of a delay appearing suddenly.
Second, evaluate the business impact. Is anyone actually waiting? Does this affect revenue, customers, or a commitment we made externally? If yes, discuss options. If no, note it and move on.
Third, help remove blockers. If the delay is caused by a dependency, a decision that's needed, or a requirement that's unclear, that's on you to fix. Not on the engineer to suffer through.
Fourth, discuss in retro, not in real-time. If there's a pattern of estimates being off, address it structurally in retrospectives. Not in heated real-time conversations where people are defensive.
Business impact as the universal filter
Treating everything based on business impact became one of my topmost learnings as a product manager. Not just for engineering conversations, but for everything:
- Should I push back on this stakeholder request? What's the business impact of saying no?
- Should I attend this meeting? What's the business impact of missing it?
- Should I chase this bug? What's the business impact if it stays?
- Should I reprioritize the sprint? What's the business impact of the current plan vs. the new one?
When you run everything through this filter, you naturally focus your energy on things that matter. And you stop wasting the team's energy on things that feel important but aren't.
The respect equation
I used to treat all estimates too seriously and raise shallow questions that created friction. Engineers tolerated me because they had to, not because they wanted to work with me.
When I changed the urgencies to be based on business impact and raised questions only after taking time to understand everything, I started gaining respect.
Not because I became "nice." Not because I stopped caring about delivery. But because my judgment improved. When I raised a concern, it was warranted. When I asked a question, it was informed. When I flagged urgency, it was real.
That's what engineers respect: calibrated judgment. Not someone who treats everything as urgent. Not someone who ignores everything either. Someone who can tell the difference.
The bottom line
Before you question engineers about a delay, ask yourself: what's the actual business impact? If you can't articulate a clear, concrete answer, the conversation doesn't need to be aggressive. A check-in is fine. Offer to help. And save your urgency for when it's real.
The PMs who earn the most respect from engineering teams are the ones whose urgency is calibrated. When they say "this matters," the team moves. Because they know the PM doesn't say it lightly.
How ProductResume helps
This kind of calibrated PM leadership, knowing when to push and when to trust, shows up in resume bullets as evidence of mature cross-functional collaboration. Score your PM resume to see whether your experience signals this kind of engineering partnership.