Best Books for Engineering Managers and CTOs Building Real Teams

Here’s a secret about being an engineering manager that nobody is going to tell you until you’re in it. There is no license for this job. There is no certification, no board exam to take. There is no university diploma that says, “Congratulations, you are now qualified to be responsible for the livelihoods of five other people.”

You learn how to write code. Someone gives you a team. And you figure out what you don’t know as quickly as possible, usually while a building is burning down.

Reading is one of the last short-cuts available to you. It isn’t a replacement for taking your team through a disaster, but it does give you the opportunity to borrow years of someone else’s experience before you have to gain that experience yourself. I’ve been an engineering manager for over 20 years at three different companies. I have overseen a nine-figure acquisition, and I have overseen situations where we almost went under. I don’t think that anybody is actually taught how to do this well.

Here is the list that I would hand to any new engineering manager, or a CTO that wants to level up their game. Most of these lists are missing one thing: AI has changed what this job is, and many of the books have not caught up with that change.

Where a book’s thesis still stands up, I’ll mention that. Where I think AI has changed what a book means today, I’ll mention that too.

1. The Mythical Man-Month

In 1975, Fred Brooks wrote The Mythical Man-Month about an IBM mainframe project.

We still recommend it constantly because his main argument never got old: adding manpower to a late software project makes it later. Communication costs increase quicker than work output when you add more people. This is also why software projects run over their planned schedule more often than most people anticipate.

Brooks’ theory was that a system with conceptual integrity, i.e., designed by one person or a few people, is better than one designed by many. Even if they’re all excellent programmers.

Now that we have AI coding assistants, it’s easy to forget this law. When you can get working code in a matter of seconds, you think you suddenly have infinite resources. Just hire one more person, one more engineer, and the capacity problem is solved.

There was no shortage of people back then either. The problem was getting everyone on the same page, on the same design, with the same reasoning. Teams that don’t agree on the system design will write more code, faster, but it’ll still be wrong code.

And AI hasn’t solved this problem; it’s actually made it worse. Wrong code is shipped even quicker.

2. Team Topologies

This is the most useful book on how to actually structure an engineering org that I’ve read. Matthew Skelton and Manuel Pais present four types of teams. Stream-aligned teams take ownership over a full vertical slice of the business. Platform teams create a platform for others to build upon. Enabling teams help other teams improve their skills. Complex subsystem teams handle the one place in the product that truly needs deep domain expertise. And underpinning it all: the idea that we should design our team boundaries deliberately around the cognitive load they’ll be asked to carry rather than letting them arise out of some org chart.

The deeper insight here is more relevant than ever: Conway’s law says that any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure. This is the “inverse Conway maneuver,” where we design our organization intentionally to arrive at the architecture we actually want.

This might be the most relevant book on this list today, with one big exception. AI changes what a stream-aligned team can do without needing help from a platform or enabling team, and it decreases how much of that complex-subsystems work still needs to be handled by a dedicated team of specialists.

Those specialists still have a job. It shifts toward reviewing AI’s output in those tricky areas instead of building everything from scratch by hand, the same “wrong code ships faster too” issue from the Mythical Man-Month section, just wearing a team-architecture hat instead of an individual one.

Anyone who tries to reorganize their company around AI tools in 2026 without this book’s vocabulary will do it the painful, redundant, expensive way, just as I have seen firsthand while helping scale engineering teams at three different companies.

3. The Manager’s Path

The Manager’s Path by Camille Fournier ascends the ladder one chapter at a time: engineer, tech lead, manager, director, VP, or CTO. Each chapter describes what skill transition is necessary for the next rung. It’s at the top of almost any list of “best engineering management books” and that’s precisely why we have our engineering career ladder.

Readers consistently point to how honestly it treats each stage. There’s a massive jump from writing code to managing people who write code, and this book never pretends otherwise.

That ladder is compressing. Things that used to take a manager months, writing a first-pass performance review, drafting a development plan, calibrating feedback across a team, AI can now produce in minutes. The job isn’t getting any easier.

What shifts instead is the key question at every rung, from “can you produce the artifact” to “do you have the judgment to catch when an AI-drafted one is wrong.”

Fournier’s framework still holds. Just what counts as a basic skill and where the leadership really happens has shifted.

4. Accelerate

Nicole Forsgren, Jez Humble, and Gene Kim spent many years researching DORA and published the following four metrics that can be used to determine how well an organization will perform: deployment frequency, lead time for changes, mean time to restore, and change failure rate.

The takeaway that caused this book to get cited by every engineer was not “Ship faster.” The real takeaway was that these four numbers either all move together in a well-functioning team, or they pull apart in a dysfunctional one. A team with both a high deployment frequency and a high failure rate is just dressing up chaos as speed.

AI coding assistants can easily drive those first two metrics higher. Pay attention to the change failure rate and mean time to restore as the amount of code generated by AI increases. This will show you if you’re going faster, or if you’re just running faster toward disaster.

5. The Phoenix Project and The Unicorn Project

In The Phoenix Project, Gene Kim co-authored a book with Kevin Behr and George Spafford that is written as a story about a floundering IT team. He later wrote The Unicorn Project alone, which takes the same scenario and tells it from the developer’s side. They’re both examples of business fiction. And that’s why the DevOps crowd keeps bringing them up again, even after everyone’s long since picked up the core concepts inside them. They show how things look from the inside: unseen work stacking up, heroism replacing procedures, in a way a list of frameworks simply can’t capture.

If you plug in an AI tool to a dysfunctional process and hope for it to fix it, it’ll do exactly what the novels say it will.

AI doesn’t fix processes. It magnifies them. For one team that’s already being honest about tracking unplanned work, AI will help them close that hole quicker. For another team that’s masking unplanned work through heroic actions, AI will just give them more to cover up, perpetuating the same rescue-me cycle that the books tell us about, just on different platforms. A third team that was already struggling to handle unplanned work will continue to struggle with it even more quickly, now with the added benefit of better auto-complete.

6. Co-Intelligence

Only one of the books on this list is about actually using AI in your work: Ethan Mollick’s. His most famous concept is the jagged frontier: AI is great at some things and terrible at things that seem just as easy from the outside. The first draft of a code review might be great. But the first draft of a timeline for a production-outage postmortem, written by the same AI on the same day, might omit the one piece of information that actually matters. There’s no clear boundary between “AI can code” and “AI can’t code.” It depends on the specific job at hand, and that line shifts as the models improve.

For an engineering leader, that’s the actual decision every week: what gets handed to AI, and what stays with a human who understands the tradeoffs. That line moves every few months as the models improve, so treat this as a snapshot of where things stand today, not a fixed map. It’s become the go-to mental model for engineering leaders trying to make that call without guessing.

7. Product Driven

This is one I wrote. I’ll be upfront: none of these six books completely address the issue that was haunting me across three companies. Engineers who wrote great code, but still delivered the wrong thing. Teams that were always busy every sprint, yet never built the right thing.

As I put it in the book itself: “The problem isn’t code quality or technical skill. It’s product thinking.”

The book is built around five pillars: Vision, Focus, Clarity, Ownership, and Courage. This one lands at the end of the list on purpose, not because it’s a plug.

AI is making “can we build it” almost trivial. The only question left standing is whether we know what to build, and why. Product Driven was arguing that same point long before AI came along and made it impossible to ignore.

I started out as a 22-year-old college dropout trying to build software for car dealerships I didn’t understand well enough. I co-founded VinSolutions, which was acquired for $147 million in 2011 as the number one CRM in the auto industry. Then I founded Stackify, and now I’m the founder of Full Scale. And at every stage, the reason a team failed traced back to nobody having a reason to care about the result, not the quality of their code.

The best books for engineering managers, side by side

Book	Author(s)	Core idea	What AI changes about it
The Mythical Man-Month	Fred Brooks	Adding people to a late project makes it later	AI makes capacity feel free; the real bottleneck is shared understanding, not typing speed
Team Topologies	Skelton & Pais	Design team boundaries around cognitive load, not org charts	Reshapes what a stream-aligned team can own without help
The Manager’s Path	Camille Fournier	The specific skill shift at each management rung	AI drafts the artifacts faster; judgment becomes the real differentiator
Accelerate	Forsgren, Humble, Kim	Four DORA metrics predict org performance	Watch failure rate and MTTR as AI-generated code volume rises
The Phoenix Project / The Unicorn Project	Kim, Behr, Spafford (Phoenix); Kim (Unicorn)	What DevOps dysfunction actually looks like from inside	AI amplifies whatever process already exists
Co-Intelligence	Ethan Mollick	The “jagged frontier” of what AI is actually good at	The practical framework for deciding what to hand to AI
Product Driven	Matt Watson	Most engineering problems are product-thinking problems	More true now that “can we build it” stopped being the hard question

Every new hire at Full Scale gets this book as part of onboarding, engineering leads included but not limited to them. The same question applies at every level: can this person tell you what they’re building and why.