Work has kept me busy, and writing here has had to wait. I’m glad to be back, starting with a practical question: when delivery is stuck, do you need a book that helps people see the problem, or one that helps them change how teams work?
That is the useful distinction between The Phoenix Project and Team Topologies. They belong in the same conversation, but I would not hand them out as interchangeable answers to “we need to move faster”.
My short answer: start with The Phoenix Project when you need a shared diagnosis of queues, interruptions and bottlenecks. Start with Team Topologies when the decision is about responsibilities, dependencies and how teams should interact. You do not have to finish the first to earn permission to open the second. The question in front of you decides the order.
What each book helps you do
The Phoenix Project
Gene Kim, Kevin Behr and George Spafford tell a fictional story about Bill, an IT manager at Parts Unlimited trying to rescue a troubled project. The novel introduces constraints, the Three Ways and four types of work as ways to understand a delivery system. The publisher’s overview sets out that scope.
The novel form is its advantage. A request to measure unplanned work can sound like another reporting obligation. A story about urgent work repeatedly displacing planned work gives people something concrete to discuss. The conversation can move from “why is that team slow?” to “what keeps arriving, and where does it wait?”
I would use it to open that conversation, particularly with a stakeholder who sees a missed deadline and reaches straight for the hiring plan. More people may be the right answer. First establish what is limiting delivery; otherwise you may simply put more work into the same queue.
What I would not ask the novel to do is choose your team boundaries. Recognising a bottleneck does not, by itself, tell you which responsibilities to move or how to divide a shared service.
Team Topologies
Matthew Skelton and Manuel Pais provide a vocabulary for designing teams and their interactions. The four fundamental types are stream-aligned, enabling, complicated subsystem and platform. The three interaction modes are collaboration, X-as-a-Service and facilitation. Cognitive load matters because there is a limit to the complexity a team can usefully carry. The authors’ key concepts explain these together, not as an exercise in drawing a new reporting structure.
This site’s review covers the 2019 first edition. A second edition was published in 2025. This comparison concerns the core approach, not a verdict on what changed between editions.
The useful design question is more specific than “do we need a platform team?” It is: which responsibility should another team take on so that this team can deliver without carrying unnecessary complexity? Then ask how those teams will work together. A new name on the organisation chart answers neither question.
Diagnose the conversation before recommending the book
Consider two different complaints.
“We just need more engineers.” Perhaps you do. But if nobody can describe where a recent change waited, which interruptions displaced it, or which person every difficult request depended on, I would start with The Phoenix Project. Use it to make a shared diagnosis possible, not to prove that the hiring request is foolish.
“Every change needs three teams, and the platform is another ticket queue.” Here I would start with Team Topologies. You have a concrete dependency to examine. Does the consuming team need a service it can use independently, temporary help acquiring a skill, or close collaboration while a boundary is being worked out? Those are different needs. Calling all of them “alignment” does not help anyone decide what to do on Monday.
If you are unsure which complaint fits, trace one recent change from request to release with the people who did the work. Mark the waiting, interruptions and handovers. Then ask what you disagree about. Is it the existence or cause of the delay, or what to change about the teams involved?
That exercise is not a diagnostic instrument with a pass mark. It is a way to avoid prescribing a book before you know what conversation it needs to support. An organisation can need both conversations at once.
What using the wrong book looks like
Start with team labels before a shared problem and you risk topology theatre. The infrastructure group becomes “the platform”, product teams become “stream-aligned”, and the same requests still wait for the same approvals. The vocabulary has changed; the work has not.
That is a misuse of Team Topologies, not a requirement of it. The authors’ team interaction modelling guidance explicitly allows existing teams to remain undefined when they do not fit the model. It starts with understanding the current situation rather than forcing every team into a tidy box.
Go the other way and you can use a novel to postpone a decision. If everyone already agrees that a shared service is creating delays, another discussion about bottlenecks may add little. At some point someone has to decide what the service offers, who owns it and which decisions its users can make without opening a ticket.
I would be wary of any reading programme that keeps the conversation safely abstract. A reading group can agree with everything while changing nothing.
The limits worth keeping in view
The Phoenix Project is fiction, not evidence that a particular intervention will work in your organisation. The plot can make a useful idea memorable; it cannot settle whether your actual constraint is staffing, funding, a technical dependency or a policy nobody has authority to change. Use the story to ask better questions, then look at the work.
Team Topologies supplies a model, not the authority to act on it. A sensible boundary change can still require budget, agreement over ownership or a change to how people are rewarded. I would write those requirements beside the team design rather than leave them as someone else’s implementation detail.
Neither book makes disagreement disappear. Nor should it. A proposal that reduces one team’s load by quietly handing it to another deserves an argument, however neatly the diagram is labelled.
Turn the reading into one decision
If you need both books, I would use this sequence:
- Agree on the problem. Use The Phoenix Project where its story helps. Write down one delay or interruption pattern you want to change, using a recent example rather than a general complaint about productivity.
- Describe a different interaction. Use Team Topologies to work through what each team would own, what it could stop doing and what it would need from the other team. Keep the scope smaller than a wholesale reorganisation.
- Make the proposal testable. Name the decision owner and a sign of improvement: fewer handovers for that change, less waiting on a particular service, or fewer interruptions to the team doing the delivery. Revisit it with both teams rather than declaring success when the new names appear.
Suppose a product team needs an infrastructure ticket for every test environment. The first question is whether that queue is materially delaying its work. If it is, the next question is whether a supported self-service option would remove the wait without making the product team operate another platform. That is a specific proposal to assess. “Become more DevOps” is not.
For the wider reading sequence, see the enterprise architecture book guide. But do not turn a problem involving two teams into a requirement to read ten books first.
Which I would choose
Choose The Phoenix Project when the missing piece is a shared understanding of why work gets stuck. Choose Team Topologies when you need to change team responsibilities and interactions. Read both if both questions are live, and skip the preliminary persuasion if the people involved already agree.
The useful outcome is not a room that can recite four team types. It is a room that can name one thing it will change about how work gets done.
Questions about choosing between the books
- Should I read The Phoenix Project or Team Topologies first?
- Start with The Phoenix Project if you need a shared diagnosis of queues, interruptions and bottlenecks. Start with Team Topologies if your immediate decision concerns team responsibilities and interactions. Neither is a prerequisite for the other.
- Are the books about the same thing?
- They overlap around improving delivery, but work differently. The Phoenix Project uses a fictional story to make problems in the flow of work recognisable. Team Topologies offers a model for team responsibilities, interactions and cognitive load.
- Do I need to reorganise before using Team Topologies?
- No. Begin by understanding an existing team interaction and the problem you want to improve. The authors' modelling guidance allows teams to remain undefined where they do not yet fit the model; relabelling every team is not the starting point.