The PM-Engineer Relationship: Why Engineers Hate You
Camille Fournier
CTO Rent The Runway, VP Tech Goldman Sachs, Author "The Manager's Path"
AUG 2024
The Core Problem
4 Things PMs Do That Annoy Engineers
Hoarding credit — you get visibility, engineers don't get recognition
Ignoring details — acting like technical work doesn't matter
Playing telephone — inserting yourself between stakeholders and engineers
Controlling ideas — keeping engineers out of product decisions
"When you act like technical details don't matter, it shows a real lack of empathy for the work that engineers are doing. It can be very off-putting."
PM Credibility
How to Actually Win Engineer Trust
Share credit actively: Step back and let engineers present their work
Care about details: You don't need to know everything, but show you respect the craft
Connect directly: If you're saying "let me get back to you" constantly, connect people directly instead
Invite ideas: The best PMs aren't threatened by smart engineers having good ideas
Why engineers propose rewritesEngineers over-engineer and propose rewrites when they're locked out of product decisions. They need a creative outlet. Give them one.
The actual jobBuild relationships with engineers by working alongside them on real problems. PMs are successful when engineers respect what you bring to the table.
The Rewrite Trap
Why Rewrites Almost Always Fail
Engineers massively underestimate migration time from old system to new system
You still have to support the old system while building the new one
If the old system doesn't need feature work, why spend millions rewriting it?
Most rewrites are engineering solutions to organizational problems
The best approach: staged, surgical upgrades (fix the recommendation system, not everything)
The key question
If I could ignore this system forever without harming the business, is it actually worth rewriting? If the answer is yes, you have a real problem.
The hidden cost
Rewrites kill feature velocity for 6 months to 2 years. That's not acceptable in most cases. Instead: invest in incremental evolution.
"People really underestimate the migration time. Engineers notoriously, notoriously massively underestimate the work to move from old to new system. And you still have to support both."
Management
Fewer One-On-Ones, More Impact
One-on-ones with direct reports: sacred, weekly/biweekly
One-on-ones with everyone else: scale poorly, often wastes time
Stakeholder 1-on-1s hide the real issues — unhappy stakeholders don't hear from happy ones
Group meetings work better for stakeholders and internal platforms
Stop doing one-on-ones just to fill your calendar. Respect everyone's time.
Camille's principleAs you grow, you cannot scale a one-on-one relationship management approach. Move to groups and async channels instead.
Contrarian
The Management Myths
✗Management = FreedomINSTEAD →✓ Management is grueling. You're reacting to problems constantly, not making glorious decisions.
✗More work = Better resultsINSTEAD →✓ Overwork lets you avoid hard prioritization. Focus on actual important work, not 60-hour weeks.
✗Do one-on-ones with everyoneINSTEAD →✓ One-on-ones don't scale. Use groups and async. Respect your time and theirs.
✗Engineers can't do the product jobINSTEAD →✓ Engineers have good ideas. They just don't understand customer needs or business metrics. Teach them that.