Working with Engineering
Working with Engineering
The PM-engineer relationship is one of the most consequential dynamics in software development. When it works well: the team builds the right things at a sustainable pace, engineers are creative participants in problem-solving, and technical reality shapes product decisions constructively. When it breaks down: feature factories ship code nobody uses, engineers feel like ticket-closers rather than craftspeople, and product direction is disconnected from technical reality.
What Engineers Need from PMs
Clear problem definitions. Engineers do their best work when they understand the user problem and the outcome goal, not just the specified solution. "Users can't find their past orders" gives an engineer room to suggest a faster, simpler solution than "Build a new 'Order History' navigation item with a table sorted by date." The former provides context; the latter removes the engineer's creativity.
Prioritised, groomed backlogs. Work should arrive at engineering with clear requirements, acceptance criteria, and a known priority. Vague stories, changing priorities mid-sprint, and "urgent" requests that bypass planning create chaos that tanks velocity.
Respect for technical constraints. Engineers know things PMs don't: what makes a system fragile, where technical debt makes new features disproportionately expensive, what's trivially changeable and what requires careful migration. Good PMs listen to these signals and factor them into priority decisions.
Protection from scope creep. Mid-sprint scope changes are expensive — they disrupt engineering flow and make sprint commitments meaningless. PMs protect the team from scope additions during sprints by deferring non-urgent requests to the next planning cycle.
What PMs Need from Engineers
Honest estimates. Story point estimates should reflect actual complexity and effort, not the estimates PMs want to hear. A culture where engineers are penalised for revising estimates upward creates systematic underestimation and missed dates.
Technical input on product decisions. Engineers often see solutions and constraints PMs miss. A PM who says "we can't add that feature because the current architecture makes it technically infeasible in the next 2 sprints" is more honest and useful than a PM who makes a commitment and lets the team scramble.
Flagging technical debt early. When new work is building on a fragile foundation, engineers should surface this during planning, not after the sprint starts. Delayed disclosure is the most common cause of sprint failures.
Completed work that meets acceptance criteria. Features done to 90% and then marked complete to make the sprint goal create downstream problems. The Definition of Done exists to prevent this.
Agile Ceremonies and Their Purpose
Sprint Planning — PM presents the prioritised backlog; the team commits to a subset they can complete in the sprint based on velocity. The PM explains why items are prioritised; engineers ask clarifying questions and surface concerns before committing.
Daily Standup — 15-minute status check: what did you complete, what are you working on today, what is blocking you? Blockers are flagged and resolved outside the standup. The PM's role is to unblock — resolving dependencies, making decisions, answering questions.
Sprint Review / Demo — the team demonstrates completed work at the end of the sprint. Stakeholders and PMs give feedback. Incomplete work is not demo'd. This is a feedback loop, not a performance review.
Retrospective — the team reflects on the sprint process: what went well, what to improve, what to try next sprint. PM participates as a team member. Retrospectives are the primary mechanism for process improvement.
Technical Decisions PMs Should Understand
PMs do not make architecture decisions, but they need enough technical literacy to participate in conversations about:
Build vs Buy: Should we build this capability or use an existing tool/service? Involves cost, time, flexibility, and vendor risk trade-offs.
Monolith vs Microservices: Affects how fast new features can be independently deployed and scaled. Relevant to roadmap sequencing.
API Design: The interface between the product and external systems. PM input on API design affects the product's integration ecosystem.
Testing Strategy: Unit tests, integration tests, end-to-end tests. PM should understand that under-tested code increases maintenance cost and slows future development — this is not purely an engineering concern.