What engineers actually need from PMs, managers, and platform teams

Executive overview

PMs and engineers frustrate each other in predictable, fixable ways. Engineers disengage when they feel uncredited, micromanaged on ideas, or treated as code-execution machines. The same pattern drives over-engineering and unnecessary rewrites.

Camille Fournier — author of The Manager's Path, ex-CTO at Rent the Runway — lays out a clear framework: fix the PM-engineer relationship, earn mastery before moving into management, and build platform teams that operate like product teams.

The core insight: creative people who are locked out of problem-solving will find an outlet somewhere — usually in the wrong place.

What PMs do that most annoys engineers

• Hoarding credit — PMs are the front-facing voice for initiatives; engineers feel invisible. Fix: step back, let engineers present their own work.
• Dismissing technical details signals a lack of empathy, even when you don't need to understand every detail.
• Playing telephone — relaying questions you don't fully understand adds delay and loses information. Connect people directly when it's happening repeatedly.
• Monopolising ideation forces engineers to find creative outlets elsewhere — usually over-engineering or premature rewrites.
• The best PMs are not threatened by engineers having product ideas; they channel them.

Why engineers push for rewrites (and why rewrites usually fail)

• Engineers who feel creatively excluded redirect energy into technology choices and architecture debates.
• Rewrites are almost always sold as liberation from a painful legacy system; they rarely deliver.
• Migration from old to new is massively underestimated — every time, by every team.
• The old system must still be supported while the new one is built.
• Legacy systems contain undocumented business logic that only reveals itself when you try to replicate it.
• If a system doesn't need new features and isn't harming the business, a full rewrite is hard to justify economically.
• Prefer staged evolution: identify a well-contained component, uplift it, validate, repeat.

Engineering leadership: staying technical as you move up

• Don't leave hands-on technical work until you have genuine mastery — the kind where a long break leaves you rusty but not lost.
• Technical leaders don't need to dictate library choices; they need to ask good questions and guide decisions.
• Build a network of hands-on engineers and stay genuinely curious about what they're worrying about.
• Surround yourself with smart technical people and listen to them talk through real problems.
• Loss of interest in what engineers care about may be a signal to reassess your role.

When to move from IC to engineering management

• Aim for ~10 years of hands-on coding before making the leap — more than most people expect.
• For underrepresented engineers especially, internal confidence from mastery matters before taking the risk.
• If you're still enjoying writing code, don't rush the transition.
• Being pushed into a project manager role early is not the same as a path to real engineering leadership.

What surprises new engineering managers

• You no longer own your time — your team, your manager, and the company do.
• Management is a service role, not an authority role.
• Command-and-control doesn't work in tech; engineers expect to be convinced, not ordered.
• The job is mostly nudging, setting guardrails, and enabling — not making every decision.

Rethinking one-on-ones

• One-on-ones with direct reports and your manager: hold these sacred, weekly or biweekly.
• One-on-ones with every peer, stakeholder, and cross-functional partner do not scale.
• If a stakeholder doesn't want the meeting, you're burning both calendars for nothing.
• One-on-ones with multiple stakeholders hide disagreement — unhappy stakeholders don't see that others are satisfied.
• For stakeholder management at scale, group forums surface divergent views more honestly.
• Respect your own time: more meetings is not the same as more productive.

Building a focused work culture

• Overwork is often a proxy for avoiding the hard question of what actually matters.
• Regular audits of where time goes are necessary — priorities shift, but without auditing you won't notice.
• Delegation feels costly upfront but is the only way to scale; people often surprise you.
• Focused, bounded hours force prioritisation; forcing a hard stop is a useful discipline.
• If you would never cut anything, you probably aren't cutting enough.

Platform teams: what they are and when to build one

• Platform engineering = developing and operating platforms that manage system complexity and deliver leverage to the business.
• Includes: CI/CD tooling, cloud infrastructure, developer experience, internal frameworks, billing platforms, storage systems.
• Don't start before ~50 engineers. Early signals: same problems being solved redundantly across teams; developer productivity visibly bottlenecking shipping.
• Platform teams require software engineers (not just SRE/DevOps), systems engineers, and product managers.
• Without PMs, platform teams build what seems technically cool rather than what solves real internal problems.
• PM-to-engineer ratios run higher than in product teams — much of the work is deeply technical and doesn't need a product spec.

Working with a frustrating platform team

• Platform teams are often slow, impose adoption, and struggle to show ROI — this is a real and common problem.
• Find the parts of the team that are working well and invest in those relationships first.
• If they lack a PM, product-manage them yourself: be explicit about your problems and what you need.
• Anger and avoidance make it worse in the short term; clarity about needs is the fastest path to improvement.

What makes a great platform team

• Think in outcomes, not outputs: reduce cycle time, unblock launches, cut infrastructure costs.
• Platform projects run longer and are more complex than agile product sprints — plan accordingly.
• Migrations are unavoidable and painful; teams that handle migrations smoothly create real value.
• Stakeholder management is the hardest part — platform teams must justify their existence continuously to peers, executives, and product.
• Leaders who want only the fun technical problems will struggle in platform leadership roles.

Succeeding as an engineer or PM on a platform team

• Engineers: half the job is operational excellence, not just shipping code. Care about scale, reliability, and migration quality.
• PMs: your job is often "past one" — taking something proven in one application team and making it available to all.
• Zero-to-one builders may be happier elsewhere; if you like stabilising, scaling, and evolving, platform is a good fit.