I really wanted to like this book, and to be fair, the book's predecessor The Phoenix Project was kind of ground breaking in the sense that when it was first published, DevOps movement was still in its early days. It talked about concepts like Three ways (principles for DevOps processes), four types of work for any work center in an organization etc. In a nutshell, that book taught me a lot. I expected something similar from the Unicorn Project as well, but to no avail, Unicorn Project doesn't live up to the expectation.

Good

To be honest, this book definitely contains some gems. The "Five Ideals" are really good and make sense for any kind of work that is software (and many other fields as well, probably) related. Let me list them here for potential readers to evaluate for themselves whether to read the book or not:

• Locality and Simplicity→ this is really important in any software project, this is where tech debt usually accumulates and makes your software a big pile of mess in a couple of iterations if not taken good care.
• Focus, Flow and Joy→ I guess this is an important benchmark for any kind of work. If you don't (or can't) focus on your work, you can't have flow and without flow, there'll be no joy in it. The resulting work will be most affected by this situation.
• Improvement of Daily Work→ This feels like author just ripped it from Three ways in the first book. It is what it says on the tin actually. If you don't improve daily work constantly, things will degrade definitely.
• Psychological Safety→ Again, this is also from Three ways. You don't even have to explain, but no one can deny how crucial this is for every organization's wellbeing.
• Customer Focus→ This is a very obvious but also a very important one as software people sometimes tend to lose focus of the customer and delve into other areas.

There are also some really good points about horizons for large organisations and context vs core concept for company goals and operations. Unfortunately these are quickly discussed at the end of the book and we don't get much detail on these. But basically it states that large organisations always have to be on the lookout for the new opportunities and ways of working and different value propositions for customers. As Marx and other people also point out, given a certain business, profits always tend to decrease because of price reductions by other players and technological advances. So, companies need to reinvent themselves again and again, continuously. Also the nudge for functional programming and Clojure in particular was nice, and it really plays to the first principle oflocality and simplicity. What is functional programming if it's not about keeping things local and pure and Clojure is the flagship of simplicity in programming languages.

Bad

But then, what is not good? For starters, the story is the same! I thought we'd have the same characters but a different project but I forgot that the Unicorn project was present in the first book as well. It's basically a data science project and all the supporting software and infrastructure around it to create campaigns for high margin products (which means not selling that much and waiting at the stores, occupying space) around holiday periods! I think the author should have done right by his readers and tried to invent a new story.

There are some new protagonists in the book, sure. The main character is a "10x programmer" who can fix errors in database drivers (not open sourced, reverse engineered from binary) and save the day, again and again! For such a stellar career at the company she's been working for some time now, she's blamed for an outage which is clearly not her fault and exiled to a different department where all the magic happens. This wouldn't happen in real life (fortunately). But then she starts a new journey, gets over obstacles after obstacles and reaches the nice ending of the book with a breeze.

So the rest of the book is that utopian as well. Teams are getting autonomy one by one, and every project they do is just successful! No one talks about alignment, schedules and goals of different teams. And before all of this shenanigans they were living in a soft of software dark ages, where none of the teams had a working CI, test environments etc. So every tiny change is such a game changer for them. I guess this is what happens when you want to summarize changes happened over 20 years in an industry, in book that spans 6 months at most.

Cringy stuff

Apart from the fact that every engineer in the book is more or less an engineering rockstar, author used the supporting Erik character again to dump information, which is fine. But this time there's the "sensei" title to everyone whom Erik talks about and this is a bit cringing. But this time around there's no military references of the personnel which is an improvement.

Verdict

All in all, it's a good book but unfortunately it doesn't live up to the legacy of the predecessor The Phoenix Project. I wished the author didn't rush to write a new book and came up with a more persuasive story and detail the important bits more.