Project management as an engineering manager

When you become an engineering manager, you don’t leave project management behind.
In fact, you often end up doing more of it, especially if your company doesn’t have dedicated PMs.

That means you need to be comfortable with estimates, scope, and communication on top of everything else.

Product vs. project vs. engineering management

It helps to draw a line between roles.

Product managers define what's being done and how it relates to the business. Engineering managers define the path to delivery. Project managers focus on execution, or getting work from A to B.

As I explained it on the podcast:

“Product managers define the what and the why. Engineering managers define the who, the how, and the when. Project managers focus on execution.”

Roadmaps don’t age well

Six-month plans look good on paper, but rarely hold up.

A better approach is to:

• Set a longer-term vision
• Break it down into quarterly or six-week chunks
• Reassess frequently so you can adapt

This makes planning honest and execution more achievable.

Estimating capacity is messy but necessary

Neither of us is a fan of t-shirt sizing. It’s vague, and it puts pressure on people to estimate in real time.

What works better:

• Building spreadsheets for “perfect engineering days”
• Factoring in vacation, onboarding, holidays, and the reality that engineers don’t code 5 days a week
• Adding confidence ratings to show which estimates are shaky

It’s not perfect, but it forces you to face tradeoffs before work starts.

Scope creep is inevitable

Scope creep isn’t a failure. It’s negotiation.

You have to decide:

• Which changes are dealbreakers worth delaying for
• Which can wait for a fast follow
• Where to draw a line in the sand

Being flexible with boundaries is the sweet spot.

Communicate constantly

Projects fall apart when communication stalls. A few strategies we’ve found useful:

• Weekly syncs with engineers, product, and design
• Midpoint retrospectives that stay blameless but surface risks
• Async standups or project docs to cut down on meetings

The exact cadence depends on your team’s maturity. More self-managed teams may need less; newer or more junior teams often need more structure.

Try this

Next time scope creep threatens to derail a project, pause and ask:
What’s the business case for adding this now instead of after launch?

You may still take it on, but you’ll have made the tradeoff explicit.

What to read

📚 Start with Why – Simon Sinek’s classic on motivation and purpose.
📚 Measure What Matters – John Doerr’s guide to OKRs and tying projects back to strategy.

Listen to the full episode: Project Management as an Engineering Manager