⚙️Working with Engineering
Engineers respect specifics, technical curiosity, and honesty about trade-offs. They lose patience with vagueness and changed minds.
Engineering is your most expensive resource and the team you'll spend the most time with. PMs who earn engineering's trust ship faster, get higher-quality output, and have better careers. PMs who don't get blocked at every turn.
Engineers want a PM who is specific, technically curious, decisive, and honest about trade-offs. They tolerate (and even appreciate) pushback when the PM has done the homework. They lose trust fast when the PM is vague, changes scope mid-sprint, or hides bad news.
The things engineers care about
- Specifics over vagueness. "Fast" is meaningless; "p95 < 200ms" is workable.
- Technical curiosity, not technical condescension. You don't need to write code, but you should understand the system well enough to ask the right questions.
- Stable scope. Mid-sprint scope changes destroy trust. If you have to change scope, do it openly and acknowledge the cost.
- Decisive trade-offs. When the engineer says "we can do A in 2 weeks or B in 6," answer quickly. Indecision wastes their time.
- Air cover. When sales/exec pressure hits, you're the buffer. The engineer shouldn't be in those meetings.
- Honesty about bad news. Slipping launch? Tell them first, not in the all-hands.
What erodes trust fastest
- Promising something to a stakeholder without checking with engineering first.
- Mid-sprint priority changes without explanation.
- Taking credit for engineering's work.
- Not reading the technical docs they wrote for you.
- Vague PRDs.
How to earn technical credibility
You don't need to write code, but:
- Understand the architecture. Get the senior engineer to draw the system on a whiteboard. Take notes.
- Read the docs. Architecture decision records, post-mortems, internal wikis.
- Sit in some engineering reviews. Not all — that would be a waste. Three per quarter.
- Use the developer tools your team builds. If your product has an API, hit the API yourself. If it has a CLI, learn the commands.
- Get curious about the constraints. When the engineer says "the database can't handle that query at scale," ask 'why specifically?' and learn.
Working with the tech lead
The tech lead is your peer in the trio. They make the call on the technical approach; you make the call on the product approach. Negotiate at the seam.
The pattern: weekly 1:1, 30 min. Agenda includes: open product questions, open technical questions, what we're each worried about, what we need from leadership. Run it for 6 months and you'll be one of the most-trusted PMs in your org.
Real-world examples
Stripe famously hires PMs who can read code and write technical PRDs. The expectation isn't that they'll commit code, but that they can hold a real technical discussion. Engineers at Stripe report this materially changes their PM relationships — they don't have to over-explain.
Go deeper — recommended reading
Interview questions (2)
Q1How do you build trust with your engineering team?behavioralmid▼
Four things I do consistently:
- Write specific PRDs. Vague specs are the #1 trust killer. I include acceptance criteria, edge cases, and what's out of scope.
- Be decisive on trade-offs. When engineers come to me with 'A in 2 weeks or B in 6,' I respond within a day, with reasoning.
- Don't change scope mid-sprint. If I have to, I do it openly with the team and acknowledge the cost — I don't pretend it's free.
- Provide air cover. When sales escalates a feature request, I'm the buffer. I take the meeting; the engineers stay focused.
The cumulative effect: engineers start volunteering to take harder projects with me, because they know I won't waste their time. That's the leverage.
Q2Tell me about a time your engineering team pushed back on a deadline. What did you do?behavioralmid▼
Last quarter we'd committed to shipping an integration in 6 weeks. At week 3, the tech lead pulled me aside and said the third-party API was less reliable than expected — they were now estimating 10 weeks, not 6.
I didn't argue. I asked three questions:
- What's the longest pole? — Auth handshake under load.
- What would a v0.5 look like? — Could ship core integration without bulk operations in 7 weeks.
- What would it take to hit 6 weeks? — Wasn't feasible without doubling headcount.
I then went to the stakeholders with three options: ship v0.5 at week 7, ship full at week 10, or descope. I recommended v0.5 because the bulk-ops use case was a 20% segment and we could fast-follow. Leadership agreed.
We shipped v0.5 at week 7, full at week 11. The engineering team trusted me more after that conversation because I'd taken their input seriously and translated it into a real decision instead of pressuring them to commit to an impossible date.