The Trust Deficit Is Real
In a 2023 survey by Pragmatic Institute, 67% of engineers said they did not fully trust their product manager to make good prioritization decisions. In a separate survey, 72% of PMs said they had a "good relationship" with engineering.
Someone is wrong. And it is probably the PMs.
The PM-engineering relationship is the most important partnership in product development, and it is also the one most frequently damaged by well-intentioned but destructive PM behaviors. Trust is not built by being nice or buying the team lunch. It is built through a specific set of behaviors practiced consistently over months.
The Six Trust-Building Behaviors
1. Respect estimates, even when they are inconvenient
Nothing destroys trust faster than a PM who hears "that will take 6 weeks" and responds with "can we do it in 3?"
Engineers estimate based on their understanding of the codebase, the technical complexity, and the risk of unknown unknowns. When you push back on an estimate, you are implicitly saying: "I know your domain better than you do." You almost certainly do not.
What to do instead:
- Ask "what is driving the complexity?" to understand the estimate, not to challenge it.
- Ask "is there a smaller version we could ship in 3 weeks?" to explore scope, not timeline.
- Ask "what would we need to change about the approach to reduce the timeline?" to invite collaboration.
The difference is subtle but engineers notice it immediately. The first approach questions their competence. The second and third approaches respect their expertise and invite them to problem-solve with you.
Real scenario: At a B2B SaaS company, a PM consistently negotiated estimates down by 30-40%. The engineering team responded by padding estimates by 50%. Both sides knew what was happening. Nobody trusted anyone. The solution was a new PM who took the first estimate at face value and instead negotiated scope. Within two quarters, estimates became more accurate because engineers stopped padding.
2. Shield the team from scope creep
The PM's job includes being a filter between the outside world and the engineering team. Stakeholders, customers, executives, and sales teams all have requests. If every request flows directly to the engineers, they lose focus and lose trust in the PM's ability to manage the product.
What this looks like in practice:
- When a stakeholder asks for a change mid-sprint, your default response is "let me evaluate that and get back to you." Not "let me ask engineering."
- You maintain the backlog and protect sprint planning commitments. If something must change mid-sprint, you remove something else of equal size.
- You document scope changes and communicate them transparently: "Sales asked for X. I said no because it conflicts with our current priority. Here is why."
The phrase engineers most want to hear from their PM: "I handled it." That means you absorbed the request, evaluated it, and either declined it or prioritized it without disrupting the team's current work.
3. Share context, not just requirements
A requirement without context is an order. A requirement with context is a collaboration.
Bad: "We need to add a CSV export to the reports page by March 15."
Good: "Three of our top 10 accounts have asked for CSV export because their finance teams cannot use our API. Without this, we risk $480K in renewals. Here is the Slack thread where the request came from. I think CSV export is the right scope. What do you think?"
The second version takes 30 more seconds to write and produces measurably better outcomes. Engineers who understand why they are building something make better technical decisions, catch edge cases earlier, and feel like partners rather than order-takers.
This is the core of the product trio model, as described by Marty Cagan's SVPG. Product, design, and engineering working together with shared context, not in a hand-off chain.
4. Give credit publicly, take blame privately
When a feature ships and users love it, the PM's job is to highlight the engineering work. "The team rebuilt the rendering pipeline and it is 4x faster. Here is what they did." Not "we shipped a faster product."
When something breaks or misses the deadline, the PM's job is to take responsibility externally. "I scoped this wrong" or "I did not account for the integration complexity" or "we need more time because I prioritized the wrong things." Not "engineering underestimated" or "there were unexpected technical challenges." (The second one is technically true but it implicitly blames engineering.)
Why this works: Engineers talk to each other. When they see a PM taking credit for their work, word spreads fast. When they see a PM absorbing blame that was partly shared, word also spreads. In a very different way.
5. Learn enough technical context to be useful
You do not need to code. You need to understand enough about the system architecture to ask good questions and avoid impossible requests.
Minimum viable technical knowledge:
- How the deployment pipeline works (CI/CD, staging, production)
- The rough architecture of the system (monolith vs microservices, key databases, third-party dependencies)
- What technical debt exists and where it hurts most
- The difference between frontend and backend complexity for a given feature
How to build this knowledge:
- Read the engineering team's design docs and RFCs
- Attend architecture review sessions (listen, do not opine)
- Ask an engineer to walk you through the codebase for 30 minutes. They will respect you for asking
- Use the product yourself enough to notice performance issues and bugs before users report them
The goal is not to become a technical expert. It is to demonstrate that you care enough about the engineering work to understand it.
6. Protect focus time and minimize interruptions
Engineers do deep work. Context switching is expensive. research by Gloria Mark at UC Irvine suggests it takes 23 minutes to regain full focus after an interruption. A PM who Slacks an engineer with "quick question" five times a day is costing the team hours of productive work.
What to do instead:
- Batch your questions. Send one message with three questions instead of three messages with one question each.
- Use async communication by default. Unless something is actually on fire, it can wait for the engineer to reach a natural stopping point.
- Schedule a daily or weekly sync for non-urgent questions instead of ad-hoc interruptions.
- Respect "do not disturb" and focus time blocks on their calendar.
What Are the Five Trust-Destroying Anti-Patterns?
If you recognize yourself in any of these, stop immediately. Each one takes months to repair.
Anti-pattern 1: The Drive-By Requirement
Dropping a requirement into Slack or Jira without context, discussion, or explanation. "Can you add a toggle to disable email notifications?" with no explanation of who needs this, why, or how it connects to the product strategy.
The fix: Every requirement comes with a one-paragraph context block: who needs it, what problem it solves, and why it is prioritized now.
Anti-pattern 2: The Moving Target
Changing requirements after engineering has started building. Not once (that happens). Repeatedly. Engineers who experience this learn to wait as long as possible before starting work, because they expect the requirements to change.
The fix: Lock scope before sprint start. If requirements must change mid-sprint, own the trade-off conversation explicitly.
Anti-pattern 3: The Demo Pressure
Pushing the team to have something "demo-ready" for a stakeholder meeting that was scheduled without consulting engineering. This forces shortcuts that create technical debt and resentment.
The fix: Coordinate demos with the engineering lead. If a stakeholder wants to see progress, show them the work-in-progress state. With an honest framing. Rather than pressuring the team to polish something that is not ready.
Anti-pattern 4: The Selective Listener
Only engaging with engineering input when it supports your preferred direction. Ignoring concerns about technical feasibility. Overriding engineering recommendations without explanation.
The fix: When engineering raises a concern, document it. If you decide to proceed anyway, explain why in writing. "I hear the concern about database performance. Here is why I think the business value justifies the risk, and here is the mitigation plan if the concern materializes."
Anti-pattern 5: The Absent PM
Not being available when engineering needs decisions. Letting questions sit in Slack for hours. Missing standups and sprint ceremonies without explanation.
The fix: Be present. If you cannot attend a ceremony, explain why and designate someone to make decisions in your absence. Response time to engineering questions should be measured in hours, not days.
How Do You Measure Trust with Engineering?
Trust is hard to quantify, but you can track proxies:
- Are engineers volunteering ideas and suggestions? If they only do what is asked and never propose alternatives, trust is low.
- Do engineers tell you when they are concerned about a decision? Silence from engineering is not agreement. It is disengagement.
- How accurate are estimates? Inflated estimates are a trust signal. When engineers trust the PM, they give honest estimates because they do not expect those estimates to be used against them.
- Do engineers come to you with problems early? If you only hear about issues in retrospectives, trust is low. If engineers Slack you about risks as soon as they see them, trust is high.
The 90-Day Trust Building Plan
If you are a new PM joining a team, or if you need to rebuild trust after a rough period:
Month 1: Listen and learn.
Do not change anything. Attend all ceremonies. Read design docs. Ask engineers about their biggest frustrations. Do not promise to fix anything yet. Just demonstrate that you are paying attention.
Month 2: Deliver small wins.
Fix one thing that annoys the team. Maybe it is a broken build pipeline. Maybe it is a stakeholder who constantly interrupts with requests. Maybe it is an unclear priority. Pick the smallest, most annoying thing and fix it. Then fix another.
Month 3: Establish patterns.
By now, you have context and some goodwill. Start establishing the behaviors described above. Share context with every requirement. Protect sprint commitments. Give credit publicly. Take blame privately.
Trust is not a milestone. It is a practice. The PM who builds trust is not the PM who does one grand gesture. It is the PM who shows up consistently, respects the team's expertise, and earns the right to ask for hard things by proving they will protect the team when it matters.