Book review: the Unicorn Project by Gene Kim
How to save a company from drowning
It’s probably sacrilege to review the Unicorn Project before tackling its big brother, the Phoenix Project, but I’ve read the Phoenix Project twice already and didn’t want to crack it open again just for a review - if that’s something you’d be interested in though, let me know!
If you’re not familiar with this series of books, they are works of fiction about software engineering and are sort of written like parables - the books are fun and easy to read but afterwards you feel like you’ve learned something. The Phoenix Project is about the broader view of an engineering organisation and how different departments should work together, whereas the Unicorn Project is about the zoomed in view and how engineering teams should operate to maximise not only productivity but also joy in their daily work, which is important when it comes to avoiding burnout.
About the author
Gene Kim hails from Portland in the US and has written several books about software engineering, most notably The Phoenix Project, but he's also written some other highly esteemed books like The DevOps Handbook (which I've also read and would recommend) and Accelerate (this one is still on my TBR - book review coming soon, I'm sure). This guy is clearly interested in helping large enterprises run smoothly because that's the subject most of his books address. He's got plenty of real world experience to back up his ideas, because he founded Tripwire in 1999, a company specialising in enterprise security software, and was their CTO for 13 years before he got into writing books.
The TL;DR
NOTE: This section contains spoilers, so don’t read it if that bothers you!
In the Unicorn Project, we meet a highly skilled Senior Engineer called Maxine who has unjustly been blamed for a payroll disaster at Parts Unlimited, the company she works for and the same company featured in Gene Kim’s previous book, the Phoenix Project. In fact, we learn that Maxine has been used as a scapegoat and has been re-assigned to the eponymous Phoenix Project, with promises of being allowed back if she behaves (i.e. keeps her head down). Maxine reluctantly agrees and chaos immediately ensues: she can’t get access to a Phoenix Dev environment due to all the red tape, developers are off working on their own features and hoping to put them all together in a big bang release and the project is scheduled to go live before it’s even complete due to an overly keen SVP who wants everyone to just “make it work” (we all know someone who’s dealt with someone like Sarah).
Maxine runs into a very helpful colleague called Kurt who magically makes her problems go away; he gets her all the documentation, build keys and environments that she needs, which means she can finally get somewhere. Kurt proceeds to invite her to an evening at a nearby bar and it’s here we meet “the Rebellion” - an elite group of engineers who are hoping to overthrow “the Empire” and get the Phoenix Project all fixed up and out the door. While at one of the rebellion meetings, Maxine meets the enigmatic Dr. Erik Reid, who should sound familiar if you've read the Phoenix Project - he's the one who tells Bill Palmer all about "the three ways". It just so happens that he is working as a bartender at Dockside, the bar where the rebellion meets.
Erik introduces Maxine and the rebellion to the five ideals:
Locality and simplicity - the idea that all teams should be able to contribute to a project independently i.e. engineers on one team shouldn't have to get other teams involved in their work to get things done. The key here is to make sure software systems are not "complected" together - in the book this likened to getting three strands of yarn and plaiting them together. Now, in order to make changes to one strand, you have to make changes to the others, which is in contrast to just having those three strands hang loose. Decoupling systems is definitely something we strive to do in engineering because it makes changing things so much simpler.
Focus, flow and joy - implementing the first ideal allows engineers to work in small batches while getting fast and continuous feedback on their work. This makes them feel productive and therefore joyous because they're not having to sit around waiting for things to happen. There is nothing worse than making some code changes, only to pass things "over the wall" to QA who then need to test things and pass it back for fixes. Big bang releases are more risky and result in firefighting and burnout, so engineers should be able to release small incremental changes almost constantly. This allow them to focus on what they're good at: solving problems with code.
Improvement of daily work - this one is all about paying down tech debt and improving working practices as you go rather than blindly following processes because "we've always done it this way". Making small incremental improvements on a daily basis as part of your standard workflow will stand you in good stead for the future and questioning how things are done makes good sense too - just because things feel familiar, doesn't mean it's the right thing to do. It's easy to dismiss making improvements to developer workflows because it's not feature work, but doing so will make feature work much faster and more efficient, which will pay off in the end.
Psychological safety - in order to question the status quo, psychological safety is absolutely tantamount. How can you see what's going wrong if no-one feels able to speak up? The example the book keeps bringing up is Toyota and their "andon cord", an actual physical cord that allows anyone on the assembly line to stop production immediately to point out an issue. This person is thanked for their insight, because they have stopped the issue in its tracks and therefore stopped it from becoming something more urgent.
Customer focus - ensuring that everything you do is for the customer means they will be delighted with you and will be happy to spend their hard earned cash on your products. The book goes into why you should spent money on "core" work (i.e. building the things your company is good at) and outsource "context" (the stuff that is holding up your company but your customers have no interest in like build pipelines for instance) and the fact that experimentation is key to keeping your customers happy. Trying out new initiatives and seeing how they go, stopping them if they're not helpful and supporting them if they are will allow you to create new revenue streams all while increasing the happiness of your customers. And increased customer happiness means more money - you basically can't lose.
Maxine is at the forefront of implementing these five ideals so we get to watch exactly how Parts Unlimited develops as a company thanks to the five ideals. I'll leave it there because I don't want to completely spoil the book.
My thoughts
I started off not enjoying this book as much as its predecessor and I found it tough going initially. I think that's because it's essentially the same book as the Phoenix Project but from a different perspective so it felt a bit predictable. However, once I got to the back third, I was enjoying it more and got through it a lot more quickly. I found myself nodding along to all the ideas in it.
Saying that, I didn't find the character of Maxine all that relatable. In my opinion, she could have just as easily been Maximilian because it felt like she was a man in a woman's skin. It's a bit of a shame because I was super excited about the fact that the main character is a woman - women still only make up about a quarter of the tech workforce so more representation is always wonderful.
The references to really ancient tech and all the geeky things pulled me out of the story a bit too. There are so many Star Wars, Star Trek, LOTR and Game of Thrones references it felt like the book was trying a touch too hard. Yes, okay, we're all nerds here, I get it! I don't really understand why the book refers to chat rooms, pagers and Tomcat (as a modern tech!) like it's 2002 - it was written in 2019 and I just found myself going "was anyone still using these back then?! because I sure wasn't".
Having gotten all my gripes out of my system, I have to say that this book does do a pretty good job of showing us what a healthy engineering culture should look like. I wholeheartedly agree with the five ideals - I know from experience that working somewhere where these five principles are actively upheld is wonderful and the difference is abundantly clear when they are not. I would highly recommend you check it out if you haven't already and if you haven't read the Phoenix Project yet, read that one too!
Overall, I give this book 6 stars out of 10. It wasn't as enjoyable as the Phoenix Project, but it still taught me some new things. In my opinion, everyone in an engineering leadership role should be given this and the Phoenix Project as required reading.
★★★★★★☆☆☆☆
Where to buy this book
You can buy The Unicorn Project from bookshop.org or your local bookseller. It is also available digitally on Kobo . I don’t use Amazon so will not post links to it here, though I’m sure they sell it too.
