The Unicorn Project: A Novel About Developers, Digital Disruption, and Thriving in the Age of Data

Imagine you get blamed by management, you personally, for some systemic issue that caused widespread disruption. They're looking for a scapegoat - someone to fire so the negative focus gets sucked out in the wake of that person's departure - but in this case you were lucky enough to have a friend in high places. So you get reassigned, sent to a cumbersome impossible trailing-edge project where no one will notice you. Maybe your growing anger and resentment will finally make it possible for you to seek revenge, to pay them back? Maybe you can teach them all a lesson? But there's something about you that just can't go there - you don't create problems, you solve them! And despite your worst intentions, you find yourself getting curious about this back-water project - why is it so broken? Where do I get started, figuring it all out? Who can help and how did it get this way? What value could customers get if we could just find a way to deliver results? This is the opening setup for Maxine Chambers, development leader and software architect at Parts Unlimited, Inc., in The Unicorn Project, Gene Kim's follow-up to The Phoenix Project. As stated in its subtitle, The Unicorn Project is "a novel about developers, digital disruption, and thriving in the age of data." Kim brings together key concepts from Geoffrey Moore, Jez Humble, Donald Reinertsen, Mik Kersten, Mark Schwartz, Peter Senge, and stories from the trenches of transformation from the DevOps Enterprise Summit conference series to capture a blueprint for transformational success that's based on the perspectives and efforts of software engineers. Not many novels bring to life the daily struggles of software engineers, so this comparatively rare mirror placed in front of us offers a welcome chance to reflect on a large set of key questions, such as: • How close are we to the results of our efforts? Do we get to see our customers' delight? • Can we execute quick experiments, get rapid feedback, and iterate? • Are we fans of pragmatic programming, functional programming? • How often are we bitten by mutability in our code? • Are we satisfied in our work? If not, what might be some systemic causes of our dissatisfaction? • Do our systems enable us to focus or are we continually context-shifting? • Are we able to collaborate easily across functions and teams? • Even better, have we reduced interdependencies to the absolute minimum? • When things go wrong, does the organization focus on blame or on systemic corrections? • Are we generating technical debt faster than we're paying it down? • How much toil do we face every day? Unplanned work? Internal work? • How do we carve out time for improvement, or even time just to think? • What's the relationship between engineering and "the business" really like, here? But despite all the instructional value in this book, it's very easy to get caught up in the drama of the story. Parts Unlimited is a very large, traditional enterprise that must transform to survive. The legacy of complex and entangled architectures, out-of-date processes, methods, and tools have generated a context in which innovation dies long before it can complete its journey to customers. A brave group of engineers form a "rebellion" to confront this legacy and create a lasting business transformation, both technological and cultural. To organize the dramatic principles at work in the story, Gene Kim came up with The Five Ideals of DevOps: 1. Locality and Simplicity (reduce interdependency, own your code in production, microservices architecture) 2. Focus, Flow, and Joy (limit work in progress, make work visible, see the value of your contributions) 3. Improvement of Daily Work (pay down technical debt, streamline the architecture) 4. Psychological Safety (blameless culture, systems thinking, shared context) 5. Customer Focus (core vs. context, feedback) Elements of the storyline are adeptly woven through these five ideals, clarifying each one and giving them practical weight. Plot twists, setbacks, sudden breakthroughs, a major RIF, taking a sledgehammer to old server equipment, and C-level treachery make this a very compelling read. One of my favorite parts involves a QA joke Bill Sempf shared on Twitter: "QA engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a sfdeljknesv." Although the speed at which certain miraculous improvements happen defies belief at times, the novel is full of inspiring tales of software engineers getting excited about better methods, shaking off the shackles of the status quo, and getting it done right.

I really enjoyed reading the story of the Unicorn project. It was a well written and enjoyable novel. Unfortunately, I also think it was a missed opportunity in both better expressing some concepts covered in the book and completely missed a set of related concepts that might have made the book better. That said, especially for people who enjoy software development related novels, the Unicorn Project is recommended. Because this is a novel, the rest of the review is likely to contain spoilers. The book consists of three parts. These parts are only labeled with dates, but they are roughly (1) the miserable current reality, (2) the rebellion, and (3) the unicorn project. The first part, slightly larger than 100 pages, is a description of the current situation in Parts Unlimited. The main character, Maxine, is published for an IT failure and gets expelled to The Phoenix Project. This is a deadmarch IT project which is the absolute worst and unfortunately quite familiar for some of us that have been working in large organizations. This part describes in-depth how bad things are, perhaps even a bit exaggerated at times. The second part starts when one of the people who do want to improve things (Kurt) becomes a development manager and is given the opportunity to do things differently. The other people who join him call themselves the rebellion and they adopt modern development (DevOps) practices to improve the development work. They convince Maggie from marketing that they can build and deliver a really important feature that might save the company. The third part, the rebellion expands and needs a new name and becomes the Unicorn Project. They adopt modern development practices and some modern technology and with that dramatically improve the product. This leads to significantly increased revenue and they save the company. Next the company changes their focus to include more innovation so that it will be less likely that it will be disrupted by a competitor. As said, the biggest plus for this book was that was easy and enjoyable to read. The lessons it tried to convey were mostly good, such as focus on developer efficiency, automated builds, test, and deployment, and modern technologies and architectures. It introduce "the five ideals" which seem useful principles for improving product development. I was disappointed that some of the above mentioned concepts were not explained in-depth. But my biggest disappointed was that it seemed to miss some ideas completely and didn't seem to offer a long-term way forward for a product development organisation. Let me clarify a bit. The first part was a perfect description of what happens in development when you create narrow-focused functional and component teams who do not collaborate (or just collaborate through tools). Then the second part starts breaking some of these silos and moves to a more cross-functional approach, yet they still *seem* keep team-code ownership rather than moving through cross-team code ownership. It wasn't completely clear as the teams were still structured around the architectural components, yet the author referred at least a couple of times to them as feature teams. Closely related, the book showed well how you can get things done cross-teams when you have a clear #1 priority (expedited development), but it didn't cover how an effective development organization would be structured so that all the teams can work effectively, not just the ones that work on the expedited features. In conclusion, I would give the book 3 stars for content and 4 stars for writing and story. As it is a novel and I did enjoy it, I'll round it up... 4 stars.

Having read "The Unicorn Project," I found it to be a solid resource in the realm of technology and business. Gene Kim, the author, weaves an informative narrative around Maxine, a protagonist navigating through a stifling corporate landscape. The journey she undertakes represents a familiar struggle for many in a similar position. The book's main principles are embodied in the Five Ideals: Locality and Simplicity, Focus, Flow and Joy, Improvement of Daily Work, Psychological Safety, and Customer Focus. Through these, I got a comprehensive understanding of what it takes to implement change in a rigid system. Maxine's journey in redefining the errors of 'The Phoenix Project' showcases the interconnectedness of business and technology. It underlined the significance of balance and harmony within an organization's different functions. "The Unicorn Project" extensively covers DevOps, presenting it not just as a toolset or process, but as a culture and philosophy that promotes constant learning, collaboration, and innovation. However, the frequency of technical jargon used may make it challenging for those not deeply entrenched in the tech field. Despite being heavily rooted in technology and software development, the book carries a broader appeal due to its engaging narrative style. Even though the extensive use of technical terminology might pose a slight barrier, it's still a worthwhile read for anyone interested in understanding the digital landscape of modern businesses.

I've always said that there is no customer problem so bad that I couldn't come in and make it worse. The Unicorn Project, while an entertaining business novel, is chalk full of coding and other technical references that go right over my head. That being said, I still heartily enjoyed the book and learned a tremendous amount from reading it. In The Unicorn Project, Gene Kim retells The Phoenix Project story of IT and corresponding business transformation at the struggling auto-parts store giant, Parts Unlimited, but from the completely different perspective of Maxine Chambers and the IT staff. An hoc team, The Rebellion, fights back against the bureaucracy, waste and, most importantly, technical debt inherent in the 100-year old company. The mysterious Yoda-like tech guru, Erik (also featured in The Phoenix Project) explains, “There are many definitions, but my favorite is how it was originally defined by Ward Cunningham in 2003. He said, ‘technical debt is what you feel the next time you want to make a change.’” Given the recent release of the final Star Wars saga, The Unicorn Project’s rebellion is particularly timely. And Gene includes plenty of fun Star Wars trivia subtly embedded throughout the book. Business philosophy worthy of a Naval Ravikant is scattered throughout The Unicorn Project such as this gem, "Every tech giant has nearly been killed by technical debt. You name it: Facebook, Amazon, Netflix, Google, Microsoft, eBay, LinkedIn, Twitter, and so many more." IT guru, Erik, chimes in with observations like, "Interestingly, Satya Nadella, CEO of Microsoft, still has a culture that if a developer ever has a choice between working on a feature or developer productivity, they should always choose developer productivity." The Unicorn Project also includes practical snippets for non-IT workers such as when an executive reminds employees at a celebratory meeting, "Uh, just a reminder, this is insider information. If you use this information to trade Parts Unlimited stock, you can go to prison. Dick Landry, our CFO, told me to tell you that he will assist in your prosecution as per your employment contract." The book even highlights a very relevant word for IT, "Complect." Erik explains, "It's an archaic word, resurrected by Sensei Rich Hickey. 'Complect' means to turn something simple into something complex." He makes sure to call out One of the passages resonated personally: “Maxine thinks with a grin, “We’re racking up a heck of a bill with the cloud computing providers, but absolutely no one in Marketing is complaining because the business benefits are so spectacular.” I spend a good deal of my time explaining how cloud is an operating model, not a destination, and that an enterprise cloud model can bring enable the business benefits of public cloud combined with the much lower cost and greater control of on-prem. In fact, Gene even includes a reference to the Nutanix Workshops website. Heroin Maxine says near the end of the book, "Technology needs to be embedded in the business, not external to it or merely aligned with it.” The wonder of The Unicorn Project is that by the end of the book, Gene has not only convinced his readers about the truth of this declaration, but he’s helped them experience second-hand why it’s so.

I have been a Developer, Engineer and Project Manager in IT for the last 20 odd years. I have been fortunate enough to have worked with and for several Tech Giants. The names and places change; but, the story remains the same. Why is it that most everyone can relate to "Dilbert?" Alas, I rest my case. The Unicorn Project, is stellar on a variety of fronts; unlike the "Phoenix Projects" it covers the whole gamut of a Corporation struggling for a foot hold in an ever decreasing market. The author did an amazing job of capturing the different "political" motives, even to the level of the Board and really demonstrated how little input CEO's have when Board Members go rouge. The book is not an easy read and I would say that it was almost frantic; yet it had to be. I could relate personally with most of the cast (Dev, Eng, PM) and the solutions were more than Ideals or Steps. We've all seen these things and been told they hold the key to success. (If only the whole organization would follow) As stated, this is an amazing book and both the "Phoenix Project" and the "Unicorn Project" should be mandatory reading for everyone within an organization, regardless the size. From Peons, to Managers, to CEOs, CFO's, COO's to Board Members. Dilbert will live forever if the lessons in this book are not learned and learned well.

I liked this significantly less than the 5*, highly, highly recommended Phoenix Project. I do not work in IT, but I am from the continuous improvement / Lean world in the office, and I'm always looking for other perspectives. Pros: - Good story. I did find Maxine's story engaging and relatable. We've all been in a bureaucratic nightmare, and it's almost always of our own creation. - The 5 points / maxims are great discussion points with organizations. I don't see them as limited to only developers; anyone who works in an office environment can read and get those, and we all feel the pain when we don't flow. Cons: - The biggest miss was burying the content too deeply in the story. The 5 points / maxims were referred to quite a few times, but not in a complete and structured way. I would have loved to see something at the end of chapters to call them out and reinforce where they were used in that chapter. Further - there were a couple other interesting topics buried in the book - Horizon 1, 2, and 3 - that were discussed but never fully explained other than a description. I was very interested in this and definitely wanted to know more. - At times it was very deep in the weeds about specific technical issues. For the narrative, it worked, but it seemed to hide the overall concept. - Erik referring to everyone as Sensei XXX was annoying to me. Minor thing but ugh.

Following the tradition of The Goal several decades ago, business books that show attempt to show rather than tell by means of a fictional stories, this quasi-sequel to The Phoenix Project exemplifies how software development should work in the Cloud era, what business problems it solves, and what success looks like for the business that the technology supports. I think the general idea for the book was quite good, the problem statement felt very real, but by the middle of the book it got lost in the weeds, too much extraneous detail about various crises that were hard to follow without adding much to the story. I think those parts could have been compressed a bit to make room for further elaboration on the transformation initiatives, the actual success stories and “happy ending” which were described in a very rushed way in the last two chapters. Then there’s corporate cartoon villain Sarah, which is too much to believe, and a passing mention of functional programming as a kind of silver bullet without really describing what it is and how it helps. Overall I would give this book 5 stars for vision and 3 for execution, there’s hope that a better edited second edition will be great.

The power of story in teaching technical concepts is highly underutilized. Gene Kim & friends achieved a great feat in introducing new people to DevOps in The Phoenix Project, which is a great book about business struggles in digital transformation (from the business' perspective). They achieved even more in The Unicorn Project when they flip the story on its head and tell it from IT's viewpoint. The characters are infinitely relatable and compelling and probably most importantly, tied to real world events/IT stories so that they are grounded in reality. This is a super fast read in part because it is a fictional story. But don't let that fool you. The book is worth reading again to digest some of the great wisdom imparted at key moments. The book is so instructive that I plan on including it in the curriculum for the software architecture course that I teach at a local university. Well done, Gene!