Best Books for Engineering Managers: Nine That Stuck

I have been an engineering manager at three companies, scaled teams from four engineers to thirty-five and change, and written one book about doing it. Which makes me exactly the person you should be suspicious of when I hand you a reading list.

So here is the list, ranked for one specific reader: an engineer who has been managing for under two years, or is about to start. Not for a VP. Not for someone running a four-hundred-person org. If that is you, the ordering below is wrong and the books are still fine.

An engineering management reading list is a set of books ordered for a stage of the job rather than for general merit, because the book that helps a first-time manager and the book that helps a manager of managers are almost never the same one.

The ranking is not by quality. It is by how quickly a book changes something you do on a Monday.

I picked these nine on one test — whether the book changed something I actually did with a team — and I earn a commission on every book link on this page, plus an author royalty on the one book here that I wrote myself.

That second part matters more than the first. From Code to Culture is my book. Buying it pays me twice: once as an Amazon Associate and once as the author. I have put it at number seven, behind six books I would hand you before I handed you mine, because a roundup where the author's own product wins is not a roundup, it is an ad with footnotes.

The other bias worth stating: my experience runs from four engineers to about thirty-five, mostly frontend, growth and platform-adjacent teams at health and learning companies, plus fractional CTO work since. I have led a four-person senior frontend team and a five-person team while still writing code daily. I have never run a division. Where a book on this list is about scale beyond thirty-five people, I am recommending it on reasoning, not on scar tissue.

A brand-new engineering manager should read The Manager's Path first, because Camille Fournier structures the book as one chapter per rung — mentor, tech lead, manager, director, VP — and the chapter above yours is a preview of decisions you are about to be handed.

The more useful advice is about volume. Do not read four management books in your first quarter. Read one, apply it badly, and re-read it at month six when the abstractions have names and faces attached.

This is the same trap engineers fall into with architecture. Watching people learn system design taught me that reading produces recognition while rebuilding produces judgement, and management books are worse than architecture books in this respect, not better. You cannot rehearse a difficult one-on-one on a canvas.

The genuinely first thing to read is not a book at all. It is your own company's engineering ladder document, if one exists, followed by the last two performance cycles for everyone who now reports to you. Those tell you what your organisation actually rewards. Fournier tells you what the job is supposed to be. The gap between the two is your real job description.

These eight sit behind The Manager's Path, ordered by how quickly each one changes a decision rather than by how good it is. Two are great books; the rest are useful books, which for a manager is the higher compliment.

An Elegant Puzzle is the book that stopped me making obvious scaling mistakes twice, because Larson treats an engineering organisation as a system with measurable constraints rather than a collection of relationships to be managed by feel.

It is also the only book on this list that hands you numbers you can act on. Larson's guidance is that a manager supports six to eight engineers, that fewer than four makes you a tech lead manager in practice whatever your title says, and that a manager of managers supports four to six managers. To create a new team, he suggests growing an existing one to eight or ten and then budding it into two teams of four or five.

Team Topologies is worth reading because it gives you four team types and three interaction modes, and a whole category of organisational dysfunction stops being a vague bad feeling once you can name it.

The mechanism is Conway's Law taken seriously: your systems end up shaped like your communication paths. That is not an abstraction to me. The feature that reads a GitHub repository and draws its architecture works by running Conway's Law backwards — manifests, compose files and CI configs preserve the boundaries the org agreed to, and it flags two services pointing at the same database as a smell. That smell is usually two teams that never settled a boundary.

Skip it if you are one team and expect to stay one team for a year. The vocabulary only pays off when there is more than one team to name.

Accelerate is the book to bring to the meeting where someone senior proposes measuring engineers by story points, because it replaces your opinion with four years of survey research covering more than 23,000 responses, according to its publisher IT Revolution.

The four metrics — deployment frequency, lead time for changes, change failure rate, and time to restore service — have held up remarkably well since 2018. They have also moved on: DORA's later reports renamed time to restore service as failed deployment recovery time, and the 2025 report reframed team performance around seven team profiles.

Read it for the argument, not the dashboard. The point of Accelerate is that throughput and stability are not a trade-off in high-performing organisations, which is the single most useful sentence you can quote at someone who wants to slow you down for safety reasons.

The SRE book earns its place on a management list for one chapter's worth of ideas: error budgets convert the argument between shipping fast and staying up from an opinion into arithmetic that both sides have already agreed to.

That is a management tool, not an ops tool. It is the difference between "product wants to ship and infra says no" and "we have spent eighty percent of the quarter's budget, so the next two weeks are stability work." Nobody has to win.

Staff Engineer is the most honest account of the senior individual contributor track I have read, largely because the interviews in it contradict each other and the book has the confidence to leave the contradictions in.

For a manager, its use is narrow and important: read it before you promote someone into a staff role, so that you write the job description first instead of reverse-engineering one after the fact. Half the staff-engineer unhappiness I have seen comes from a title granted with no agreement about what it means.

From Code to Culture is my own book, so weigh everything in this entry accordingly: I earn a royalty on it in addition to the affiliate commission that funds every other link on this page.

It covers hiring, culture, and the transition from writing code to building the organisation that writes it, at startup scale specifically. I wrote it because the advice I got as a new manager was either abstract enough to be useless or scaled for companies a hundred times the size of mine. There is a fuller and less flattering comparison against Fournier further down this page.

The Phoenix Project is the worst-written book on this list and I still recommend it, for exactly one reason: it is the only book here that a non-technical executive will actually finish.

The novel framing is divisive and the dialogue is rough. But getting a CFO to understand work-in-progress limits and the cost of unplanned work is worth a great deal, and no whitepaper has ever achieved it. Treat it as a gift, not a study text.

Refactoring belongs on a management list because a manager's real leverage over code quality is vocabulary rather than commits, and this is the catalogue that supplies it.

Once "extract function" and "replace conditional with polymorphism" mean the same thing to everyone on the team, code review stops re-litigating the same shapes every sprint. At Kyruus I led a four-person senior frontend team through an Ember-to-React migration — the kind that sounds simple in a meeting and takes six months in reality. What cut production incidents there by seventy percent was not tooling. It was monitoring, error tracking, and a review culture that actually caught things, and shared naming is what makes that kind of review culture cheap enough to sustain.

Three books get pushed at new engineering managers constantly and should not be: Designing Data-Intensive Applications, Clean Architecture, and Domain-Driven Design. All three are on my shelf. All three are the wrong shelf for someone who became a manager last month.

The pattern is the same in each case. They are technical books, and a new manager reaching for a technical book is usually reaching for evidence that they have not stopped being an engineer. That instinct is understandable and it costs you the one year in which reading about people would have compounded.

Domain-Driven Design deserves the sharpest version of this. It assumes a domain complex enough to be worth modelling, and most products are nowhere near that. A manager who mandates DDD across a team that has not earned the complexity has just added a vocabulary tax to every pull request, and the team will comply, because you are the manager.

Clean Architecture is the one I disagree with in parts and still recommend — to architects. Its failure mode in a manager's hands is being cited rather than read. If you have not sat with the dependency rule long enough to argue against it, do not use it to settle someone else's design review.

And Designing Data-Intensive Applications is genuinely the book I have re-read the most. That is precisely why the recommendation is dangerous. It is the most enjoyable way for a new manager to spend a month not learning their new job.

Read for the problem in front of you, not for the level on your business card: the shape of the job in the first six months, the shape of the system between six and eighteen months, and the shape of other managers after that.

The cell people argue with is the first row's last column. Org design books are extremely pleasant to read when you do not yet have an org, and reading them early reliably produces a manager who restructures a five-person team into a four-team topology because a book told them to.

From Code to Culture covers hiring and culture-building at startup scale — the stretch where a team goes from a handful of engineers to a few dozen and nothing is written down yet — which is the exact stretch the better-known management books pass through quickly on the way somewhere else.

Here is where it loses. Fournier's book covers rungs I have not personally stood on: director, VP, and the politics of a large organisation. Mine stops where my experience stops, at roughly thirty-five engineers. Larson's book has better systems thinking and sharper numbers. If you can only read one book about becoming a manager, read The Manager's Path, and I say that knowing exactly what it costs me to say it.

What mine has that the others do not is failure at a specific scale. It includes the parts that did not work, in the situations where a startup manager actually stands: hiring when you cannot compete on compensation, culture when there is no HR function, and the transition from being the person who ships to being the person who makes shipping possible.

The one thing I would add now, which the book does not contain: the culture claim has research behind it. Google's Project Aristotle, published on its re:Work site, studied team effectiveness across Google and found psychological safety to be the strongest of five factors — ahead of who was actually on the team. Culture is not the soft complement to engineering rigour. It is an input with a measured effect size.

None of these books teaches you how to manage a team where most of the code arrives from a model, how to decide a product question that has no technical answer, or when to ship nothing at all.

The first gap is the biggest and it is new. Google's 2025 DORA report, published in September 2025 and based on responses from nearly 5,000 technology professionals, found that ninety percent report using AI at work, that AI adoption now shows a positive relationship with software delivery throughput, and that it continues to show a negative relationship with delivery stability. That is a management problem with no chapter written about it: your throughput improves and your failure rate follows it up, and the fix is in review capacity and testing rather than in anything the books call process.

The second gap is product judgement. When I built DateSafe I decided that a millisecond of extra spinner was a security bug, because a duress PIN that visibly behaves differently from a real one is not a duress PIN. No management book contains that call. They can tell you how to run the meeting where it gets made and how to disagree well inside it, which is genuinely useful, and then the call is still yours.

The third is the discipline of shipping nothing. ResolveMesh launched with a deliberately empty catalog because no discovered tool had cleared its evidence bar, and publishing the numbers that justified an empty launch was harder than shipping a full one would have been. Every book here optimises for throughput. None of them has a section on the quarter where the honest output is a documented no.

So: read Fournier, then argue with Larson, then buy The Phoenix Project for someone in finance. Everything I have recommended here and elsewhere, including the technical books I just told you not to read yet, is on the bookshelf with the same skip-it-if notes attached. The list is short on purpose. Nine books is roughly a year if you actually apply them, and applying two beats finishing nine.