Rasp logo

Rasp

Getting Engineering to Love You (or at Least Tolerate Your Requests)

•By Rasp Team

Every product manager has been there.

You walk into sprint planning with what you think is a great idea. Engineering's reaction?

Silence. Side-eyes. One brave engineer asks, "Why are we building this again?"

You explain. They nod politely. Then they:

  • Estimate it at 3x what you hoped
  • Ask questions that reveal you haven't thought it through
  • Suggest it's technically complex in ways you don't understand
  • Ultimately build it, but with minimum enthusiasm

The problem isn't them. It's you.

Engineering doesn't hate PMs. They hate bad PMs — ones who waste their time, ignore technical reality, and treat them like code monkeys.

The best PM-engineering relationships are partnerships, not battles. Here's how to build one.

Why Engineering Rolls Their Eyes at PMs

Let's be honest about what frustrates them.

Frustration 1: Requirements That Make No Sense

What PMs do wrong:

"Build a dashboard that shows everything users need."

What engineers hear:

"I have no idea what I want. Figure it out for me."

Why it frustrates them: Vague requirements waste time. They build the wrong thing, you reject it, they rebuild. Everyone's miserable.

Frustration 2: Changing Priorities Mid-Sprint

What PMs do wrong:

Monday: "Feature A is critical."
Wednesday: "Actually, let's do Feature B instead."
Friday: "Can we do both?"

What engineers hear:

"Your time means nothing to me."

Why it frustrates them: Context switching kills productivity. Constant changes signal you don't know what you're doing.

Frustration 3: Ignoring Technical Constraints

What PMs do wrong:

"This should be easy, right? Just add a button."

What engineers hear:

"I have no understanding of how software works."

Why it frustrates them: Dismissing complexity shows disrespect for their expertise.

Frustration 4: Treating Them Like Order-Takers

What PMs do wrong:

"Just build it the way I said."

What engineers hear:

"I don't value your input or problem-solving skills."

Why it frustrates them: Engineers want to solve problems, not execute orders.

Frustration 5: Taking Credit for Their Work

What PMs do wrong:

Feature ships. PM tells execs "I built this."

What engineers hear:

"Your contribution doesn't matter."

Why it frustrates them: Recognition matters. Stealing credit destroys trust.

The Foundation: Respect Their Expertise

Engineers spent years learning their craft. They know things you don't.

The mindset shift:

  • You're not the boss of engineering
  • You don't know better than them about technical implementation
  • Your job is defining problems, not prescribing solutions

In practice:

Don't: "Build it like this [detailed technical spec]"

Do: "Here's the problem: Users can't see status updates in real-time. What's the best way to solve that?"

Why it works: You give them the problem and outcome. They determine the best technical approach.

Rule 1: Write Clear Requirements

Vague PRDs waste everyone's time.

Bad Requirement

"Improve the dashboard"

Problems:

  • What does "improve" mean?
  • Which metrics matter?
  • What's success?

Good Requirement

"Users need to see their top 5 performing campaigns at a glance so they can quickly identify what's working without opening multiple tabs."

Why it's better:

  • Clear user need
  • Specific outcome
  • Measurable success

The template:

"[User] needs to [action] so they can [outcome]."

Bonus: Add acceptance criteria

  • Must show top 5 campaigns by revenue
  • Must load in <2 seconds
  • Must update when filters change

Rule 2: Respect Their Time

Engineering time is expensive. Don't waste it.

Tactic 1: Batch Questions

Don't: Slack engineers constantly with one-off questions.

Do: Collect questions. Ask in daily standup or scheduled sync.

Why it works: Respects their flow state.

Tactic 2: Do Your Homework First

Don't: "Hey, what's the API endpoint for user data?"

Do: Check docs first. If unclear, then ask: "I checked docs and couldn't find X. Where should I look?"

Why it works: Shows you tried. Doesn't treat them as Google.

Tactic 3: Protect Sprint Scope

Don't: Add requirements mid-sprint.

Do: Hold changes for next sprint unless genuinely critical.

Why it works: Predictability lets them plan and execute.

Tactic 4: Minimize Meetings

Don't: Schedule hour-long status meetings.

Do: Use async updates. Only meet when decisions need discussion.

Why it works: More time coding, less time in meetings.

Rule 3: Involve Them Early

Don't drop fully-formed specs on them.

The Right Collaboration Flow

Phase 1: Problem Discovery (Involve Them)

What you do:

  • Share user research
  • Explain business context
  • Outline constraints

Ask them:

  • "What technical approaches could work?"
  • "What are the trade-offs?"
  • "What am I not considering?"

Why it works: They help shape solution. They feel ownership.

Phase 2: Solution Design (Collaborate)

What you do:

  • Define requirements
  • Propose scope

Ask them:

  • "Is this feasible in the timeline?"
  • "Where's the complexity?"
  • "What would you cut if we needed to ship faster?"

Why it works: Reality-checks your plans. Identifies risks early.

Phase 3: Execution (Support Them)

What you do:

  • Unblock when they hit product questions
  • Shield from stakeholder interruptions
  • Clarify edge cases as they arise

Why it works: You're helpful, not micromanaging.

Rule 4: Understand Technical Constraints (At Least a Little)

You don't need to code, but you need to understand basics.

Learn Enough To Be Dangerous

Understand:

  • Your product's tech stack (what languages, frameworks)
  • Basic architecture (how systems connect)
  • Common technical debt in your codebase
  • What "simple" vs "complex" means for your system

How to learn:

  • Ask engineers to explain architecture
  • Shadow them for a day
  • Read technical docs
  • Sit in on technical design reviews

Why it matters: When you understand constraints, you make better product decisions.

Rule 5: Make Trade-Offs Transparent

Engineers appreciate honesty about why you're prioritizing things.

Bad Prioritization

"Just do it because I said so."

Result: Compliance without understanding. Resentment.

Good Prioritization

"I know tech debt is painful. Here's why I'm prioritizing this customer feature:

  • It's blocking $200k ARR deal
  • Customer committed to annual contract if we ship
  • We can dedicate 20% of next sprint to tech debt afterward

Does that trade-off make sense? What would you do differently?"

Result: Engineers understand context. They appreciate being treated as partners.

Rule 6: Celebrate Their Wins

Recognition costs nothing. Do it often.

When Features Ship

Don't: "Great, we shipped it."

Do:

  • Thank engineering publicly in Slack
  • Highlight technical challenges they overcame
  • Credit them in exec updates
  • Share positive user feedback directly with them

Example Slack Message:

"🎉 Shoutout to @sarah @mike @james for shipping real-time sync. This was technically complex (required rebuilding our websocket layer) and they crushed it. Users are already loving it: [quote from customer]."

Why it works: Engineers feel valued. They'll go the extra mile for PMs who recognize them.

When Things Go Wrong

Don't: "Engineering broke production."

Do: "We had an incident. We've fixed it. Here's what we're doing to prevent it: [action items]."

Why it works: Take blame publicly, give credit publicly.

Rule 7: Learn to Speak Engineering

Translate between business and technical language.

Business to Engineering Translation

Stakeholder says: "We need this ASAP for the big customer."

Don't say to engineering: "Drop everything and build this."

Do say: "Enterprise customer worth $500k ARR needs SSO to close. It's blocking contract signature. Can we prioritize this? What would we need to defer?"

Why it works: Context + respects their input on trade-offs.

Engineering to Business Translation

Engineer says: "This requires refactoring the auth layer. It's complex."

Don't say to stakeholders: "Engineering says it's hard."

Do say: "This touches core security infrastructure. We need 2 extra weeks to do it safely. The alternative is shipping fast but risking user data."

Why it works: Translates technical reality into business terms.

Rule 8: Trust Their Estimates

When engineers give estimates, believe them.

What PMs Do Wrong

Engineer: "This will take 3 weeks."
PM: "Can you do it in 1 week?"

Result: Engineer feels pressured, cuts corners, ships buggy code, everyone's unhappy.

What Good PMs Do

Engineer: "This will take 3 weeks."
PM: "What if we cut scope? Could we ship core functionality in 1 week and iterate?"

Result: Collaborative discussion. Engineer maintains quality. Everyone wins.

The rule: If estimate feels high, ask what drives complexity. Don't just push back with a random lower number.

Rule 9: Shield Them from Chaos

Your job is protecting engineering from distractions.

What to Shield

From Sales

Sales: "Customer wants feature X by Friday or they'll churn."

Don't: Immediately escalate to engineering.

Do:

  1. Validate if customer actually will churn
  2. Explore workarounds
  3. If genuinely critical, bring to engineering with full context and trade-off discussion

From Executives

Exec: "Why isn't feature Y done yet?"

Don't: Forward question to engineering.

Do: Answer it yourself. You're accountable for roadmap.

From Support

Support: "Customer has weird edge case bug."

Don't: Interrupt engineer mid-work.

Do: Triage severity. Batch non-critical issues for review.

Why it works: Engineers can focus. They trust you to handle noise.

Rule 10: Admit When You're Wrong

Mistakes happen. Own them.

When You Misjudge Scope

What happened: You said feature would take 1 week. It took 4.

Don't: Blame engineering for slow estimates.

Do: "I underestimated complexity. That's on me. What can we learn for next time?"

When Requirements Were Unclear

What happened: Engineers built the wrong thing because your specs were vague.

Don't: "This isn't what I asked for."

Do: "I didn't spec this clearly enough. Here's what I should have said: [better requirements]. Can we iterate?"

When You Change Direction

What happened: You pivot after work started.

Don't: Act like it's no big deal.

Do: "I know this is frustrating. I'm changing direction because [data/customer feedback]. I apologize for the wasted effort. Here's what we're doing instead and why."

Why it works: Builds trust. Shows you respect their time even when you mess up.

The Engineering Relationship Audit

Are you a good PM partner? Check yourself:

Green Flags (You're Doing Well)

  • Engineers proactively share ideas with you
  • They ask clarifying questions, not combative ones
  • They volunteer to help scope and design
  • They seem genuinely excited about roadmap
  • They advocate for your priorities in technical discussions

Yellow Flags (Room for Improvement)

  • Engineers seem disengaged in planning
  • Estimates feel defensive ("I said 3 weeks, don't push me")
  • They rarely volunteer ideas
  • You hear complaints through back channels

Red Flags (Relationship Is Broken)

  • Engineers openly push back on every request
  • They build minimum viable versions to "technically" meet requirements
  • High turnover on team
  • They exclude you from technical discussions
  • You hear "the PM doesn't understand" comments

If you have red flags: Have an honest conversation with engineering lead. Ask what needs to change.

Real-World Example: Turning It Around

Scenario:

New PM joins team. Engineering is cold and dismissive.

What the PM did:

Week 1: Listen

  • 1:1s with every engineer
  • Asked: "What frustrated you about past PMs?"
  • Common themes: Vague requirements, changing priorities, no appreciation

Week 2: Set Expectations

  • Shared new working agreement:
    • Pre-reads 24 hours before planning
    • Scope locked once sprint starts
    • PM owns shielding team from interruptions

Week 3: Prove Reliability

  • Sent detailed, clear PRD
  • Involved engineers in solution design
  • Blocked executive request to add mid-sprint scope

Week 4: Show Appreciation

  • When feature shipped, publicly thanked team
  • Sent exec update highlighting technical challenges overcome
  • Bought lunch for team

Result:

After 1 month, team softened. After 3 months, partnership. After 6 months, engineers actively collaborating on roadmap.

Key: Consistency. One gesture doesn't fix it. Pattern of respect does.

Quick Wins to Build Trust

Start here:

This Week

  • Write clearer acceptance criteria on your next ticket
  • Ask engineering lead: "What can I do to make your job easier?"
  • Publicly thank engineer for something they shipped

This Month

  • Shadow an engineer for half a day
  • Read your product's technical architecture doc
  • Protect sprint scope — say no to mid-sprint additions

This Quarter

  • Run retros specifically on PM-engineering collaboration
  • Co-create working agreement with engineering lead
  • Learn enough about your tech stack to have basic conversations

Final Thought

Engineering doesn't need to love you.

But they should respect you. Trust you. Want to work with you.

That comes from:

  • Respecting their expertise
  • Protecting their time
  • Being clear in communication
  • Celebrating their wins
  • Owning your mistakes

Start today.

Write better requirements. Block an interruption. Thank someone publicly.

Small actions compound.

In six months, you'll have engineers who don't just tolerate your requests.

They'll actively help you build something great.