Three axes to match on
- Domain — does the PM know the industry vocabulary? A construction PM dropped into healthcare IT will spend the first quarter learning HIPAA and EHR systems instead of running the project.
- Lifecycle preference — does the PM operate well in waterfall (long planning, fewer surprises) or agile (continuous re-planning, comfortable with change)? Mismatched, the PM fights the team or fights the sponsor.
- Operating style — process-heavy vs. relationship-heavy. Both are legitimate; some projects (regulated, contractual) need process-heavy; others (cross-functional consumer software) need relationship-heavy.
When to bring in a senior PM
McConnell argues that the cost of a senior PM on a complex project is rarely the bottleneck — the cost of putting a junior PM on it is. Senior PMs cost more per hour but spend fewer hours getting to the same outcome, and they prevent large categories of failure that junior PMs only learn from experiencing.
↳ the easiest mismatches to catch
A PM who's only ever shipped enterprise software running a consumer launch. A PM whose entire career has been in agile tech put in charge of a regulated infrastructure rollout. The PM is competent — the org chose the wrong project for them.
What about the PM choosing the project?
PMs early in their career often take whatever they're assigned. Senior PMs increasingly choose. The right pattern as you grow: be honest about your domain depth and operating style, and turn down assignments where the mismatch will cost the org more than your tenure can recover.