The PM role comes with a peculiar kind of power: you're expected to lead a team that doesn't report to you, make decisions you don't have full information for, and be accountable for outcomes you can't fully control. Engineering relationships are where this tension is felt most acutely.
I've worked with engineering teams across four companies now — from small startup teams to a distributed large distributed engineering org at my current employer. The engineers who've shipped the best products with me weren't the ones I managed — they were the ones who trusted me. Here's what I've learned about earning that trust.
The Foundational Mistake: Treating Engineers as Execution Resources
The fastest way to destroy your relationship with an engineering team is to treat them as a factory that turns requirements into features. When a PM hands over a detailed spec and says "build this," they're implicitly saying: "your job is to execute, not to think." Engineers are problem-solvers by nature. Excluding them from problem definition makes them feel like contractors, not collaborators.
The shift that changed everything for me was bringing engineers into the problem space, not just the solution space. Instead of "We need a chatbot that handles return queries," I started with "Our support call volume for returns is up 30% and it's costing us ₹X per month — what can we do?" That framing invites engineering creativity, surfaces constraints I wouldn't know about, and produces better solutions than anything I could have written alone.
Technical Respect is Earned, Not Assumed
My engineering background helps — but I've learned not to lead with it. Nothing irritates an engineer more than a PM who ostentatiously name-drops technical concepts to signal credibility. True technical respect is built through behaviour, not credentials.
The behaviours that have worked for me:
- Read the system design before asking questions. When we onboard a new integration at my current employer, I review the architecture document myself first. My questions in the technical discussion are specific, not generic. Engineers notice.
- Don't push back on estimates without understanding why. If an engineer says something will take three weeks, my first question is "walk me through the main complexity" — not "can we do it in two?" Understanding the reasoning means I can make an informed trade-off, not an uninformed pressure play.
- Acknowledge what you don't know. "I don't fully understand the latency implications here — can you help me think through them?" is far more respected than pretending to expertise you don't have.
The Rituals That Build Relationships
Weekly 1:1s with the Tech Lead
Not sprint planning, not backlog grooming — a separate, informal thirty minutes with the engineering lead. No agenda beyond: "What's on your mind? What's getting in your way? What do you wish I understood better?" These conversations have surfaced more product-critical information than any formal meeting I've run.
The "Why" Brief Before Every Sprint
Before each sprint starts, I share a one-paragraph brief with the team that explains the why behind what we're building. Not the business justification for management — the user story, the pain point, the outcome we're aiming for. Engineers make dozens of micro-decisions during implementation. When they understand the goal, those decisions align with it. When they don't, they optimise for the wrong things.
Retrospectives Where PMs Aren't Defensive
I've sat in retrospectives where PMs treated critical feedback as an attack. That's a culture killer. I make it a point to start retrospectives by naming something I did that didn't work — a requirement that was underspecified, a stakeholder constraint I didn't communicate clearly, a decision I made without enough consultation. It sets the tone that this is a learning session, not a blame session.
The signal I watch for: If engineers start coming to me with problems before they become issues, trust is there. If I'm always the last to hear about blockers, something is broken in the relationship.
When You Disagree with a Technical Decision
This happens. A PM sees a different architectural path, thinks the estimated effort is too high, or believes a technical constraint is being overstated. How you handle this moment defines whether your relationship with engineering is collaborative or adversarial.
My approach: disagree privately, support publicly, and decide with data.
If I have a concern about a technical approach, I raise it with the tech lead in our 1:1, not in sprint planning. I frame it as a question, not a pushback: "Help me understand the trade-offs between option A and option B — are there user-facing implications to the architectural choice?" If I still disagree after understanding the reasoning, I say so clearly — once — and then commit to the decision the team makes.
The Language That Builds Bridges
Small language choices compound over time. I've trained myself to say:
- "What are the risks I should know about?" instead of "Why will this take so long?"
- "Help me understand the constraints" instead of "That constraint seems arbitrary"
- "We shipped this together" instead of "My team delivered this"
- "What would make this sprint better for you?" instead of "How do we go faster?"
The Ultimate Test of the PM-Engineer Relationship
A live production incident. Something is broken, users are affected, everyone is stressed, and decisions need to be made fast. In those moments, the quality of the relationship is revealed instantly.
The best incident I've been through at my current employer wasn't the one we handled perfectly — it was the one where the engineering lead called me at 11pm because he trusted me to help make the trade-off call on whether to roll back or push a patch. That call at 11pm was a relationship outcome. It doesn't happen without months of trust built in calmer moments.
Build for the 11pm call. Every 1:1, every "why" brief, every retrospective where you're honest about your own mistakes — that's the investment. The returns show up when it matters most.
