Lesson 37: Working with Engineering Teams

Lessons 31 through 36 gave you the mechanics of Agile execution — the frameworks, ceremonies, and release practices a PM operates within. But mechanics alone don't produce a functioning team; the quality of the actual working relationship between a PM and the engineers building the product does. This lesson addresses that relationship directly, because it is simultaneously one of the highest-leverage and most commonly mishandled parts of the job. A PM with excellent prioritization judgment (Lesson 29) and flawless Sprint mechanics (Lesson 34) can still fail completely if engineers don't trust their judgment, feel dictated to rather than collaborated with, or are handed solutions instead of problems.

This lesson also closes a loop opened in Lesson 32's Case Study, where a cross-team resourcing blocker required escalation beyond what the team's own retrospective process could solve — this lesson gives you the specific judgment for knowing which problems belong to the team and which require the PM to act as an escalation point on the team's behalf. The underlying theme across this entire lesson is one this curriculum has returned to since Lesson 1: a PM's authority comes from the quality of their judgment and their trustworthiness as a partner, not from positional authority they don't actually hold over engineering. Nowhere is that truer than in the day-to-day working relationship this lesson covers.

Learning Objectives

1
Explain why "giving context, not commands" produces better technical outcomes than specifying a solution directly, and connect this to INVEST's "Negotiable" criterion from Lesson 34.
2
Describe the specific behaviors that build or erode engineering trust in a PM over time, distinguishing durable trust from one-off goodwill.
3
Apply a technical-disagreement resolution approach that respects engineering's authority over "how" while preserving the PM's accountability for "why" and "what."
4
Distinguish problems a team can resolve internally from problems that require PM/PO escalation outward, extending the distinction raised in Lesson 32's Case Study.
5
Explain the Iron Triangle (scope, time, quality) and use it to reason about trade-off conversations with engineering under real constraints.

This lesson assumes Lesson 1's foundational framing of the PM as having "responsibility without authority" — this lesson is, in many ways, a direct application of that idea to the single most important working relationship a PM maintains. It also assumes Lesson 32's role distinctions (Product Owner owns value/backlog, Developers own the how) and Lesson 34's INVEST criteria, specifically the "Negotiable" principle that a well-formed backlog item states a need rather than a pre-specified technical solution — this lesson extends that principle from how items are written to how a PM behaves in conversation with engineers more broadly.

Give Context, Not Commands

The single most consequential shift a new PM can make in how they work with engineers is moving from specifying solutions to specifying problems, context, and constraints — then trusting engineering to own the solution space. This is not a matter of etiquette; it reflects a genuine asymmetry in expertise. A PM typically has the clearest view of the user problem, the business context, and the constraints that matter (deadline pressure, dependencies, strategic priority); engineers typically have the clearest view of the technical trade-off space (what's actually hard, what's actually cheap, what technical debt a given approach would create). A PM who hands over a fully-specified technical solution is, in effect, making decisions in a domain where engineering has more information — and is very often specifying a worse solution than engineering would have proposed with the same context.

This does not mean a PM should have no opinion on technical approach, or should never ask a clarifying or challenging question about a proposed solution. It means the PM's questions should test whether a proposed approach actually serves the stated problem and constraints, rather than substituting the PM's own preferred implementation for engineering's.

What Builds (and Erodes) Engineering Trust

Trust between a PM and an engineering team is built cumulatively, through specific, repeated behaviors, and eroded quickly by their absence:

Builds Trust	Erodes Trust
Explaining the "why" behind a request, not just the "what"	Handing over tickets with no context, expecting silent execution
Protecting the team's focus by pushing back on low-value mid-Sprint interruptions	Constantly introducing new "urgent" requests without prioritization discipline
Accepting engineering's estimate and technical judgment by default	Second-guessing every estimate or technical call without domain expertise to back it up
Escalating blockers the team can't solve on its own (Lesson 32's Case Study)	Leaving structural blockers unaddressed and blaming the team for resulting delays
Being honest about uncertainty and changing plans transparently (Lesson 31, Lesson 34)	Presenting an uncertain plan as a firm commitment, then quietly walking it back later

Trust, once established, gives a PM significant benefit of the doubt during a genuinely difficult trade-off conversation; trust, once eroded, makes even a reasonable request from the PM subject to skepticism and resistance.

Resolving Technical Disagreements

A specific, recurring situation deserves its own framework: what happens when a PM and engineering disagree about the right approach to a problem. The healthiest pattern separates the conversation into two distinct questions, asked in order:

Do we agree on the problem, the user need, and the constraints? If not, the disagreement is actually about "what" and "why" — squarely the PM's domain — and should be resolved there first, before any technical discussion proceeds.
Given agreement on problem and constraints, which technical approach best satisfies them? This is squarely engineering's domain. A PM can and should ask clarifying questions here ("does this approach still meet the timeline we discussed," "does this handle the edge case we identified"), but should generally defer to engineering's judgment on the actual technical trade-offs once the problem and constraints are aligned.

Most unproductive PM-engineering disagreements occur because the two questions get conflated — a PM pushing back on a technical approach is often, without realizing it, actually revealing an unresolved disagreement about the underlying problem or constraints, which is better surfaced and resolved directly rather than fought out indirectly through a debate about implementation details neither side fully owns from the other's side.

Escalating What the Team Can't Solve Internally

Recall Lesson 32's Case Study: a cross-team design-resource blocker recurred across eight consecutive retrospectives, unsolved, because it required PO escalation outward rather than an internal process fix. This lesson generalizes that distinction: some problems (unclear requirements, internal process friction, estimation disagreements) are genuinely within a team's power to resolve through its own Scrum or Kanban practices; others (a shared resource bottleneck, an organizational dependency, a conflicting priority set by another team's leadership) are structural, and no amount of internal team process will fix them. A PM's job includes correctly identifying which category a given blocker falls into, and taking ownership of escalating the structural ones — since failing to do so leaves the team blocked indefinitely while quietly absorbing blame for a problem that was never theirs to solve alone.

The Iron Triangle

A classical framing, useful in trade-off conversations with engineering: any piece of work can be described along three dimensions — scope (how much is being built), time (how quickly it must ship), and quality/resources (how much rigor, testing, and polish goes into it). The core claim of the Iron Triangle is that these three dimensions are interdependent: fixing any two effectively determines the third, and demanding all three be fixed simultaneously (more scope, faster, with no quality trade-off) is not a request for hard work — it's a request that violates the triangle's basic arithmetic.

This framing gives a PM a clean, respectful way to have a trade-off conversation under deadline pressure: rather than simply demanding "more, faster," name explicitly which side of the triangle is flexible — is scope negotiable (can something be cut), is time negotiable (can the deadline move), or is quality genuinely the dimension being knowingly traded down (with the resulting risk made explicit and accepted).

Common Mistakes to Avoid

Handing engineering a fully-specified technical solution instead of a problem and constraints

As covered in Theory, this substitutes the PM's judgment for engineering's in a domain where engineering typically has more relevant information, often producing a worse outcome than trusting the team with the actual problem.

Second-guessing engineering estimates without new information to justify it

Pushing back on an estimate simply because it's inconvenient, without offering new context that might genuinely change the estimate (a simplified scope, a different approach, new information about urgency), erodes trust and rarely produces a more accurate number — it usually just produces a falsely optimistic one.

Treating every blocker as the team's to solve internally

As covered in Theory, some blockers are structural and require PM escalation; a PM who reflexively tells a blocked team to "just figure it out" when the blocker is genuinely outside the team's control leaves the team stuck and erodes trust in the PM's willingness to advocate for them.

Demanding fixed scope, fixed time, and fixed quality simultaneously under deadline pressure

This is the Iron Triangle violation described above — a request that isn't really a request for harder work, but an implicit demand that one of the three dimensions quietly gives way (usually quality, and usually invisibly, in the form of accumulating technical debt or reduced testing) without ever being named or agreed to explicitly.

Conflating disagreement about the problem with disagreement about the technical solution

As covered in Theory, unresolved disagreements about the underlying problem or constraints often surface, confusingly, as arguments about implementation details — resolving the wrong layer of disagreement (arguing about code architecture when the real disagreement is about which user need matters most) wastes time and rarely produces genuine alignment.

Mental Model

The Trust Ladder

This lesson's core takeaway tool visualizes engineering trust as a ladder that a PM climbs through repeated, consistent behavior, and can fall down quickly through a small number of trust-eroding actions:

Use the Trust Ladder as a diagnostic whenever a working relationship with engineering feels strained: which rung is actually in question? A team that doesn't trust a PM's basic reliability (Rung 1) needs a different remedy than a team that trusts the PM personally but has seen structural blockers go unaddressed (Rung 4) — treating every trust problem as if it's the same problem, at the same rung, tends to apply the wrong fix.

Quick Reflection Checkpoint

Key Takeaway: How will you apply "The Trust Ladder" when evaluating trade-offs in your product decisions?

Working with Engineering Teams