Your relationship with engineering is the most important working relationship you'll have as a PM.
When it's good, everything flows. Ideas get discussed openly. Estimates are honest. Problems get raised early. Shipping happens.
When it's bad, everything is hard. Engineers are defensive. Discussions are adversarial. Things take longer than they should. Nobody enjoys the work.
I've been on both sides. Here's what I've learned about building the good version.
The Foundation: Respect Their Craft
Engineers can smell condescension from a mile away. If you think of them as "resources" to be managed or code-producing machines, they'll sense it and respond accordingly.
Start from this premise: engineering is hard, complex work that requires real expertise. You probably couldn't do it. Approach with genuine respect.
This doesn't mean you can't push back or disagree. It means you do so while acknowledging that they know things you don't.
What respect looks like in practice:
- •Ask questions about technical decisions rather than assuming they're wrong
- •Listen when they raise concerns about feasibility or timeline
- •Acknowledge the complexity of what they're building
- •Defend engineering time against unreasonable requests
- •Give credit publicly for what they ship
What disrespect looks like (avoid this):
- •Treating estimates as negotiable or assuming they're padded
- •Going around engineers to their manager when you don't like an answer
- •Changing requirements frequently without acknowledging the cost
- •Taking credit for shipped products without mentioning engineering
- •Using phrases like "just" or "simply" (as in "can't you just...")
Earn Technical Credibility
You don't need to be an engineer. But you need to understand enough to be useful.
The baseline:
- •Know how the system architecture works at a high level
- •Understand why some things are harder than others
- •Be able to read a technical doc and ask intelligent questions
- •Know the difference between frontend, backend, database, and infrastructure
- •Understand the basics of APIs, data models, and system dependencies
How to build this:
- •Ask engineers to explain things. Most are happy to teach if you're genuinely curious.
- •Read the technical docs, even if you don't understand everything
- •Sit in on technical discussions (with permission) just to learn
- •When something doesn't make sense, ask follow-up questions
The goal isn't to become technical. It's to be conversant enough that engineers don't have to translate everything for you.
Bring Context, Not Just Requirements
The worst thing you can do is show up with a spec and say "build this."
Engineers want to understand why. They want to know what problem you're solving, who it's for, and what success looks like. This context helps them make better decisions—and it treats them as partners, not ticket-takers.
When bringing work to engineers:
- •Start with the user problem, not the solution
- •Explain why this problem matters (business context)
- •Share what you know about constraints and tradeoffs
- •Be open to alternative solutions that achieve the same goal
- •Invite pushback and questions
The magic question:
"Is there a simpler way to achieve this outcome?"
This question opens the door for engineers to propose alternatives. Often, they have ideas that are faster to build, more elegant, or more maintainable—but they need permission to share them.
Handle Estimates and Timelines Carefully
Estimates are a source of tension in many PM-engineering relationships. Here's how to make it better:
Never argue with an estimate.
If an engineer says something will take three weeks, that's their professional judgment. You can ask questions to understand the breakdown, but you shouldn't try to negotiate it down.
Do ask for transparency:
- •"Can you walk me through what makes this take three weeks?"
- •"What would need to change to get a version shipped in one week?"
- •"What are the biggest risks or unknowns in this estimate?"
These questions help you understand the work without challenging the estimate itself.
When timelines are tight:
If you have a deadline, share it—with context for why. Then ask: "What would we need to cut or change to hit this date?" Put the tradeoff conversation in their hands rather than demanding they work faster.
Give Engineers Ownership
The best PM-engineering relationships aren't PM-driven. They're partnerships where engineers have real ownership of the product.
What this looks like:
- •Include engineers in customer conversations and research
- •Share user feedback and data regularly
- •Ask for their input on product direction, not just implementation
- •Let them propose solutions and features
- •Give them visibility into why decisions are made
Why this works:
Engineers who feel ownership care more about the outcome. They'll raise problems earlier. They'll go the extra mile when needed. They'll stick around longer.
Engineers who feel like they're just executing someone else's vision tend to disengage. They do exactly what's specified, nothing more.
When You Disagree
Disagreements happen. How you handle them determines the health of the relationship.
First: Understand their position.
Before pushing back, make sure you understand why they see it differently. Ask questions. Repeat back what you heard. Often, the disagreement dissolves once you actually understand each other.
Second: Share your reasoning.
Explain why you see it differently. Bring data if you have it. Be clear about what you're optimizing for.
Third: Find a path forward together.
Sometimes one person is right. Sometimes the answer is a compromise. Sometimes you need to run an experiment to find out. The key is arriving at a decision together rather than one person pulling rank.
Fourth: Once decided, commit.
After a decision is made, support it fully—even if it wasn't your preference. Nothing erodes trust faster than relitigating decisions or undermining them after the fact.
The Day-to-Day
Little things matter:
- •Be responsive. If engineers are blocked waiting for your input, unblock them fast.
- •Show up to standups (or whatever ritual the team has). Be present.
- •Know what's being worked on and what the challenges are.
- •Celebrate wins. Shipping is worth acknowledging.
- •Shield the team from unnecessary noise. Not every executive request needs to flow through.
When It's Not Working
Sometimes the relationship is broken, and you need to diagnose why:
If engineers don't trust you:
Rebuild slowly. Be transparent. Follow through on commitments. It takes time.
If you keep changing requirements:
That's a you problem. Improve your upfront work. Commit to decisions longer before pivoting.
If engineers are disengaged:
Are they bored? Burned out? Frustrated? The cause matters. Talk to them directly. Often it's not about you—it's about the work or the company.
If there's a specific engineer you clash with:
Have a direct conversation. Clear the air. If it doesn't resolve, get your managers involved—but try direct resolution first.
The Bottom Line
The PM-engineering relationship is a partnership. Not a hierarchy where you dictate and they execute. Not a dynamic where they build and you take credit.
You bring user context and prioritization. They bring technical expertise and execution. Together, you build something neither could build alone.
Invest in that relationship. It's the foundation of everything else.
Related reading: Working with Designers and Stakeholder Management cover other critical PM relationships.