What do you think?
Rate this book
The Phoenix Project #2
獨角獸專案 - 看 IT 部門如何引領百年企業振衰起敝，重返榮耀
內容簡介
暢銷小說《鳳凰專案》姊妹作，主角梅克辛致力建立一個充滿活力的學習型組織，重新點燃人們心中的創新之火，同時和根深蒂固的階級制度抗爭，挑戰對風險避之唯恐不及的傳統秩序，因為她知道，在這個充滿不確定性的時代中，唯有適者才能生存，方能把握前所未有的機遇。
《獨角獸專案》邀請讀者重返無極限零件公司的殘酷世界。無極限零件公司正處於失敗邊緣，極有可能是零售末日的下一個受害者。所有人生存的一線希望都寄託於「鳳凰專案」，但這項專案似乎也災難重重，前途未卜。
身為全公司數一數二傑出的工程師，梅克辛不明不白地成為薪酬核算系統故障的替罪羔羊，被流放到多災多難的鳳凰專案。到了那裡，她發現開發團隊面臨龐大的交付壓力，被恐懼和怪罪的組織文化深深籠罩，遭受將近十年的冷落忽視，背負沈重的技術債。梅克辛努力創造技術卓越，對抗迷霧重重的官僚主義和軟體架構，在這種令人困惑的架構中，即便想做出最微小的改動也困難重重，甚至會導致災難性後果和互相指責。
鳳凰專案未能兌現其目標之際，在神秘反抗軍的幫助下，梅克辛開始採取行動拯救公司。她必須找出推翻現有秩序的方法，幫助開發人員高效工作，為技術組織找回快樂，好讓無極限零件公司能在破壞式創新的數位時代中佔有一席之地，在市場中贏得勝利。
梅克辛以「五大理念」為核心精神，致力打造獨角獸專案，改善公司業務和技術開發的合作方式。反抗軍號召整個組織運用大數據，全力執行他們的巧妙計畫，但他們的東奔西走究竟能否拯救梅克辛和無極限零件公司？
專家推薦
「書中主角所經歷的組織轉型困境，根本就是我們在企業中進行顧問服務與推動敏捷和導入DevOps時，所面對到的真實問題的翻版。舉凡陳舊資訊系統所發生的難題、組織官僚體系的僵化、企業內政治問題的牽絆、乃至於改善時所採用的方法與工具，在在都讓人心有戚戚焉。」 -- 董大偉，微軟技術社群區域總監（Microsoft RD+MVP）／光岩資訊資深技術顧問
「我鼓勵讀者們，第一遍看熱鬧，第二遍看門道。第一遍速讀，先享受高潮起伏的劇情，並熟悉人物與關係。第二遍重讀時，請以「核心業務與脈絡業務」及「系統與組織的五大理念」兩種觀點細讀，從頭分析故事的人事時地物及因果關係。如此下來，比起許多愛談高大上理念的敏捷、DevOps、數位轉型書籍，你會有更深刻具體的領悟。橫看成嶺側成峰，願你能從中獲益。」 -- 敏捷魔藥師 葉秉哲（William Yeh）
「每一家正在經歷數位化轉型的公司都需要將此書列為所有主管的必讀之作。他們不僅會認識到並感同身受瑪克辛和團隊的掙扎，還能從「五大理念」中找到成功的啟示。」-- Courtney Kissler, NIKE全球技術副總裁。
「《獨角獸專案》太棒了！我喜這本書甚過《鳳凰專案》100倍....，它讓我記住了過去4年我們在愛迪達經歷的每一步。」-- Fernando Cornago, adidas平台工程資深總監
「就像《鳳凰專案》之於管理組織變革的重要性，《獨角獸專案》對於絕大多數在第一線現場實際解決問題的人來說，也是如此。這本書為未來幾代軟體工程師描繪了一個願景。」-- Tom Longstaff博士，卡內基美隆大學軟體工程研究所首席技術官
「一個真正的數位化轉型，一個在客戶滿意度、員工參與度和現金流方面有價值的轉型，是一場艱苦卓絕的勝利，要經過一場場痛苦的戰鬥。勝利、失敗和意外是不可避免的，需要仰賴勇氣和毅力才能克服。《獨角獸專案》是每個技術和商業開拓者必閱的組織內戰小說。」-- Christopher O'Malley, Compuware總裁兼執行長。
「《鳳凰專案》釐清了DevOps的內容和原因。Gene Kim的最新著作《獨角獸專案》闡明了數位化轉型的內容和原因。」-- Jeffrey Snover，微軟技術研究員
「《獨角獸專案》是《鳳凰專案》的續作，從技術貢獻者的角度講述了同樣的事件，並更深入地挖掘了團隊動態、領導力、自動化和誤導治理等關鍵問題。在現實世界的IT或數位組織中工作的讀者會再次發現自己還有很長的路要走；幸運的是，Gene正在繼續照亮道路。」-- Charles Betz, Forrester Research首席分析師和全球DevOps負責人。
「如果你讀了《鳳凰專案》，懷疑作者就是在描寫你的工作情況，那麼，《獨角獸專案》會讓你有一種似曾相識的感覺。」-- Erica Morrison, CSG軟體工程執行總監
「我喜歡《鳳凰專案》的原因是，它讓我覺得自己並不孤單。看了這本書，我非常認同書中主角在軟體開發過程中的經歷。在《獨角獸專案》中，他又為被遺棄的技術宅提供一劑良方。而這一次，他又延伸到了技術世界中的另一整個族群-- 那些與數據、分析、報告和預測模型打交道的人。任何從事軟體或資料分析工作的人都會對《獨角獸專案》中的人物和團隊遇到的問題產生親切感，並會在他們應用Dev和DataOps最佳實踐獲得成功時為他們加油。很可怕的是，這些角色、對話和情境與我們日常經歷的事情如此接近。我懷疑Gene聽過我們下班後浸泡在啤酒中的牢騷......」-- Christopher Bergh, DataKitchen執行長
作者簡介
Gene Kim
Gene Kim是一位屢獲殊榮的CTO、研究員和作家。Tripwire的創始人，並擔任了13年的CTO。著作包括暢銷書《鳳凰專案》和《DevOps Handbook中文版｜打造世界級技術組織的實踐指南》，以及《Beyond The Phoenix Project》、《Accelerate》等等。他因在業界的出色成就被普渡大學推舉為傑出校友。
Gene的推特：@RealGeneKim
暢銷小說《鳳凰專案》姊妹作，主角梅克辛致力建立一個充滿活力的學習型組織，重新點燃人們心中的創新之火，同時和根深蒂固的階級制度抗爭，挑戰對風險避之唯恐不及的傳統秩序，因為她知道，在這個充滿不確定性的時代中，唯有適者才能生存，方能把握前所未有的機遇。
《獨角獸專案》邀請讀者重返無極限零件公司的殘酷世界。無極限零件公司正處於失敗邊緣，極有可能是零售末日的下一個受害者。所有人生存的一線希望都寄託於「鳳凰專案」，但這項專案似乎也災難重重，前途未卜。
身為全公司數一數二傑出的工程師，梅克辛不明不白地成為薪酬核算系統故障的替罪羔羊，被流放到多災多難的鳳凰專案。到了那裡，她發現開發團隊面臨龐大的交付壓力，被恐懼和怪罪的組織文化深深籠罩，遭受將近十年的冷落忽視，背負沈重的技術債。梅克辛努力創造技術卓越，對抗迷霧重重的官僚主義和軟體架構，在這種令人困惑的架構中，即便想做出最微小的改動也困難重重，甚至會導致災難性後果和互相指責。
鳳凰專案未能兌現其目標之際，在神秘反抗軍的幫助下，梅克辛開始採取行動拯救公司。她必須找出推翻現有秩序的方法，幫助開發人員高效工作，為技術組織找回快樂，好讓無極限零件公司能在破壞式創新的數位時代中佔有一席之地，在市場中贏得勝利。
梅克辛以「五大理念」為核心精神，致力打造獨角獸專案，改善公司業務和技術開發的合作方式。反抗軍號召整個組織運用大數據，全力執行他們的巧妙計畫，但他們的東奔西走究竟能否拯救梅克辛和無極限零件公司？
專家推薦
「書中主角所經歷的組織轉型困境，根本就是我們在企業中進行顧問服務與推動敏捷和導入DevOps時，所面對到的真實問題的翻版。舉凡陳舊資訊系統所發生的難題、組織官僚體系的僵化、企業內政治問題的牽絆、乃至於改善時所採用的方法與工具，在在都讓人心有戚戚焉。」 -- 董大偉，微軟技術社群區域總監（Microsoft RD+MVP）／光岩資訊資深技術顧問
「我鼓勵讀者們，第一遍看熱鬧，第二遍看門道。第一遍速讀，先享受高潮起伏的劇情，並熟悉人物與關係。第二遍重讀時，請以「核心業務與脈絡業務」及「系統與組織的五大理念」兩種觀點細讀，從頭分析故事的人事時地物及因果關係。如此下來，比起許多愛談高大上理念的敏捷、DevOps、數位轉型書籍，你會有更深刻具體的領悟。橫看成嶺側成峰，願你能從中獲益。」 -- 敏捷魔藥師 葉秉哲（William Yeh）
「每一家正在經歷數位化轉型的公司都需要將此書列為所有主管的必讀之作。他們不僅會認識到並感同身受瑪克辛和團隊的掙扎，還能從「五大理念」中找到成功的啟示。」-- Courtney Kissler, NIKE全球技術副總裁。
「《獨角獸專案》太棒了！我喜這本書甚過《鳳凰專案》100倍....，它讓我記住了過去4年我們在愛迪達經歷的每一步。」-- Fernando Cornago, adidas平台工程資深總監
「就像《鳳凰專案》之於管理組織變革的重要性，《獨角獸專案》對於絕大多數在第一線現場實際解決問題的人來說，也是如此。這本書為未來幾代軟體工程師描繪了一個願景。」-- Tom Longstaff博士，卡內基美隆大學軟體工程研究所首席技術官
「一個真正的數位化轉型，一個在客戶滿意度、員工參與度和現金流方面有價值的轉型，是一場艱苦卓絕的勝利，要經過一場場痛苦的戰鬥。勝利、失敗和意外是不可避免的，需要仰賴勇氣和毅力才能克服。《獨角獸專案》是每個技術和商業開拓者必閱的組織內戰小說。」-- Christopher O'Malley, Compuware總裁兼執行長。
「《鳳凰專案》釐清了DevOps的內容和原因。Gene Kim的最新著作《獨角獸專案》闡明了數位化轉型的內容和原因。」-- Jeffrey Snover，微軟技術研究員
「《獨角獸專案》是《鳳凰專案》的續作，從技術貢獻者的角度講述了同樣的事件，並更深入地挖掘了團隊動態、領導力、自動化和誤導治理等關鍵問題。在現實世界的IT或數位組織中工作的讀者會再次發現自己還有很長的路要走；幸運的是，Gene正在繼續照亮道路。」-- Charles Betz, Forrester Research首席分析師和全球DevOps負責人。
「如果你讀了《鳳凰專案》，懷疑作者就是在描寫你的工作情況，那麼，《獨角獸專案》會讓你有一種似曾相識的感覺。」-- Erica Morrison, CSG軟體工程執行總監
「我喜歡《鳳凰專案》的原因是，它讓我覺得自己並不孤單。看了這本書，我非常認同書中主角在軟體開發過程中的經歷。在《獨角獸專案》中，他又為被遺棄的技術宅提供一劑良方。而這一次，他又延伸到了技術世界中的另一整個族群-- 那些與數據、分析、報告和預測模型打交道的人。任何從事軟體或資料分析工作的人都會對《獨角獸專案》中的人物和團隊遇到的問題產生親切感，並會在他們應用Dev和DataOps最佳實踐獲得成功時為他們加油。很可怕的是，這些角色、對話和情境與我們日常經歷的事情如此接近。我懷疑Gene聽過我們下班後浸泡在啤酒中的牢騷......」-- Christopher Bergh, DataKitchen執行長
作者簡介
Gene Kim
Gene Kim是一位屢獲殊榮的CTO、研究員和作家。Tripwire的創始人，並擔任了13年的CTO。著作包括暢銷書《鳳凰專案》和《DevOps Handbook中文版｜打造世界級技術組織的實踐指南》，以及《Beyond The Phoenix Project》、《Accelerate》等等。他因在業界的出色成就被普渡大學推舉為傑出校友。
Gene的推特：@RealGeneKim
356 pages, Paperback
First published November 26, 2019
2781 people are currently reading
21166 people want to read
About the author
Gene Kim
23 books1,009 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 760 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.
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.
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.
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.
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 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 23, 2019
Super kurinukas. Man kaip visą gyvenimą esančiam arti programuotojų, bet pačiam dirbant daugiausia su infrastruktūra, šis kūrinys labai artimas. Aišku jei pats nesi iš IT srities, jis greičiausiai pasirodys nuobodus arba ne visai suprantamas.
Phoenix Project buvo geras, bet šis tikrai nenusileidžia savo pirmtakui. Šiuos kūrinius galima skaityti nepriklausomai, nes kas juos sieja tai IT sritis ir projekto pavadinimas, viska kita yra atskiros istorijos.
Phoenix Project buvo geras, bet šis tikrai nenusileidžia savo pirmtakui. Šiuos kūrinius galima skaityti nepriklausomai, nes kas juos sieja tai IT sritis ir projekto pavadinimas, viska kita yra atskiros istorijos.
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!
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.
May 9, 2025
The Unicorn Project offers a powerful look at how even a century-old manufacturing company must evolve through technology to remain competitive. I appreciated the realistic portrayal of internal politics, technical debt, and how outdated processes can burden employees and threaten a company's future. It also highlights the risks and trade-offs of outsourcing tech departments—showing that losing internal knowledge can have lasting consequences. A compelling reminder that simplicity, autonomy, and collaboration are critical for long-term success.
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!
September 27, 2025
I have read the Phoenix project several years ago and i had liked it considering it was one really nice story focusing on common business problems and solutions for agility and constraints management.
On this one, even though there is an attempt to do the same, it feels a bit "weird" to me that the story had to be based on the same story of Parts Unlimited etc on the same period. It felt familiar and sort of boring to be reading again about the same characters, same company, same problems, same behaviors. The five ideals that is the key takeaway of the book i would perceive them as good reminder when building teams, but somehow too obvious as a concept.
On this one, even though there is an attempt to do the same, it feels a bit "weird" to me that the story had to be based on the same story of Parts Unlimited etc on the same period. It felt familiar and sort of boring to be reading again about the same characters, same company, same problems, same behaviors. The five ideals that is the key takeaway of the book i would perceive them as good reminder when building teams, but somehow too obvious as a concept.
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!
January 22, 2025
3 stars because you do learn a lot along the way but what a slog
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).
Displaying 1 - 30 of 760 reviews