For a while now I’ve been meaning to read a book that was highly recommended by another developer: The Phoenix Project by Gene Kim, Kevin Behr and George Spafford. On my recent holiday, I finally got round to reading it, and its sequel, The Unicorn Project. It possibly wasn’t the lightest reading for a holiday but both books were interesting and enlightening and I thought I would share some of my takeaways.

So what are the books about? They tell the story of a retail company that is losing ground to its competitors. They’re trying to launch a new online product that aims to revitalise the business, but are struggling with years of technical debt, fragile systems, and demanding stakeholders.

While the Phoenix Project tells the story from the perspective of a newly appointed VP of Operations, the Unicorn Project tells it from the perspective of a Senior Developer.

At first glance, as a developer looking at that statement I would have assumed that the Unicorn Project would resonate more with me personally based on my skillset, but actually the Ops and DevOps perspective was the book I found more engaging.

I’m not going to talk at great length about the concepts the books cover. Instead I’m going to cover some of the parallels I found myself drawing against my career so far. Some of these points might seem obvious to you, or you might be dumbfounded that companies still work like this in 2025 - but I can guarantee that they do.

First, I want to cover the “Urgent Work” cycle that occurs at a lot of companies. Have you ever worked at a company, where everything you build is urgent? You know you have a fragile codebase, littered with temporary (now permanent) solutions to problems from days gone by, but you have no time to fix the issues. You’re too busy dealing with BAU tasks and last minute requests.

In the Phoenix Project, this silent killer is labeled as “Unplanned Work” - and it gave a name to something that I’ve seen happen time and time again but never been able to label. Last minute features or requirements being dropped on teams due to poor planning or foresight, or just arbitrary deadlines that have come down from on-high. This isn’t just “busyness” - it’s a failure of production workflow. You find yourself in a vicious cycle.

The system is fragile or broken, but you have no time to fix it as you’re too busy building new features or dealing with BAU. So you build on top of the already shaky foundations. The system becomes more fragile, and even slower to work with. The vicious cycle continues as you add layers to the ‘crap onion’ you’ve constructed.

Speaking of fragile systems, have you ever gone into a codebase only to find that it takes a week or longer to get your machine set up for local development? You spend your time trying to run the project, hitting a snag, asking around to find the correct magic incantation that resolves the issue. If you’re lucky, you just have to sort this the one time. If you’re unlucky, every time you go to run the application you find yourself asking around for the latest magic incantation.

Good news! You’ve made your change, performed the witchcraft to test it locally, and you’ve merged it in. So now it’s going to your test environment and live, and all that will happen in a matter of minutes? Hours? Days? What about weeks? I’ve seen code merged that has taken over a month to get to live as it fights its way through the pipelines.

It finally gets there, you find yourself sat hovering over the deploy button that sends it to live. But how confident are you feeling? This release has over a month’s worth of code changes in it including changes to logic critical to how the business makes money. You click deploy, a change made by another team explodes, you find yourself rolling it back and looking for the nearest ledge to jump off.

If you’re lucky enough to never have experienced the above cycle, I envy you. The inefficiency in development is obvious, and I’m sure if you have experienced it you’ll be well aware of how slow it is to deliver features. No doubt you have irritated stakeholders asking why things are taking so long. When you’re trying to fix these cycles though, I’ve always heard the same reasons - faster delivery, more stable applications, etc.

The Unicorn Project though really highlighted to me the mental impact of these cycles on developers. When you’re in a situation like this it’s common to see high churn. The next time I’m in a situation like this, I’ll be doing my best to highlight this as a benefit.

The last thing I wanted to call out was the term Complexity Debt. Everyone has heard the phrase “tech debt”, but up until reading these books I’d never heard of Complexity Debt. So what’s the difference between the two?

Tech debt is the code written quickly now, knowing it’s going to cause you pain in the long run. A short cut here, missing documentation there, with the plan that you will come back and tidy it up later. It’s a debt that you’re going to pay back. Unfortunately, there’s often times not a collector, so the urgency to pay it back doesn’t exist. Instead, in my experience at least, it lives forever until it reaches critical mass, and you enter the death spiral of spending all your time firefighting and dealing with unplanned work.

Complexity debt builds on this concept, but shifts focus away from purely technical concerns and takes into consideration the business structures as well. What happens when a feature spans multiple teams? Or even just touches another team’s area of expertise?

I’ve seen first hand an example of this. Team A added a new flag to the user record that could be set by customer support. Team B wanted to use that flag to show a notification. Somehow Team C then got pulled into the mix to add an API endpoint that could be used. Why couldn’t Team B just do it? That’s complexity debt in action.

Siloed teams, bureaucratic processes, and the time and effort it takes to coordinate multiple teams, all take away from the time that could be spent doing productive things like writing code.

In my view, technical debt is a much easier thing to blame for problems. Things are slow due to poor historic decision making, or rushing and not having the time to pay off the debt. Very few people tend to be willing to discuss that organisational issues are actually the problem. Instead, tech debt is played and the cycles continue. In the future I’ll be trying to avoid this trap.

This post is already getting fairly long, so I’m going to end it here. Overall, I think the two books are great and I’d highly recommend them. As standalone books, the Phoenix Project is the stronger of the two in my view. It felt less rushed, the characters felt more developed, and generally it just resonated more with me.

I would recommend every developer read the Phoenix Project, and if you enjoy it consider picking up the Unicorn Project as well. If you’re not a dev, but you’re in a leadership position at a tech company, I would still highly recommend reading the Phoenix Project. It will give you great insight as to why delivery can be slow, and what you can do to help.