Books › Technical Program Manager roadmap
Best books for Technical Program Managers (TPMs)
Program management for engineering organisations, where every dependency sits with a team you do not manage. The list begins with how software projects run and why they slip (scoping, estimating, flow). It then covers influence without authority, systems thinking, difficult conversations, slack and written plans. The final set covers large multi-year programs and how engineering leaders structure teams.
12 books in 3 stages, about 3,450 pages (at least 86 hours of reading). The notes are ours, with no ratings or sales claims.
How to choose your books
A short method, so you read the right book for where you are instead of the longest list.
Find your stage
Getting started · 4 books
How software projects run and run late: scoping, schedules, honest estimates and where delivery work gets stuck.
Jump to this stage ↓Doing the job · 5 books
The cross-team craft: getting help from people who do not report to you, seeing why a program keeps slipping, and writing plans others can rely on.
Jump to this stage ↓Senior and leading · 3 books
Large programs and organisation design: forecasting from reference classes and fixing dependency pain that comes from team structure.
Jump to this stage ↓
If you are unsure, start one stage lower than you think. Books in a later stage assume the working knowledge the earlier ones give you.
Begin with one book
Our starting pick
Making Things Happen: Mastering Project Management
by Scott Berkun · 2008
Written by a former program manager, it covers the practical mechanics (specs, schedules, decisions, keeping a team moving) that you need in your first cross-team project.
See the book ↓Then pick by your situation
Choose the next book by the problem in front of you, not by its place in the list.
If engineers and executives keep giving you numbers that do not agree
read Software Estimation (getting started)
If your main blocker is people who do not report to you
read Influence Without Authority (doing the job)
If you are running a large, multi-year program
read How Big Things Get Done (senior and leading)
Set a time budget
| Stage | Books | Pages | Reading | At 3 hrs a week |
|---|---|---|---|---|
| Getting started | 4 | 1,460 | 37 hrs | 12 wks |
| Doing the job | 5 | ≥ 1,100 | ≥ 28 hrs | ≥ 9 wks |
| Senior and leading | 3 | 890 | 22 hrs | 7 wks |
| All 3 stages | 12 | ≥ 3,450 | ≥ 86 hrs | ≥ 29 wks |
Treat this as a ceiling, not a target. Read one book at a time, apply it, then move on; read reference-style books in sections. Totals are approximate.
Judge any book before you buy it
Age
This list runs from 1975 (The Mythical Man-Month) to 2023 (How Big Things Get Done). Older books earn their place by teaching principles that do not change. For tools and platforms, buy the latest edition.
Level
Check the stage before the title. A book from a later stage will make sense only once you have faced the problems it solves.
Format
Some books suit reading start to finish; others work as references. Read the reference-style ones in sections, when a problem calls for them.
Fit
Ask what you will do differently the week after you finish. If you cannot answer, the book is for a different moment. Come back to it when the situation arrives.
Getting started
How software projects run and run late: scoping, schedules, honest estimates and where delivery work gets stuck.
Start hereMaking Things Happen: Mastering Project Management
by Scott Berkun · 2008
~400 pages~10 hrs to read
A practical guide to running software projects: scoping, specs, schedules, decisions and keeping a team moving, written by a former Microsoft program manager. A good first read when you take over your first cross-team project.
View book →
The Mythical Man-Month: Essays on Software Engineering
by Frederick P. Brooks · 1975
~320 pages~8 hrs to read
Essays on why large software projects run late, including the cost of adding people and the communication overhead of big teams. Read it early to understand the schedule pressure you will be asked to manage.
View book →
Software Estimation: Demystifying the Black Art
by Steve McConnell · 2006
~310 pages~8 hrs to read
Explains how to estimate software work, express uncertainty as ranges and tell an estimate from a target. Useful when engineers and executives give you numbers that do not agree.
View book →
The Phoenix Project
by Gene Kim, Kevin Behr, George Spafford · 2013
~430 pages~11 hrs to read
A novel about an IT organization in crisis that introduces flow, work in progress and handoffs between teams. An easy way to see where delivery work gets stuck before you have a framework for it.
View book →
Doing the job
The cross-team craft: getting help from people who do not report to you, seeing why a program keeps slipping, and writing plans others can rely on.
Influence Without Authority
by Allan R. Cohen, David L. Bradford · 1990
~320 pages~8 hrs to read
A method for getting help from people who do not report to you: work out what each side values and trade accordingly. Central to a TPM job, where every dependency sits with a team you do not manage.
View book →Thinking in Systems: A Primer
by Donella H. Meadows · 2008
~220 pages~6 hrs to read
An introduction to feedback loops, delays and leverage points in complex systems. Helps you see why a program keeps slipping in the same place and where changing the process matters more than pushing harder.
View book →
Crucial Conversations: Tools for Talking When Stakes Are High
by Kerry Patterson, Joseph Grenny, Ron McMillan, Al Switzler · 2001
~300 pages~8 hrs to read
Techniques for raising hard issues when opinions differ and emotions run high. Useful for the conversations a TPM has to start: a slipping date, a missed commitment, a disagreement between two leads.
View book →
Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency
by Tom DeMarco · 2001
~260 pages~7 hrs to read
Argues that an organization with no spare capacity cannot change or respond to surprises. Worth reading before you commit a team to a plan that has no buffer.
View book →
Docs for Developers: An Engineer's Field Guide to Technical Writing
by Jared Bhatti, Heidi Waterhouse · 2021
Covers planning, writing and maintaining technical documents, including design docs, release notes and process documentation. Helps when your main output is the written plan, status update or decision record others rely on.
View book →
Senior and leading
Large programs and organisation design: forecasting from reference classes and fixing dependency pain that comes from team structure.

How Big Things Get Done
by Bent Flyvbjerg, Dan Gardner · 2023
~360 pages~9 hrs to read
Draws on a large database of projects, from buildings to IT, to explain why big projects overrun and how planning and reference-class forecasting reduce that risk. For TPMs who run large, multi-year programs.
View book →
An Elegant Puzzle: Systems of Engineering Management
by Will Larson · 2019
~290 pages~7 hrs to read
Essays on team sizing, org design, migrations and engineering strategy. Gives senior TPMs a view of how engineering leaders think about the same constraints you plan around.
View book →
Team Topologies: Organizing Business and Technology Teams for Fast Flow
by Matthew Skelton, Manuel Pais · 2019
~240 pages~6 hrs to read
Describes four team types and three interaction modes for organizing teams around fast flow of change. Useful when dependency pain comes from how teams are structured rather than from any one project.
View book →
Book links go to Amazon and are affiliate links. As an Amazon Associate I earn from qualifying purchases.
Frequently asked questions
Which book should a Technical Program Manager read first?
Making Things Happen: Mastering Project Management by Scott Berkun. Written by a former program manager, it covers the practical mechanics (specs, schedules, decisions, keeping a team moving) that you need in your first cross-team project.
Do I need to read all 12 books?
No. The list is a menu, not a syllabus. Find your stage (getting started: 4, doing the job: 5, senior and leading: 3), begin with one book (we suggest Making Things Happen: Mastering Project Management), then pick the next book by the problem you are facing at work. Come back to the others when the situation they cover arrives.
How long does it take to read these books?
The 11 books with a known page count add up to about 3,450 pages, roughly 86 hours at 1.5 minutes a page. At three hours a week that is about 29 weeks; at six hours a week, about 14. The list is meant to be read over time, one book at a time, not in one run.
Are these books up to date?
They range from 1975 (The Mythical Man-Month) to 2023 (How Big Things Get Done). Older titles are included because they teach principles that have not changed; for tools and platforms, we favour recent editions. Check the edition before you buy.
Related reading
Some links are affiliate links: we earn a small commission if you buy, at no cost to you. It does not change what we list.