Skip to content
Core craftboth

Working with engineering

Earning trust with the people who actually build it.

The short version

You own the what and the why; engineering owns the how. The partnership works when you bring crisp problems, real context, and clear priorities — and stay out of implementation. The PMs engineers trust are the ones who explain the customer and the rationale, make decisions fast, clear blockers, and never pretend to know more about the build than the people building it.

Why it matters

A PM controls almost nothing directly — you deliver through engineers who do not report to you. If they trust your judgment and understand the why, they build better things faster and flag risks early. If they do not, you get malicious compliance: exactly what you specified, and nothing more.

The architect/builder split is the model: you frame the problem with clarity (the spec, the customer, the priority), and engineering decides how to construct it. Trust is the currency, and it is earned by being a good requester — organized, responsive, honest about trade-offs — not by being the smartest person about the code.

How to be a partner engineers trust

01
Bring the why, not just the what. Explain the customer problem and rationale. Engineers who understand intent build better and catch your mistakes.
02
Own the problem, not the solution. Specify outcomes and constraints; let engineering choose the implementation. Resist designing the architecture.
03
Make crisp, timely decisions. Ambiguity and slow answers are the most expensive thing a PM ships. Decide, clear blockers, escalate when stuck.
04
Ask, do not assume, on estimates. Get effort from the people doing the work; ask "why is this big?" and "what are the risks?" to understand, not to push back.
05
Respect operational reality. Balance feature delivery with system health and tech debt; protect time for "keeping the lights on."

Common mistakes

✕

Specifying the how — handing engineering a solution instead of a problem.

✕

Being a disorganized requester: vague asks, moving targets, slow responses.

✕

Treating estimates as negotiations to win rather than information to understand.

✕

Ignoring tech debt and system health until it becomes a velocity crisis.

In a startup

The line between PM and engineer is blurry and that is fine — you may write specs in a Slack thread and the engineer may own product calls. Trust is built through proximity and shipping together, not process.

In an enterprise

You likely work through an SDM and possibly a TPM. Learn who owns what (SDM = engineer manager/gatekeeper, TPM = cross-team plan + translation) and use the right partner for the right ask. Roles may be merged on smaller teams.

Quick check

Optional — test the lesson. Nothing is gated.

1. In the architect/builder model, what does the PM own?

2. What is the most expensive thing a PM can "ship" to engineering?

Continue the path

Next concept →

Influence without authority

Related perspective →

AI-DLC: the validation crisis