Design an engineering excellence review for PMs

PMs Who Can Read Engineering Health Build Better Products

PMs who rely only on subjective velocity impressions get blindsided by maturity issues — on-call burnout, test coverage decay, cycle time regression — that eventually break delivery. GitHub's research on developer productivity, The Pragmatic Engineer on engineering effectiveness, and Atlassian's agile metrics all converge on the same rubric: shipping velocity, quality, on-call load, collaboration, and growth.

How the Design an engineering excellence review for PMs Prompt Works

The prompt structures a quarterly review with the EM partner across five dimensions, with trend data per dimension and 1-sentence evidence. The "metric I'd bet against next quarter" output makes the PM a credible partner in engineering conversations — one who can spot risk before it manifests.

When to Use It

• You sense delivery is slipping and want to have a structured conversation.
• A new EM partner is joining and you want a shared baseline.
• Leadership is asking for engineering health data and you have no framework.
• On-call load has risen and the team is showing strain.
• A quarter ended and you want a ritual review before planning the next.

Common Pitfalls

• Measuring only velocity. Velocity without quality and on-call context is a vanity metric.
• No trend data. Point-in-time metrics say nothing. Trend vs. last quarter is the signal.
• PM reviews without EM partner. Eng health is a shared conversation. Running it solo produces adversarial dynamics.

Sources

• GitHub Developer Research — GitHub
• The Pragmatic Engineer Newsletter — Gergely Orosz
• Agile Metrics — Atlassian
• Begin with Trust — Harvard Business Review