What do you think?
Rate this book
The Unicorn Project
The Phoenix Project wowed over a half-million readers. Now comes the Wall Street Journal Bestselling The Unicorn Project ! “ The Unicorn Project is amazing, and I loved it 100 times more than The Phoenix Project …”— FERNANDO CORNAGO, Senior Director Platform Engineering, Adidas “Gene Kim does a masterful job of showing how … the efforts of many create lasting business advantages for all.”— DR. STEVEN SPEAR, author of The High-Velocity Edge, Sr. Lecturer at MIT, and principal of HVE LLC. “ The Unicorn Project is so clever, so good, so crazy enlightening!” ––CORNELIA DAVIS, Vice President Of Technology at Pivotal Software, Inc., Author of Cloud Native Patterns This highly anticipated follow-up to the bestselling title The Phoenix Project takes another look at Parts Unlimited, this time from the perspective of software development. In The Unicorn Project , we follow Maxine, a senior lead developer and architect, as she is exiled to the Phoenix Project, to the horror of her friends and colleagues, as punishment for contributing to a payroll outage. She tries to survive in what feels like a heartless and uncaring bureaucracy and to work within a system where no one can get anything done without endless committees, paperwork, and approvals. One day, she is approached by a ragtag bunch of misfits who say they want to overthrow the existing order, to liberate developers, to bring joy back to technology work, and to enable the business to win in a time of digital disruption. To her surprise, she finds herself drawn ever further into this movement, eventually becoming one of the leaders of the Rebellion, which puts her in the crosshairs of some familiar and very dangerous enemies. The Age of Software is here, and another mass extinction event looms—this is a story about rebel developers and business leaders working together, racing against time to innovate, survive, and thrive in a time of unprecedented uncertainty...and opportunity. “ The Unicorn Project provides insanely useful insights on how to improve your technology business.” —DOMINICA DEGRANDIS, author of Making Work Visible and Director of Digital Transformation at Tasktop ——— “My goal in writing The Unicorn Project was to explore and reveal the necessary but invisible structures required to make developers (and all engineers) productive, and reveal the devastating effects of technical debt and complexity. I hope this book can create common ground for technology and business leaders to leave the past behind, and co-create a better future together.”—Gene Kim, November 2019
352 pages, Hardcover
First published November 26, 2019
About the author
Gene Kim
24 books882 followersGene Kim is a multiple award-winning CTO, Tripwire founder, Visible Ops co-author, IT Ops/Security Researcher, Theory of Constraints Jonah, a certified IS auditor and a rabid UX fan.
He is passionate about IT operations, security and compliance, and how IT organizations successfully transform from "good to great."
He is passionate about IT operations, security and compliance, and how IT organizations successfully transform from "good to great."
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 627 reviews
February 13, 2020
Easily one of the worst books I've ever read. Or rather couldn't read: I gave up on page 199.
There might've been some good message in it, and it sounded like an interesting format, but unfortunately it reads like bad fan fiction.
There's the protagonist, a typical Mary Sue. No flaws, stellar career, awesome husband and kids, cute puppy, volunteering with refugees and a coding school, running a popular open-source project, able to deal with any technical or organizational challenge. The way you know she's good is because she literally says, in a dialogue, “I'm really, really good at this stuff” twice within the first 5 chapters. Additional clues are long paragraphs about her awesomeness which for a technical person don't make much sense.
For example, “She routinely lives in the world of NP-complete problems that are so difficult to solve they can take more than polynomial time to complete”. NP-complete problems are a thing, and yes, currently we don't know of polynomial algorithms to solve them; but routinely living in the world of NP-complete problems is something that people do in academia (or in the first year of a computer science program).
“She is still the only person who knows every keyboard shortcut from vi to the latest, greatest editors. But she is never ashamed to tell anyone that she still needs to look up nearly every command line option for Git—because Git can be scary and hard!” — again, vi is a thing, yes, but it mostly has commands, not shortcuts, and while it might be interesting and educational to explore and compare different text editors, I don't comprehend why would one memorize *every* shortcut in *all* the editors instead of, you know, choosing one and becoming really efficient with it. Also you must refresh your memory from time to time, so she uses tens of different editors?.. To remember all the shortcuts?.. Weird hobby. On the other hand, if you use git every day and still need to look up nearly everything, that's not git's fault at this point. Setting up some aliases would be a solution aimed at productivity here.
There are countless examples like this which mention all the right words, but just do not make sense. Docker containers were claimed to be immutable (images are; containers aren't). When presented with a new laptop, the protagonist is appalled that code editors, Docker, or OmniGraffle are not installed on it yet. On another occasion, she thinks about looping being “so very, very dangerous and difficult to get right”. In Python. In Python!
Speaking of Python, one accurate detail I remember because it stood out as a real one, was some schoolgirls struggling with indentation errors in their Python code. That happens all the time indeed.
Back to the protagonist: she's just as believable a person as she is a developer. Being a seasoned professional in her 40s, she (like everyone else in the book, by the way) can't hold her cool for a second. She laughs in the meetings uncontrollably, fills up with rage at the first sign of a mildly irritating obstacle, works while sick and on the weekends; her face turns red or she's “fuming”every few pages and someone chokes on their coffee every other few pages. If I weren't reminded from time to time of her age, I would've guessed early 20s, first job ever.
And speaking of other characters, they love talking in infodumps.
Then there's the editing:
“Killing time in the kitchen waiting for another pot of coffee to brew, her phone buzzes.”
“Her app let's her easily push work into [...]”
“But everyone was delighted and grateful when their changes made it in—but not as delighted as Maxine.”
p.79: “Cranky Dave is on a roll.”
p.80: “Kurt's on a roll.”
p.103: “"Holy cow," Maxine continues, on a roll”
“I believe my job my job is very simple: [...]”
“She knows exactly how it feel.”
“personally identifiably information (or PII)”
...and so on.
Turning around a huge team which has been working on a critical project for years is a fascinating challenge, and I'd love to read a book about it. But not this one. It lost my trust at NP-complete problems.
So, being on a roll as I choke on my coffee, I'd liek to finish this review which runs on Windows web by recommending this book to people who 1) know their tech enough to not be misguided by the pseudo-technical details, and 2) are patient enough to not be irritated by typos and clunky sentences.
There might've been some good message in it, and it sounded like an interesting format, but unfortunately it reads like bad fan fiction.
There's the protagonist, a typical Mary Sue. No flaws, stellar career, awesome husband and kids, cute puppy, volunteering with refugees and a coding school, running a popular open-source project, able to deal with any technical or organizational challenge. The way you know she's good is because she literally says, in a dialogue, “I'm really, really good at this stuff” twice within the first 5 chapters. Additional clues are long paragraphs about her awesomeness which for a technical person don't make much sense.
For example, “She routinely lives in the world of NP-complete problems that are so difficult to solve they can take more than polynomial time to complete”. NP-complete problems are a thing, and yes, currently we don't know of polynomial algorithms to solve them; but routinely living in the world of NP-complete problems is something that people do in academia (or in the first year of a computer science program).
“She is still the only person who knows every keyboard shortcut from vi to the latest, greatest editors. But she is never ashamed to tell anyone that she still needs to look up nearly every command line option for Git—because Git can be scary and hard!” — again, vi is a thing, yes, but it mostly has commands, not shortcuts, and while it might be interesting and educational to explore and compare different text editors, I don't comprehend why would one memorize *every* shortcut in *all* the editors instead of, you know, choosing one and becoming really efficient with it. Also you must refresh your memory from time to time, so she uses tens of different editors?.. To remember all the shortcuts?.. Weird hobby. On the other hand, if you use git every day and still need to look up nearly everything, that's not git's fault at this point. Setting up some aliases would be a solution aimed at productivity here.
There are countless examples like this which mention all the right words, but just do not make sense. Docker containers were claimed to be immutable (images are; containers aren't). When presented with a new laptop, the protagonist is appalled that code editors, Docker, or OmniGraffle are not installed on it yet. On another occasion, she thinks about looping being “so very, very dangerous and difficult to get right”. In Python. In Python!
Speaking of Python, one accurate detail I remember because it stood out as a real one, was some schoolgirls struggling with indentation errors in their Python code. That happens all the time indeed.
Back to the protagonist: she's just as believable a person as she is a developer. Being a seasoned professional in her 40s, she (like everyone else in the book, by the way) can't hold her cool for a second. She laughs in the meetings uncontrollably, fills up with rage at the first sign of a mildly irritating obstacle, works while sick and on the weekends; her face turns red or she's “fuming”every few pages and someone chokes on their coffee every other few pages. If I weren't reminded from time to time of her age, I would've guessed early 20s, first job ever.
And speaking of other characters, they love talking in infodumps.
Then there's the editing:
“Killing time in the kitchen waiting for another pot of coffee to brew, her phone buzzes.”
“Her app let's her easily push work into [...]”
“But everyone was delighted and grateful when their changes made it in—but not as delighted as Maxine.”
p.79: “Cranky Dave is on a roll.”
p.80: “Kurt's on a roll.”
p.103: “"Holy cow," Maxine continues, on a roll”
“I believe my job my job is very simple: [...]”
“She knows exactly how it feel.”
“personally identifiably information (or PII)”
...and so on.
Turning around a huge team which has been working on a critical project for years is a fascinating challenge, and I'd love to read a book about it. But not this one. It lost my trust at NP-complete problems.
So, being on a roll as I choke on my coffee, I'd liek to finish this review which runs on Windows web by recommending this book to people who 1) know their tech enough to not be misguided by the pseudo-technical details, and 2) are patient enough to not be irritated by typos and clunky sentences.
January 27, 2020
Wow, where do I start with this one? The Unicorn Project is a book that I immediately bought, once I heard of its existence. I loved The Phoenix Project, dug deeper by reading a lot of Goldratts books and subsequently also enjoyed The DevOps handbook and Accelerate. I expected to fall in love with this book, like I did with The Phoenix Project and The Goal.
Turns out I didn't, at least as a novel, even though the core messages of the book resonate with me.
What I didn't like specifically:
1. They massively changed the stylistic formula used in the previous books and at least for me it works against the book.
While previously we had protagonists, who where completely out of their league, the new protagonist Maxine is already an expert developer and in most cases pretty much knew how to do it better, citing principles, books etc. along the way. Also her sidekick Kurt pretty much knew what they wanted to achieve from the first pages in the book. The role of the external coach Eric (or his equivalent Jonah in The Goal) consequently has been reduced from an impulse giver to a better sidekick and gone are the big "aha" moments of the original books when their protagonists reason about hints and metaphors used by the external coach and slowly reach their own conclusions.
In contrast this book is largely about fighting company politics and the "aha" moments have been replaced with an - what feels to me like an - "In your face" approach, where Maxine constantly talks and thinks unlike any "real" human being, churning out opinionated tech wisdom and best practices like a machine gun on every opportunity. I've worked with plenty of great technical colleagues in my career, also hardcore, tech-savy introverts and I can guarantee you, no-one talked like this, ever.
Also why does Eric reference every external impulse giver as "Sensei", like "Sensei Hickey" or "Sensey Moore". He didn't do that in the The Phoenix Project and to me it just felt awkward and cringe-worthy.
Speaking about being opinionated, I like Functional Programming, I also like (at least conceptually) Clojure, but being constantly reminded that FP and Clojure are awesome started to feel at some point like fan service to these developer communities. Again too much "in your face" for me.
2. Compared to The Goal, the whole story feels surprisingly less human
During these frantic times of a business where so much is changing, everything is fluid and the stakes are high, the personal life of employees usually takes a toll, especially if they're the ones pushing for change. If you work constantly under stress and work long hours it will affect your life. Goldratts original novel emphasised this by also showing how that big turn-around affected Alex Rogo's relationship with his family. This aspect is completely absent from this book. Instead Maxine constantly meets with her gang in a bar. I think it's a pity, because real life at least to me feels not like this and had they taken a page out of Goldratts book, I would have sympathised more with this.
3. It feels already a bit dated
I don't know whether this is because of where I've worked for the majority of the last decade, but a lot of the depiction of IT in Parts Unlimited feels like its from 15 to 20 years ago to me. No deployable build, no CI, etc. That's probably intentional to make the point, but I've never seen something like this in my career (which started in 2004). Looking also at the DORA report (https://cloud.google.com/blog/product...) the industry as a whole is moving faster and faster. So while this kind of IT transformation might have been leading to a competitive edge in 2013 (when The Phoenix Project came out), I'm not so sure this is still the case in 2020 (at least judging by the DORA report). What was elite back then, is pretty much normal for a larger group of companies now and that group continues to grow.
4. Autonomy is great, but what about alignment?
Having seen problems with autonomous teams at scale, I would have loved to hear something about the next challenges that you'd naturally encounter when you structure your engineering efforts into autonomous teams. Maintaining flow and alignment is not an easy feat from my experience and I had hoped that they would also delve a bit into that (other than Maxines new job description at the end).
What I did like:
1. The 5 ideals make a lot of sense to me and join neatly with other ideas such as the 3 ways from The Phoenix Project or the 5 Focussing Steps from The Goal.
2. The idea of doing front-line training close to the customers is great
3. The general theme of the book that developers can be trusted and if met on eye level can be a source for tremendous innovation for the business
All-in-all 3 stars is probably a bit harsh, and 4 stars would be a better match (because of the content), but for me a lot of the stylistic choices took away a lot of what made The Phoenix Project and The Goal great.
Turns out I didn't, at least as a novel, even though the core messages of the book resonate with me.
What I didn't like specifically:
1. They massively changed the stylistic formula used in the previous books and at least for me it works against the book.
While previously we had protagonists, who where completely out of their league, the new protagonist Maxine is already an expert developer and in most cases pretty much knew how to do it better, citing principles, books etc. along the way. Also her sidekick Kurt pretty much knew what they wanted to achieve from the first pages in the book. The role of the external coach Eric (or his equivalent Jonah in The Goal) consequently has been reduced from an impulse giver to a better sidekick and gone are the big "aha" moments of the original books when their protagonists reason about hints and metaphors used by the external coach and slowly reach their own conclusions.
What comes to mind here is for example how in The Goal the protagonist Alex Rogo slowly discovers "Drum-Buffer-Rope" while experimenting with different ways to keep a group of boy scouts together on a hiking trip, especially when one of the kids can't keep up with the rest of the group.
In contrast this book is largely about fighting company politics and the "aha" moments have been replaced with an - what feels to me like an - "In your face" approach, where Maxine constantly talks and thinks unlike any "real" human being, churning out opinionated tech wisdom and best practices like a machine gun on every opportunity. I've worked with plenty of great technical colleagues in my career, also hardcore, tech-savy introverts and I can guarantee you, no-one talked like this, ever.
Also why does Eric reference every external impulse giver as "Sensei", like "Sensei Hickey" or "Sensey Moore". He didn't do that in the The Phoenix Project and to me it just felt awkward and cringe-worthy.
Speaking about being opinionated, I like Functional Programming, I also like (at least conceptually) Clojure, but being constantly reminded that FP and Clojure are awesome started to feel at some point like fan service to these developer communities. Again too much "in your face" for me.
2. Compared to The Goal, the whole story feels surprisingly less human
During these frantic times of a business where so much is changing, everything is fluid and the stakes are high, the personal life of employees usually takes a toll, especially if they're the ones pushing for change. If you work constantly under stress and work long hours it will affect your life. Goldratts original novel emphasised this by also showing how that big turn-around affected Alex Rogo's relationship with his family. This aspect is completely absent from this book. Instead Maxine constantly meets with her gang in a bar. I think it's a pity, because real life at least to me feels not like this and had they taken a page out of Goldratts book, I would have sympathised more with this.
3. It feels already a bit dated
I don't know whether this is because of where I've worked for the majority of the last decade, but a lot of the depiction of IT in Parts Unlimited feels like its from 15 to 20 years ago to me. No deployable build, no CI, etc. That's probably intentional to make the point, but I've never seen something like this in my career (which started in 2004). Looking also at the DORA report (https://cloud.google.com/blog/product...) the industry as a whole is moving faster and faster. So while this kind of IT transformation might have been leading to a competitive edge in 2013 (when The Phoenix Project came out), I'm not so sure this is still the case in 2020 (at least judging by the DORA report). What was elite back then, is pretty much normal for a larger group of companies now and that group continues to grow.
4. Autonomy is great, but what about alignment?
Having seen problems with autonomous teams at scale, I would have loved to hear something about the next challenges that you'd naturally encounter when you structure your engineering efforts into autonomous teams. Maintaining flow and alignment is not an easy feat from my experience and I had hoped that they would also delve a bit into that (other than Maxines new job description at the end).
What I did like:
1. The 5 ideals make a lot of sense to me and join neatly with other ideas such as the 3 ways from The Phoenix Project or the 5 Focussing Steps from The Goal.
2. The idea of doing front-line training close to the customers is great
3. The general theme of the book that developers can be trusted and if met on eye level can be a source for tremendous innovation for the business
All-in-all 3 stars is probably a bit harsh, and 4 stars would be a better match (because of the content), but for me a lot of the stylistic choices took away a lot of what made The Phoenix Project and The Goal great.
December 14, 2019
Great idea (re-utilized tbh), brilliant principles, but not a great book.
What did I like?
- the general "stage" was set quite well - easy to grasp & understand the problems, credible & "realistic"
- some of the comparisons (e.g. to "redshirts" were brilliant & hilarious :>)
- I likes "sensei" quotations - they may have felt a bit out of place, but they were very valuable in a context - my fav. one was about horizons
- I really believe this book can have its effect - I mean: be more thought-provoking for certain class of individuals than any other one
What didn't I like?
- oversimplifications - not in terms of WHAT to do (there's a good balance here), but in terms of how certain obstacles/impediments are hard to get through - the biggest challenges in the book (incl. re-writing the most messed parts of the software) were beaten in a week or so: reality is NOT like that. I'm not saying "rebellion" should not do what they did - I'm saying this book can build false expectations (e.g. in non-tech executives) that rhinos can be turned into unicorns within a month or so
- in terms of word-crafting it's just artisan work - it doesn't tire the reader down, but I wouldn't call it "fun to read"
- there were about 3 moments of max. naivety with "cargo cult-like" statements (about FP, "Panter", etc.) which appeared almost ... childish
Nevertheless - this IS an important book. Another piece in a wide education set for all the IT professionals around the word. It's not perfect, yet it's one of the best pieces of weaponry we have - and for that I'm thankful.
4.2-4.5 stars
What did I like?
- the general "stage" was set quite well - easy to grasp & understand the problems, credible & "realistic"
- some of the comparisons (e.g. to "redshirts" were brilliant & hilarious :>)
- I likes "sensei" quotations - they may have felt a bit out of place, but they were very valuable in a context - my fav. one was about horizons
- I really believe this book can have its effect - I mean: be more thought-provoking for certain class of individuals than any other one
What didn't I like?
- oversimplifications - not in terms of WHAT to do (there's a good balance here), but in terms of how certain obstacles/impediments are hard to get through - the biggest challenges in the book (incl. re-writing the most messed parts of the software) were beaten in a week or so: reality is NOT like that. I'm not saying "rebellion" should not do what they did - I'm saying this book can build false expectations (e.g. in non-tech executives) that rhinos can be turned into unicorns within a month or so
- in terms of word-crafting it's just artisan work - it doesn't tire the reader down, but I wouldn't call it "fun to read"
- there were about 3 moments of max. naivety with "cargo cult-like" statements (about FP, "Panter", etc.) which appeared almost ... childish
Nevertheless - this IS an important book. Another piece in a wide education set for all the IT professionals around the word. It's not perfect, yet it's one of the best pieces of weaponry we have - and for that I'm thankful.
4.2-4.5 stars
December 1, 2019
I wanted to like this story a lot more than I did... What resonated for me with The Phoenix Project, and later The Goal, seemed to be largely missing when I read The Unicorn Project. Some of it may have been due to already having been exposed to many of the concepts of the book, but the storyline and characters also seemed more forced than it could have been... The Phoenix Project was largely generic enough that I would readily feel comfortable recommending it to those not directly in the IT sector, I'm not sure I feel the same way with The Unicorn Project.
Lastly, I was disappointed with the quality of the both the Audible and Kindle version of the book. With the Kindle version, there were many typos (doubled words, wrong words, etc.) that were slightly distracting. Some additional editing would have been nice. With the audiobook, the narration audio was distractingly jarring... Maybe the initial recordings were done prior to extensive re-writes and lines had to be changed or added last-minute...? No clue what led to the poor final product, but it was annoying...
Lastly, I was disappointed with the quality of the both the Audible and Kindle version of the book. With the Kindle version, there were many typos (doubled words, wrong words, etc.) that were slightly distracting. Some additional editing would have been nice. With the audiobook, the narration audio was distractingly jarring... Maybe the initial recordings were done prior to extensive re-writes and lines had to be changed or added last-minute...? No clue what led to the poor final product, but it was annoying...
December 12, 2019
I did have quite high expectation's from this book. Looking at The Pheonix Project and DevOps Handbook I thought this will be HUGE. and it was, but disappointment.
Firstly, with PP I could identify myself with problem and solution. I was trying to find a solution to the problem that Bill was having. It was really engaging and educational.
Here it was hard to identify with anyone in the book. Rebellion to save a company, working against everyone. I wasn't and I'm still not sure what this book is about. Cheering devs? Having fun of writing code? Pushing to prod? Doing everything for the customer?
Of course, there is lots of truth in the book. however, we need to pick/find/extract the truth as readers, and it's not part of the story.
This book would be 5-star book if it would be thought through before writing IT and created like The Goal or The Pheonix Project.
Firstly, with PP I could identify myself with problem and solution. I was trying to find a solution to the problem that Bill was having. It was really engaging and educational.
Here it was hard to identify with anyone in the book. Rebellion to save a company, working against everyone. I wasn't and I'm still not sure what this book is about. Cheering devs? Having fun of writing code? Pushing to prod? Doing everything for the customer?
Of course, there is lots of truth in the book. however, we need to pick/find/extract the truth as readers, and it's not part of the story.
This book would be 5-star book if it would be thought through before writing IT and created like The Goal or The Pheonix Project.
January 9, 2020
Like its predecessor "The Phoenix Project", this book dwells on the transformation required for companies to achieve sustained velocity and quality relying on communication and data-driven decisions. Although the timeline is pretty much the same as "The Phoenix Project", this time, the perspective is of the development and business.
I can relate with several signals of broken organizations, like silos, over-complicated processes and blameful culture. As most of my career was spent on operations (although in the book the line between operations and IT is stretched way too thin), I also understand very well the impact of developers owning their software in production. Similarly, the systems engineering teams being able to understand applications and improving the tooling, providing their services as a platform for a self-service approach, are mandatory for bridging the gap between dev and ops. So, the story depicted is plausible and above all, entertaining.
I truly enjoyed the fact of some of my favourite books being mentioned, which I do recommend everyone to read:
* Team of Teams by General Stanley McChrystal
* Transforming NOKIA by Risto Siilasmaa
* Redshirts by John Scalzi
But there were things I did not appreciate and broke the flow of the book.
There's an unhealthy functional programming overload, depicting it as the holy grail of software engineering, as one knows, tools are just a part of a solution.
The character Maxine having god-like powers and moving from operations to software development, product and management effortlessly is also quite the stretch.
People without a background in this kind of scenarios will definitely enjoy this book much more than I did because of the issues mentioned above.
I can relate with several signals of broken organizations, like silos, over-complicated processes and blameful culture. As most of my career was spent on operations (although in the book the line between operations and IT is stretched way too thin), I also understand very well the impact of developers owning their software in production. Similarly, the systems engineering teams being able to understand applications and improving the tooling, providing their services as a platform for a self-service approach, are mandatory for bridging the gap between dev and ops. So, the story depicted is plausible and above all, entertaining.
I truly enjoyed the fact of some of my favourite books being mentioned, which I do recommend everyone to read:
* Team of Teams by General Stanley McChrystal
* Transforming NOKIA by Risto Siilasmaa
* Redshirts by John Scalzi
But there were things I did not appreciate and broke the flow of the book.
There's an unhealthy functional programming overload, depicting it as the holy grail of software engineering, as one knows, tools are just a part of a solution.
The character Maxine having god-like powers and moving from operations to software development, product and management effortlessly is also quite the stretch.
People without a background in this kind of scenarios will definitely enjoy this book much more than I did because of the issues mentioned above.
January 2, 2020
I read The Phoenix Project back in 2012 or so, near the beginning of the DevOps movement, and I couldn't put it down. As someone who had spent most of his career up to that point in mostly-horrible operations roles, many of the horror stories and high-pressure scenarios -- not to mention typical stifling enterprise bureaucracies -- resonated with me deeply. In the 7 years since I first read it, I've recommended the book to countless people, both technical and non-technical, as a way to understand and empathize with those poor souls stuck inside the dysfunction of traditional IT organizations.
The problem with a book so impactful is that any sequel is likely to disappoint. The Unicorn Project is a good -- but not great -- take on many of the same technical and business issues in The Phoenix Project, but from a different angle, that of software development. The main character, Maxine Chambers, is supposedly a one-woman superhero who can effortlessly go from rewriting ten developers' 15-year-old spaghetti code into 50 lines of Clojure in an afternoon, all the way to having business-level conversations about strategy (and layoffs) with the CEO. Not only does this seem implausible, but by necessity, the roles of many of the other characters are minimized. I couldn't remember who Kurt, Shannon, Wes, etc. were, much less what areas they were supposedly responsible for, because Maxine is made out to be the person behind them all.
Two of the factors that made The Phoenix Project so compelling and readable were a) the fact that it was based on an existing work, Eliyahu M. Goldratt's The Goal, and b) the dialogue was crisp, direct, and fast-paced. To the first element: While Kim has made a reasonable attempt to explain agile and Lean software development practices in this book, there is no one single source for this information, and his synthesis of a lot of different ideas sometimes ends up being muddled. The character of Erik doesn't get the same play as in The Phoenix Project, and I think the book suffers for that.
A bigger problem is that Kim lets his passion for technology get in the way of the narrative. There are way too many technical details that don't drive the plot forward, and Kim's personal advocacy of functional programming languages creeps into the story line without a particularly good reason. At best, it hampers the flow; at worst, it is unnecessary dogma that makes Clojure sound like a panacea for developer velocity acceleration. Which is exactly why so many regular (imperative or object-oriented developers) find functional developers so annoying: Clojure is like the CrossFit of programming. (The first rule of functional programming is to always be talking about functional programming.)
All of this makes me wonder whether this book could have been better had Kim co-authored it, like he did the first, with Kevin Behr and George Spafford (or others). Having collaborators -- or a good editor -- tends to help rein in an author's worst impulses.
Zooming out, there's nothing fundamentally wrong with the book. Kim describes how modern software product teams should operate, teaches the reader about the guiding principles behind practical agile (being agile rather than just "doing" agile), and throws in a bit of best practices on large-scale distributed systems design to boot. It's possible that my criticisms stem from the fact that I know this space very well, so my eye is drawn to detailed flaws. If you don't have expertise in these topics, the book is definitely worth a read. But if you've already been living and breathing this stuff, you can give it a pass.
The problem with a book so impactful is that any sequel is likely to disappoint. The Unicorn Project is a good -- but not great -- take on many of the same technical and business issues in The Phoenix Project, but from a different angle, that of software development. The main character, Maxine Chambers, is supposedly a one-woman superhero who can effortlessly go from rewriting ten developers' 15-year-old spaghetti code into 50 lines of Clojure in an afternoon, all the way to having business-level conversations about strategy (and layoffs) with the CEO. Not only does this seem implausible, but by necessity, the roles of many of the other characters are minimized. I couldn't remember who Kurt, Shannon, Wes, etc. were, much less what areas they were supposedly responsible for, because Maxine is made out to be the person behind them all.
Two of the factors that made The Phoenix Project so compelling and readable were a) the fact that it was based on an existing work, Eliyahu M. Goldratt's The Goal, and b) the dialogue was crisp, direct, and fast-paced. To the first element: While Kim has made a reasonable attempt to explain agile and Lean software development practices in this book, there is no one single source for this information, and his synthesis of a lot of different ideas sometimes ends up being muddled. The character of Erik doesn't get the same play as in The Phoenix Project, and I think the book suffers for that.
A bigger problem is that Kim lets his passion for technology get in the way of the narrative. There are way too many technical details that don't drive the plot forward, and Kim's personal advocacy of functional programming languages creeps into the story line without a particularly good reason. At best, it hampers the flow; at worst, it is unnecessary dogma that makes Clojure sound like a panacea for developer velocity acceleration. Which is exactly why so many regular (imperative or object-oriented developers) find functional developers so annoying: Clojure is like the CrossFit of programming. (The first rule of functional programming is to always be talking about functional programming.)
All of this makes me wonder whether this book could have been better had Kim co-authored it, like he did the first, with Kevin Behr and George Spafford (or others). Having collaborators -- or a good editor -- tends to help rein in an author's worst impulses.
Zooming out, there's nothing fundamentally wrong with the book. Kim describes how modern software product teams should operate, teaches the reader about the guiding principles behind practical agile (being agile rather than just "doing" agile), and throws in a bit of best practices on large-scale distributed systems design to boot. It's possible that my criticisms stem from the fact that I know this space very well, so my eye is drawn to detailed flaws. If you don't have expertise in these topics, the book is definitely worth a read. But if you've already been living and breathing this stuff, you can give it a pass.
February 6, 2021
Why I read it: I liked the author’s previous novel ‘Pheonix Project’ a lot.
What I liked about it:
It is nice to read a novel about daily life of software engineers. The scenes of people coming together to fire-fight issues or to change the engineering culture made me wish I had more of that at work.
The five ideals presented in the book promote healthy cultural values for engineering companies.
The book gave me a better understanding of some agile practices. For example I’ve never thought much about the idea behind ‘user stories’. It was just a name of a Jira functionality for me. But here there was a good description how they were supposed to make the engineering work more customer focused.
The book is based on a a lot of contemporary resources. Books, twitter posts, YouTube videos.
What I disliked:
The first third of the book seemed like a total misunderstanding for me. It seemed to have been focused on re-assuring the main character – a female developer – is really good at her job. For one thing, that felt kind of sexist. When the main character was a male developer (the Pheonix Project) book dived straight to the action. But with a female developer apparently you need 100 pages to describe how capable she is at her job. Furthermore that made the character development feel poor. From my experience with women in STEM fields, we do not go around constantly thinking ‘I am so amazing. If I can’t do this, no one can’.
The entire book and situations designed to drive the five ideals home made me think how people going on stage need really bright make up so their faces can look expressive from afar. They were oversimplified and exaggerated.
There were quite a few scenes of the main character working on weekends and while being sick. And the family was mentioned just in passing. That created an impression of someone being so immersed in their work that their family life suffers.
What I liked about it:
It is nice to read a novel about daily life of software engineers. The scenes of people coming together to fire-fight issues or to change the engineering culture made me wish I had more of that at work.
The five ideals presented in the book promote healthy cultural values for engineering companies.
The book gave me a better understanding of some agile practices. For example I’ve never thought much about the idea behind ‘user stories’. It was just a name of a Jira functionality for me. But here there was a good description how they were supposed to make the engineering work more customer focused.
The book is based on a a lot of contemporary resources. Books, twitter posts, YouTube videos.
What I disliked:
The first third of the book seemed like a total misunderstanding for me. It seemed to have been focused on re-assuring the main character – a female developer – is really good at her job. For one thing, that felt kind of sexist. When the main character was a male developer (the Pheonix Project) book dived straight to the action. But with a female developer apparently you need 100 pages to describe how capable she is at her job. Furthermore that made the character development feel poor. From my experience with women in STEM fields, we do not go around constantly thinking ‘I am so amazing. If I can’t do this, no one can’.
The entire book and situations designed to drive the five ideals home made me think how people going on stage need really bright make up so their faces can look expressive from afar. They were oversimplified and exaggerated.
There were quite a few scenes of the main character working on weekends and while being sick. And the family was mentioned just in passing. That created an impression of someone being so immersed in their work that their family life suffers.
December 13, 2020
'The Phoenix Project' was fantastic, and naturally it left me incredibly curious as to what Gene Kim would come up next with. This is a far cry from both the literary quality as well as the technical depth that made 'The Phoenix Project' so successful.
The prose is still told in a lighthearted, approachable way, but there were several elements that in my opinion don't make this a good book, or an educational one even.
The characters are not believable. Maxine is forever over-excited, child-like and idealistic, and talks about all of the good practices she has seen in the past in both Parts Unlimited and in other jobs she's had in her career. Who tells everyone they meet in the morning "It's Testing Day!" urging them to be bouncing around? I also thought her relationship with her work was quite problematic. The book attempts to occasionally shift into Maxine's life outside the office, and she is pictures taking notes, strategising, compulsively checking her phone. She is depicted as a hero, and work overtaking one's life to the point that they seem unable to connect with their family or engage in personal relationships is not something that I would seek for myself or recommend to others.
But my main problem with this book is in its technical aspects. It's written a good 10 years too late, if not more. There are 'epochs' in the evolution of software, and a good 2/3rds if not more are about:
- QA, Ops and Devs working together - still no mention of Engineering as a craft;
- Continuous Integration (CI), Continuous Delivery (CD);
- Dev, testing and production environments and their replicability and portability;
- Making room for tech debt in the every day.
The fact that Parts unlimited had absolutely nothing in terms of CI and CD, and that many characters had not even heard of these concepts makes me very dubious of the contemporaneity of a book published in 2o19. This is the age when we are discussion scale and data-oriented systems, not CI and CD or the fact that developers have no knowledge of what the test suites look like. It makes it dated and adds nothing to the literature available in tech.
And lastly, everything comes very easy to the characters. The book is anchored in the political work scene rather than the technical merits of the decision making process. It's over-simplified and fairy-tale like, rather than a realistic perspective of endless discussions and negotiations.
If you are new to tech or perhaps not familiar with operational practices or working at scale in terms of a large number of teams supporting a project, maybe. Can't say I will be the one recommending it, though.
The prose is still told in a lighthearted, approachable way, but there were several elements that in my opinion don't make this a good book, or an educational one even.
The characters are not believable. Maxine is forever over-excited, child-like and idealistic, and talks about all of the good practices she has seen in the past in both Parts Unlimited and in other jobs she's had in her career. Who tells everyone they meet in the morning "It's Testing Day!" urging them to be bouncing around? I also thought her relationship with her work was quite problematic. The book attempts to occasionally shift into Maxine's life outside the office, and she is pictures taking notes, strategising, compulsively checking her phone. She is depicted as a hero, and work overtaking one's life to the point that they seem unable to connect with their family or engage in personal relationships is not something that I would seek for myself or recommend to others.
But my main problem with this book is in its technical aspects. It's written a good 10 years too late, if not more. There are 'epochs' in the evolution of software, and a good 2/3rds if not more are about:
- QA, Ops and Devs working together - still no mention of Engineering as a craft;
- Continuous Integration (CI), Continuous Delivery (CD);
- Dev, testing and production environments and their replicability and portability;
- Making room for tech debt in the every day.
The fact that Parts unlimited had absolutely nothing in terms of CI and CD, and that many characters had not even heard of these concepts makes me very dubious of the contemporaneity of a book published in 2o19. This is the age when we are discussion scale and data-oriented systems, not CI and CD or the fact that developers have no knowledge of what the test suites look like. It makes it dated and adds nothing to the literature available in tech.
And lastly, everything comes very easy to the characters. The book is anchored in the political work scene rather than the technical merits of the decision making process. It's over-simplified and fairy-tale like, rather than a realistic perspective of endless discussions and negotiations.
If you are new to tech or perhaps not familiar with operational practices or working at scale in terms of a large number of teams supporting a project, maybe. Can't say I will be the one recommending it, though.
February 5, 2020
A pretty nice novel and a long awaited sequel. Good illustration of must-know-and-follow principles that became industry standards in the last decade.
Despite I thoroughly enjoyed the story flow, there are a couple of reasons why I would not recommend the book to a colleague. And would definitely not recommend to someone just starting his or her endeavour in IT.
The picture of the Parts Unlimited Inc is hardly realistic. I cannot beleive there could be real examples of such companies nowadays where even small software change take years to get delivered. Even less realistic would be a successful effort to make such company to an industry leader in a course of few months. I am not fan of dystopias, especially not, when the high-valued business- and IT-principles can be interpreted utopic in such context.
Another grain of salt is the impression one could get about a work/life balance in IT. It seems that working long hours till you get sick is a norm and if you are really going to make a difference, then from the sickbed you must reach for the laptop to bring your ideas forwards. It should not matter what weekday of daytime it is, your first prio is the business need and the family should be okay with the second position. Maybe there are some cultural differencies between US and EU companies, which I - as an European - do not understand. But there are also counter examples from Jason Fried, David Heinemeier Hansson demonstrating lack of correlation between business success and high level of stress. Aiming for a burnout should not be praise, even in a novel.
To wrap up - Gene Kim is a brillian entrepreneur and author. The DevOps Handbook is the best summary for the mentioned ideas. In this sense The Unicorn Project is an interesting book, but not the first choice. Maybe even not the second.
Despite I thoroughly enjoyed the story flow, there are a couple of reasons why I would not recommend the book to a colleague. And would definitely not recommend to someone just starting his or her endeavour in IT.
The picture of the Parts Unlimited Inc is hardly realistic. I cannot beleive there could be real examples of such companies nowadays where even small software change take years to get delivered. Even less realistic would be a successful effort to make such company to an industry leader in a course of few months. I am not fan of dystopias, especially not, when the high-valued business- and IT-principles can be interpreted utopic in such context.
Another grain of salt is the impression one could get about a work/life balance in IT. It seems that working long hours till you get sick is a norm and if you are really going to make a difference, then from the sickbed you must reach for the laptop to bring your ideas forwards. It should not matter what weekday of daytime it is, your first prio is the business need and the family should be okay with the second position. Maybe there are some cultural differencies between US and EU companies, which I - as an European - do not understand. But there are also counter examples from Jason Fried, David Heinemeier Hansson demonstrating lack of correlation between business success and high level of stress. Aiming for a burnout should not be praise, even in a novel.
To wrap up - Gene Kim is a brillian entrepreneur and author. The DevOps Handbook is the best summary for the mentioned ideas. In this sense The Unicorn Project is an interesting book, but not the first choice. Maybe even not the second.
This entire review has been hidden because of spoilers.
December 15, 2019
This book’s predecessor, The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win introduced me to DevOps in 2013, and while I was looking forward to learning new things about software development with this one, sadly, I can’t say that I did, but I still enjoyed it a lot. It was part horror story, part “I see this happen every day” and even part comedy, it made me roll my eyes (in a good way!) many times. It was very entertaining in a geeky kind of way.
I can certainly identify with the main character, Maxine, although I’m not sure if that’s a good thing :)
I hope there is a third book, focused on data and AI or something along those lines.
The narrator was very good, but some parts appeared to be re-recorded and those came out sounding kind of weird and inconsistent with the rest of the audio, making it very distracting. The audiobook could have been better produced.
I can certainly identify with the main character, Maxine, although I’m not sure if that’s a good thing :)
I hope there is a third book, focused on data and AI or something along those lines.
The narrator was very good, but some parts appeared to be re-recorded and those came out sounding kind of weird and inconsistent with the rest of the audio, making it very distracting. The audiobook could have been better produced.
August 21, 2022
I've read the Phoenix Project and this "highly" anticipated sequel doesn't disappoint either. With how pretentious, preachy and shallow this new book is, it somehow manages to surpass even its predecessor in being absolutely terrible (which is no small feat).
Summary: a bunch of overworked nerds in IT with unhealthy obsession for work set on a quest to save their dying crusty ol' corporation. They succeed in doing so, despite being deterred by their incompetent C-level leadership, mountains of technical debt, and having to work overtime literally all the time. Their reward for that is a smoother working process, making the company (but not themselves) a shit ton of money, and the keys to the city. At the end, everybody's patting each other on their backs for a job well done and gazing boldly into the bright bright future.
The characters are paper thin, the tech "revelations" are nothing new if you've worked in tech, the writing is plain bad. Glorifying working overtime and in secrecy to disrupt your OWN company...go see a therapist instead.
I got the cringe ON.EVERY.SINGLE.SENTENCE, and I feel a genuine like to every kindred spirit who gave this "book" a 1-star review. Way to go, you challenger you!
Summary: a bunch of overworked nerds in IT with unhealthy obsession for work set on a quest to save their dying crusty ol' corporation. They succeed in doing so, despite being deterred by their incompetent C-level leadership, mountains of technical debt, and having to work overtime literally all the time. Their reward for that is a smoother working process, making the company (but not themselves) a shit ton of money, and the keys to the city. At the end, everybody's patting each other on their backs for a job well done and gazing boldly into the bright bright future.
The characters are paper thin, the tech "revelations" are nothing new if you've worked in tech, the writing is plain bad. Glorifying working overtime and in secrecy to disrupt your OWN company...go see a therapist instead.
I got the cringe ON.EVERY.SINGLE.SENTENCE, and I feel a genuine like to every kindred spirit who gave this "book" a 1-star review. Way to go, you challenger you!
February 1, 2020
3.5-3.75 stars
This book a manages to be a novel/story AND an excellent “best practices” business book while also showing some key issues and problems with large corporations.
If you like business books and novels, you’d like this. This author also references / pulls plot from Red Shirts by Jonathon Scalzi at least four times, so if you liked that book... (I think general scalzi fans would like this as well, even though it’s not science fiction).
The one gripe I have is the main character reads like an early 30s professional (the narrators voice is probably 33) but randomly there would be a reference to her husband and kids, which stops the record — huh? Where have they been this whole time? And then you think, “so they never see her because she works 24/7, and then you wonder what you missed—is she a lot older or did she have babies in grad school? (Because she doesn’t come across as 30s/40s to begin with and in the tech world/millennials aren’t having their first kid until their 30s) but then you forget they exist (because they never appear) only for another random reference. I think, perhaps, this is the case of a male author not being able to write women accurately
This book a manages to be a novel/story AND an excellent “best practices” business book while also showing some key issues and problems with large corporations.
If you like business books and novels, you’d like this. This author also references / pulls plot from Red Shirts by Jonathon Scalzi at least four times, so if you liked that book... (I think general scalzi fans would like this as well, even though it’s not science fiction).
The one gripe I have is the main character reads like an early 30s professional (the narrators voice is probably 33) but randomly there would be a reference to her husband and kids, which stops the record — huh? Where have they been this whole time? And then you think, “so they never see her because she works 24/7, and then you wonder what you missed—is she a lot older or did she have babies in grad school? (Because she doesn’t come across as 30s/40s to begin with and in the tech world/millennials aren’t having their first kid until their 30s) but then you forget they exist (because they never appear) only for another random reference. I think, perhaps, this is the case of a male author not being able to write women accurately
May 24, 2020
Great concept, poor execution.
The book describes tech operations and inefficiencies within a company while covering various insightful concepts. However, it's clear the author comes from a strong tech background and isn't much of a writer. The book was poorly structured and had typos throughout and at times tried to explain concepts through chunks of text (spanning more than one page) spoken by one character without pause, which became really boring and difficult to follow. To make the storyline more entertaining, the author also included narratives that were mostly corny.
While the focus of the book is not writing style or articulation, they would have certainly made the concepts easier to digest. The ideas behind the book were great, but as a novel, I was unfortunately very disappointed.
The book describes tech operations and inefficiencies within a company while covering various insightful concepts. However, it's clear the author comes from a strong tech background and isn't much of a writer. The book was poorly structured and had typos throughout and at times tried to explain concepts through chunks of text (spanning more than one page) spoken by one character without pause, which became really boring and difficult to follow. To make the storyline more entertaining, the author also included narratives that were mostly corny.
While the focus of the book is not writing style or articulation, they would have certainly made the concepts easier to digest. The ideas behind the book were great, but as a novel, I was unfortunately very disappointed.
June 28, 2020
It is a really great book, however not so exciting as Phoenix Project. I would recommend to read both. Probably better to start with Phoenix Project since it is referenced few times in Unicorn Project. Although these are two different problems and could be read in any order.
The book tells a story of developer/architect having difficulties to do her job in huge enterprise with a lot of bureaucracy and issues. She solves them one by one and company becomes the leader in innovation in its niche.
What I didn’t particularly like was that some solutions were not described, but said that implemented and worked well on the other side some where described completely, so I see a misalignment here.
Recommended!
The book tells a story of developer/architect having difficulties to do her job in huge enterprise with a lot of bureaucracy and issues. She solves them one by one and company becomes the leader in innovation in its niche.
What I didn’t particularly like was that some solutions were not described, but said that implemented and worked well on the other side some where described completely, so I see a misalignment here.
Recommended!
March 22, 2021
The first half of this book should come with a PTSD trigger warning for anyone that has worked in corporate dev environments 😂
Seriously though, this isn't a bad book, particularly if you feel like things are going wrong at work. It gives you some ideas for what might be frustrating you. What is pretty "unrealistic" is the approach to resolving them. The second half of the story really dragged on and I struggled to finish it off.
There is an interesting idea of "The 5 ideals" but after finishing this book I can't remember them at all. They're mentioned and then referenced sparsely. I'll need to go look them up again.
Seriously though, this isn't a bad book, particularly if you feel like things are going wrong at work. It gives you some ideas for what might be frustrating you. What is pretty "unrealistic" is the approach to resolving them. The second half of the story really dragged on and I struggled to finish it off.
There is an interesting idea of "The 5 ideals" but after finishing this book I can't remember them at all. They're mentioned and then referenced sparsely. I'll need to go look them up again.
January 21, 2023
Like its predecessor, The Phoenix Project, this book is essentially Gene Kim's thoughts on how refactoring an organization -- focusing mainly on its IT functions -- can unlock and create value for its customers as well as its shareholders, lightly fictionalized.
The thing is, the book makes a compelling argument, and one I find myself mostly agreeing with. Not only that, it references a lot of (what I consider to be) solid real-life management and business books, as well as other things like YouTube videos and Twitter threads on the topics discussed.
The book is easy to read and hard to put down. At one point I was struck by the book's depiction of a corporate bureaucracy -- it's not evil and doesn't have it in for you personally, but it will most definitely ruin your day. Later in the book we're also treated to some realistic corporate politics.
The thing is, the book makes a compelling argument, and one I find myself mostly agreeing with. Not only that, it references a lot of (what I consider to be) solid real-life management and business books, as well as other things like YouTube videos and Twitter threads on the topics discussed.
The book is easy to read and hard to put down. At one point I was struck by the book's depiction of a corporate bureaucracy -- it's not evil and doesn't have it in for you personally, but it will most definitely ruin your day. Later in the book we're also treated to some realistic corporate politics.
April 26, 2020
A few years ago, when I started to interact with more and more IT people in my work I took an effort to understand their work and become a better collaborator for them. The first step was Edward's Yourdon "The Death March". IT is the nervous system of any organization and business people who can't interact with it really can be like a disease attacking it. I'm trying not to be that.
I think it would be great if developers and managers on the IT side would understand the business much more. Since they probably think that I should understand IT better I'm trying to make an effort to do just that.
This book is not as good as "The Phoenix Project", however, it still adds to the understanding of IT by business people.
I think it would be great if developers and managers on the IT side would understand the business much more. Since they probably think that I should understand IT better I'm trying to make an effort to do just that.
This book is not as good as "The Phoenix Project", however, it still adds to the understanding of IT by business people.
April 6, 2021
If you work in IT a lot of this probably sounds familiar; unfortunately!
I love the writing style and overall approach to this novel: Maxime is easy to relate to and Eric always is around at the right moment for some good hints. There is definitely a lot to take away from this in regards to agile, flow, technical and organizational debt and employee motivation!
I love the writing style and overall approach to this novel: Maxime is easy to relate to and Eric always is around at the right moment for some good hints. There is definitely a lot to take away from this in regards to agile, flow, technical and organizational debt and employee motivation!
March 3, 2020
Another must read book by Gene Kim. The only thing I have to point out is that if you read "The Phoenix Project", you already know how the story ends, because this story happens in the same timeline, which kind of takes away some elements of surprise and makes it less exciting to read when compared with its predecessor story.
August 20, 2022
Definitively a good read. I love these story style books that bring a good learning through the live eyes of a person and experience.
Also, if you are in tech, you should read this!
Also, if you are in tech, you should read this!
December 20, 2019
I liked the story a lot as well as the level of details on many topics. This is the great book for organisation who are at the start of their (devops transformation) journey. There are obviously few things that work differently in the real life, for instance, it is just a great co-incidence that Parts Unlimited had MRP division that was already advanced in the way they did things. Usually that is not the case. It is also unusual to have people with the competence and the experience in modern and agile software engineering practices, that are still around in the company that is fundamentally dysfunctional :) The would probably leave way before rebellion would have been established.
December 26, 2019
A good follow-up to The Phoenix Project that takes place at the same time but it's now focused on the development team as opposed to the operations/IT team. What I really enjoy in these books and that that they focus on mindset, organization, and practices, instead of technology which in my experience is the hardest and most impactful change in any organization.
The timeframe of the changes and their impact doesn't always seem reasonable but I don't think that diminishes the value of the insights, you just needs to manage the expectations while implementing this transformation in your organization ;)
The timeframe of the changes and their impact doesn't always seem reasonable but I don't think that diminishes the value of the insights, you just needs to manage the expectations while implementing this transformation in your organization ;)
June 4, 2021
It's a very nice book(novel would be better to say) around devops (what exactly it means and its philosophy). The overall story about the engineers taking initiatives and why change is way forward been illustrated very beautiful in it. There are some caveats which I feel are like since it's more of a novel, it's very predictable and can go into cliche field easily but I like the overall storytelling as well as some climatic situations presented in the book.
I might given it 5 stars if they've presented some failures too (not just success stories).
I might given it 5 stars if they've presented some failures too (not just success stories).
July 10, 2022
This was really bad. Gene Kim is a master of jargon. Not the interesting-but-requires-background-knowledge kind of jargon, but the stomach-churning I-want-to-throw-up-when-I-hear-this-bullshit type of jargon. It's regurgitated executive speak: "this will better help us bring more value to our internal customers" and "our business is one that depends on operational excellence" (:vomits uncontrollably:). Kim writes like a low-budget business consultant, sprinkling oversimplified business fads as though he's swallowed the same idiot pill that top execs take when they think that all they need to do to increase "shareholder value" (aka end-of-year executive bonus) is to force rote regurgitation of company "values" and mission statements and push out some new initiative. There's no real human connection here.
For all the reasons why I couldn't get through more than a quarter of the "DevOps Handbook," I really really struggled to finish this.
On top of the vomit-inducing dialogues, the protagonist herself was so unlikeable that I wanted to drive into her with a steam roller. Kim clearly misunderstands the basis of these stories, which should be grounded on Campbell's monomyth. Principally, it should be a story based on the relatable transformation of the protagonist through challenge, by releasing the previous self. In other words, it should be a process of destruction and regrowth. The Phoenix Project does that perfectly, while The Unicorn Project falls flat.
Here, Maxine is already perfect in every way: she's just a master of everything she does, and she's emotionally overwhelmed by anything that doesn't deliver value to customers (:vomit:). She just loves to help customers and employees, but the evil executives are scapegoating her for their own failings and preventing her from reaching her own perfection; yet, even though they've outcast her, she applies her perfect perfection in the perfect way with the other perfect people to do perfect things, bringing value to customers all along the value chain! (:cough vomit cough:)
As well as the lack of transformation in the story, with a character that's about as relatable and enjoyable as a brick sandwich, it's tough to find generalisable knowledge embedded in what should be a narrative-based textbook. The main moral of the story appears to be that over-departmentalisation and hierarchical bureaucracies reduce coordination efficiency and limit cooperation. A lesson that's been known since shortly after the days Max Weber suggested the coordination and control economies of bureaucratic governance and corporations adopted it en masse.
The actual Unicorn Project seems to be a recommendation system, yet it spends half the book talking about the decoupling of Data Hub from the Phoenix project. Because...umm...it would be better? Because coupling creates dependencies and that's bad! I honestly don't remember why. What was Data Hub used for again? An inventory management system? It then sprinkles in regurgitated Goldratt, but without the exploration: the constraint is Data Hub (why was it the constraint again? Constraint in what chain?). And, in the true fashion of poorly understood Goldratt tropes, there's a sprinkling of supernatural assistance from megaGod Eric, who's now a bartender, because that makes sense! But of course, superwoman Maxine doesn't need any supernatural help - just the merest mention of the "the ideals" and she gets it immediately and transforms all the processes to become a reflection of her megaperfect innate powers of perfection to foster innovative efforts that support customer-value competencies while setting the industry direction, allowing Parts Unlimited to leave their competitors in the dust!
(:heave:)
The only saving grace to this book was the "war room" launch chapter. Although short and they found and resolved the problems far too quickly, it was actually somewhat, slightly, almost emotionally and mentally stimulating.
If you've read The Phoenix Project and are craving more... don't waste your time on this!
For all the reasons why I couldn't get through more than a quarter of the "DevOps Handbook," I really really struggled to finish this.
On top of the vomit-inducing dialogues, the protagonist herself was so unlikeable that I wanted to drive into her with a steam roller. Kim clearly misunderstands the basis of these stories, which should be grounded on Campbell's monomyth. Principally, it should be a story based on the relatable transformation of the protagonist through challenge, by releasing the previous self. In other words, it should be a process of destruction and regrowth. The Phoenix Project does that perfectly, while The Unicorn Project falls flat.
Here, Maxine is already perfect in every way: she's just a master of everything she does, and she's emotionally overwhelmed by anything that doesn't deliver value to customers (:vomit:). She just loves to help customers and employees, but the evil executives are scapegoating her for their own failings and preventing her from reaching her own perfection; yet, even though they've outcast her, she applies her perfect perfection in the perfect way with the other perfect people to do perfect things, bringing value to customers all along the value chain! (:cough vomit cough:)
As well as the lack of transformation in the story, with a character that's about as relatable and enjoyable as a brick sandwich, it's tough to find generalisable knowledge embedded in what should be a narrative-based textbook. The main moral of the story appears to be that over-departmentalisation and hierarchical bureaucracies reduce coordination efficiency and limit cooperation. A lesson that's been known since shortly after the days Max Weber suggested the coordination and control economies of bureaucratic governance and corporations adopted it en masse.
The actual Unicorn Project seems to be a recommendation system, yet it spends half the book talking about the decoupling of Data Hub from the Phoenix project. Because...umm...it would be better? Because coupling creates dependencies and that's bad! I honestly don't remember why. What was Data Hub used for again? An inventory management system? It then sprinkles in regurgitated Goldratt, but without the exploration: the constraint is Data Hub (why was it the constraint again? Constraint in what chain?). And, in the true fashion of poorly understood Goldratt tropes, there's a sprinkling of supernatural assistance from megaGod Eric, who's now a bartender, because that makes sense! But of course, superwoman Maxine doesn't need any supernatural help - just the merest mention of the "the ideals" and she gets it immediately and transforms all the processes to become a reflection of her megaperfect innate powers of perfection to foster innovative efforts that support customer-value competencies while setting the industry direction, allowing Parts Unlimited to leave their competitors in the dust!
(:heave:)
The only saving grace to this book was the "war room" launch chapter. Although short and they found and resolved the problems far too quickly, it was actually somewhat, slightly, almost emotionally and mentally stimulating.
If you've read The Phoenix Project and are craving more... don't waste your time on this!
March 12, 2020
It's nearly scary how close descriptions in the book are to the situations I find at my clients. On the other hand, this is great because The Unicorn Project book is all the more relevant for them. For many, even the earlier Phoenix Project might create some "aha moments". The beauty is that you can enjoy reading also The Project Unicorn alone, without reading the Phoenix project first.
October 8, 2019
Note: I received an advance review copy. The book is slated to come out in November 2019.
This is a business novel, continuing the story that started in the Phoenix Project about a dusty old auto parts company that is struggling with all sorts of sclerotic systems and business processes. And it is about how they take some basic principles born of TOC, Lean, Agile, DevOps, and more and do something fabulous.
The story had me hooked pretty early, even having me concerned for the main character - when she felt sick at the actions of others, I felt sick. It’s a good read - a story that shows what can happen if you have just enough courage to do the next right thing.
More detail on my blog: https://www.jackvinson.com/blog/2019/...
This is a business novel, continuing the story that started in the Phoenix Project about a dusty old auto parts company that is struggling with all sorts of sclerotic systems and business processes. And it is about how they take some basic principles born of TOC, Lean, Agile, DevOps, and more and do something fabulous.
The story had me hooked pretty early, even having me concerned for the main character - when she felt sick at the actions of others, I felt sick. It’s a good read - a story that shows what can happen if you have just enough courage to do the next right thing.
More detail on my blog: https://www.jackvinson.com/blog/2019/...
October 14, 2020
I was shocked by my disappointment with this book. I really enjoyed the prior installment, The Phoenix Project, but felt that the story and the message of this book was not as powerful this time around. The lessons were more provocative and mysteriously drew you in with the former book, but this one laid the lessons out early on and made the rest of the book feel like filler. I came here to learn valuable lessons, not just to read a novel about what it's like to work in IT, so the story alone didn't draw me in. I completed the book (and am glad I did, because I enjoyed the end of Chapter 17 which was near the end of the book), but felt that it could have been MUCH shorter (a short story, perhaps?) and still have achieved what it was going for.
January 15, 2023
Easily one of the worst books I've ever read. The only good thing about this book is the knowledge the author undoubtly possesses about big corporate tech firms. For the love god, show, don't tell. There's pages and pages of a single character trying to explain entire systems in a monologue. If you want your readers to understand better ways of performing devOps, do it through non-fiction, because this sucks.
Also, the book contains many repetitions, literally the same sentence twice after another. Lots of spelling and grammar mistakes too.
Also, the book contains many repetitions, literally the same sentence twice after another. Lots of spelling and grammar mistakes too.
August 31, 2022
Had to put this book down. Probably the worst writing I've read in years, and the book was just not getting anywhere after 3 excruciating chapters. Kim violates the basic rule of show don't tell on every other page and thinly veils his opinions (e.g. functional programming is awesome!), giving them to his main character. A bummer since I liked the concept and wanted to like the book
Displaying 1 - 30 of 627 reviews