PMs, Stop Trying to Control Engineers. It Backfires Every Time.
"As a Product Manager, you must take control."
This is the most counterintuitive advice new PMs receive. And the most damaging.
It sounds right. PMs own the product. PMs set priorities. PMs drive outcomes. So naturally, you should be in charge. Right?
Wrong. And if you've been operating this way, you've probably already felt the resistance without understanding where it comes from.
TL;DR: PMs don't have authority over engineers. They have influence. But many PMs try to replace influence with pressure, giving orders, imposing timelines, shutting down pushback. This triggers psychological reactance: the harder you push, the more people resist. What actually works is partnership. Involve engineers early, talk about impact instead of instructions, and trust smart people with the how.
The phrases that kill collaboration
If you've ever said things like this to your engineering team:
- "Just do it, it's a priority."
- "This should be completed in a week."
- "Just go ahead! We already decided this."
You've experienced the awkward silence that follows. The subtle shift in energy. The engineer who nods but clearly checked out.
These phrases feel efficient. They're actually destructive.
Not because the content is wrong. Maybe it is a priority. Maybe a week is reasonable. Maybe the decision was already made. But the framing, the tone of command, the implied "you don't get a say," that's what causes damage.
Why orders trigger resistance
You've definitely seen this pattern in real life:
- Someone is happy to help... until they're told to.
- A task feels fine... until it's pushed aggressively.
- A timeline feels reasonable... until it's imposed without discussion.
The fastest way to make someone not want to do something is to order them to do it.
This isn't a personality flaw. It's not engineers being difficult. It's human psychology.
There's a name for it: reactance. It's a well-documented psychological phenomenon. When people feel their autonomy is being threatened, they instinctively push back. Not because the request is unreasonable. But because the way it was delivered removed their sense of choice.
The same task, framed as a collaborative decision, gets enthusiastic buy-in. Framed as a directive, it gets grudging compliance at best. Active resistance at worst.
Reactance explains why the PM who "takes control" often gets less done than the PM who shares control. The first PM fights resistance all day. The second PM has a team that moves fast because they want to, not because they were told to.
The authority illusion
Here's what nobody tells new PMs: you don't have authority over engineers. You never did.
You can't fire them. You can't promote them. You don't assign their performance ratings. You don't decide their compensation. In most org structures, engineers report to an engineering manager, not to you.
What you have is influence. The ability to make a compelling case. To align people around a shared goal. To create context where smart people make good decisions without being micromanaged.
Some PMs accept this and become incredibly effective. They learn to lead through clarity, conviction, and collaboration.
Other PMs can't accept it. They feel the gap between "I'm supposed to own this product" and "I can't actually tell anyone what to do." And they try to close that gap with pressure.
Pressure looks like:
- Setting deadlines without engineering input
- Presenting decisions as final before the team weighed in
- Escalating to leadership when engineers push back
- Using urgency as a weapon ("leadership needs this by Friday")
- Making engineers feel like implementation details are "not their concern"
Every one of these actions withdraws trust. And trust, once gone, is expensive to rebuild.
What pressure-based PMs actually produce
Let's be honest about what happens when a PM leads with pressure:
Short-term: things might move faster. Engineers comply because fighting is exhausting. Features ship on the imposed timeline.
Medium-term: quality drops. Engineers stop raising concerns because "it doesn't matter anyway." Technical debt piles up. Bugs slip through because nobody felt ownership over the solution.
Long-term: the best engineers leave your team. Or they stay but disengage. They do exactly what's asked and nothing more. No proactive suggestions. No "hey, I noticed something we could improve." No going the extra mile.
You end up managing a team of order-takers when you could have had a team of co-builders. That's the real cost of control.
What actually works
Stop trying to control people. Start partnering with them.
Involve engineers before decisions are locked
The single biggest friction point I see between PMs and engineers is timing. The PM shows up with a fully-formed solution and says "build this." The engineer has no context on why, no input on how, and no ownership over the outcome.
Fix: bring engineers into the problem space early. Share the user pain. Share the data. Let them participate in shaping the solution. They'll often find better approaches you didn't consider.
This doesn't mean design by committee. You still make the final call on what to build. But there's a difference between "I decided and you execute" and "here's the problem, I'm thinking this direction, what do you see?"
Talk about impact, not instructions
Instead of: "Build the notification system this sprint."
Try: "We're losing 15% of users in the first week because they forget to come back. If we solve this, retention improves by X. Notifications are one approach. What do you think?"
The first framing is a task. The second is a mission. People show up differently for missions.
When you talk about impact, engineers can engage with the problem creatively. They might suggest a simpler solution. They might identify a technical constraint that changes the approach. They might be more invested because they understand why it matters.
Trust smart people with the how and when
You own the what and the why. Engineers own the how and (largely) the when.
If you've hired smart people and then tell them exactly how to implement something and exactly when it needs to be done, you've wasted their expertise. You've also guaranteed they won't feel ownership over the outcome.
Trust looks like: "Here's what we need to achieve and why. How would you approach it? What timeline feels realistic given the complexity?"
This isn't abdicating responsibility. It's distributing ownership. And ownership drives quality in a way that imposed deadlines never can.
Listen when they push back instead of getting defensive
When an engineer says "that's going to take longer than you think," your first instinct might be to challenge it. To push for a shorter timeline. To ask "why?" in a tone that really means "do it faster."
Resist that instinct. Nine times out of ten, when an engineer pushes back on a timeline or approach, they have information you don't. Technical complexity you haven't considered. Dependencies you didn't know about. Past experience with similar problems.
Listening doesn't mean accepting everything at face value. It means engaging with their reasoning honestly. "Help me understand what makes this complex" is worlds apart from "can we do it in half the time?"
The partnership shift
The moment you switch from pressure to partnership, something changes.
Work moves faster. Not because you pushed harder, but because people stopped resisting. Engineers start volunteering ideas. Raising problems early instead of letting them fester. Going above the minimum because they feel ownership.
And crucially: the resentment disappears. No more passive-aggressive standups. No more engineers who "didn't see" your Slack message. No more vague "it's more complex than expected" delays that are really just disengagement in disguise.
Partnership doesn't mean you're soft. It means you're smart. You're getting more output from the same team by changing how you engage, not what you ask for.
Recognizing reactance in yourself
This isn't just about how you treat engineers. Reactance works both ways.
When leadership imposes something on you without context, how do you feel? When someone says "just do it, it came from the top," does that make you more or less motivated?
Exactly.
The same frustration you feel when your autonomy is removed is what engineers feel when you remove theirs. Remembering that is usually enough to change your approach.
The bottom line
PMs don't have authority. They have influence. And influence grows through trust, not pressure.
The counterintuitive truth: the PM who "takes control" gets less done than the PM who shares it. Because control triggers resistance. Partnership triggers ownership.
Stop ordering. Start involving. Stop imposing. Start discussing. Stop defending. Start listening.
The work will move faster. And without resentment.
How ProductResume helps
If you lead through influence and partnership rather than authority, your PM resume should reflect that. Bullets like "directed the team to build X" signal a command mindset. Bullets like "aligned engineering and design around Y, resulting in Z" signal leadership without authority, which is what hiring managers actually look for. Score your resume to see how your Leadership & Impact dimension reads to a hiring manager.