What do you think?
Rate this book
The Phoenix Project #1
The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
Bill is an IT manager at Parts Unlimited. It's Tuesday morning and on his drive into the office, Bill gets a call from the CEO.
The company's new IT initiative, code named Phoenix Project, is critical to the future of Parts Unlimited, but the project is massively over budget and very late. The CEO wants Bill to report directly to him and fix the mess in ninety days or else Bill's entire department will be outsourced.
With the help of a prospective board member and his mysterious philosophy of The Three Ways, Bill starts to see that IT work has more in common with manufacturing plant work than he ever imagined. With the clock ticking, Bill must organize work flow streamline interdepartmental communications, and effectively serve the other business functions at Parts Unlimited.
In a fast-paced and entertaining style, three luminaries of the DevOps movement deliver a story that anyone who works in IT will recognize. Readers will not only learn how to improve their own IT organizations, they'll never view IT the same way again.
The company's new IT initiative, code named Phoenix Project, is critical to the future of Parts Unlimited, but the project is massively over budget and very late. The CEO wants Bill to report directly to him and fix the mess in ninety days or else Bill's entire department will be outsourced.
With the help of a prospective board member and his mysterious philosophy of The Three Ways, Bill starts to see that IT work has more in common with manufacturing plant work than he ever imagined. With the clock ticking, Bill must organize work flow streamline interdepartmental communications, and effectively serve the other business functions at Parts Unlimited.
In a fast-paced and entertaining style, three luminaries of the DevOps movement deliver a story that anyone who works in IT will recognize. Readers will not only learn how to improve their own IT organizations, they'll never view IT the same way again.
537 pages, Kindle Edition
First published January 10, 2013
About the author
Gene Kim
20 books943 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 3,827 reviews
September 23, 2022
Bill Palmer gets thrust into the CIO position at Parts Unlimited and has 90 days to make chicken salad out of chicken shit or the entire IT department gets outsourced. Does Bill have what it takes?
Confession Time: I've worked in IT for the past fifteen years. When the CTO of the company I work for strongly recommended all IT personnel read this, I bit the bullet.
Remember those after school specials that were some kind of lesson with a flimsy story wrapped around it? That's pretty much what this was. Only instead of featuring cool things like sex and drugs, this one was about the pitfalls of being an IT manager. It read like the book equivalent of the awful training video I had to watch when I worked loss prevention at K-mart about a thousand years ago.
Bill's a server guy who suddenly becomes CIO and is forced to turn the Phoenix Project around. Yeah, it's just as riveting as it sounds. All the kiss asses at work rave about the book but it's barely a novel. It's a management manual disguised as a novel. Not only that, Bill is kind of a dick and a Mary Sue. A Dick Sue, if you will.
Even before investigating the author, I could tell he was an operations guy rather than a developer. It was pretty easy to tell by the way he laid the heaviest of the blame on everyone except the server guys. It's like a garbage man writing a book where the garbage man is the only one who can save the day.
The book reads like someone recounting meetings he's been in, which is pretty much what it is. That and some corporate propaganda praising the use of Agile IT management and The Cloud. Actually, now that I think about it, it kind of reminds me of The Pillars of the Earth, where the plot is a loop of problems, solutions, and unexpected complications, only instead of a church, they're building an application. The rape levels aren't the same, either.
The book gets a little improbable by the end. After some pep talks and embracing the Agile philosophy, somehow a team that couldn't find its asses with both hands and a map can suddenly turn things around enough to master cloud computing in half a page.
Despite all the above-mentioned dislikes, and the fact that the characters are as thin as toilet paper from the Dollar Tree, this book wasn't a total piece of shit. Despite going in determined not to learn anything, I did manage to pick up some tips and saw a lot of similarities with my everyday life.
Two out of five stars. It's not much of a novel but someone who is already pondering embracing the techniques this book beats you over the head with will probably rate it a lot higher.
Five years later: I had to add a postscript to this since it's one of my most liked reviews. Our company has attempted to go full agile at least twice since I read this. Our team is one of the few that managed to make it work despite all the bumps in the road. One thing the book doesn't touch upon is that when everyone is supposed to be able to do every job, you lose track of who is doing what and sometimes things fall through the cracks. It also doesn't touch upon what to do if one team member is an utter sack of shit but I'll save that for another time.
Confession Time: I've worked in IT for the past fifteen years. When the CTO of the company I work for strongly recommended all IT personnel read this, I bit the bullet.
Remember those after school specials that were some kind of lesson with a flimsy story wrapped around it? That's pretty much what this was. Only instead of featuring cool things like sex and drugs, this one was about the pitfalls of being an IT manager. It read like the book equivalent of the awful training video I had to watch when I worked loss prevention at K-mart about a thousand years ago.
Bill's a server guy who suddenly becomes CIO and is forced to turn the Phoenix Project around. Yeah, it's just as riveting as it sounds. All the kiss asses at work rave about the book but it's barely a novel. It's a management manual disguised as a novel. Not only that, Bill is kind of a dick and a Mary Sue. A Dick Sue, if you will.
Even before investigating the author, I could tell he was an operations guy rather than a developer. It was pretty easy to tell by the way he laid the heaviest of the blame on everyone except the server guys. It's like a garbage man writing a book where the garbage man is the only one who can save the day.
The book reads like someone recounting meetings he's been in, which is pretty much what it is. That and some corporate propaganda praising the use of Agile IT management and The Cloud. Actually, now that I think about it, it kind of reminds me of The Pillars of the Earth, where the plot is a loop of problems, solutions, and unexpected complications, only instead of a church, they're building an application. The rape levels aren't the same, either.
The book gets a little improbable by the end. After some pep talks and embracing the Agile philosophy, somehow a team that couldn't find its asses with both hands and a map can suddenly turn things around enough to master cloud computing in half a page.
Despite all the above-mentioned dislikes, and the fact that the characters are as thin as toilet paper from the Dollar Tree, this book wasn't a total piece of shit. Despite going in determined not to learn anything, I did manage to pick up some tips and saw a lot of similarities with my everyday life.
Two out of five stars. It's not much of a novel but someone who is already pondering embracing the techniques this book beats you over the head with will probably rate it a lot higher.
Five years later: I had to add a postscript to this since it's one of my most liked reviews. Our company has attempted to go full agile at least twice since I read this. Our team is one of the few that managed to make it work despite all the bumps in the road. One thing the book doesn't touch upon is that when everyone is supposed to be able to do every job, you lose track of who is doing what and sometimes things fall through the cracks. It also doesn't touch upon what to do if one team member is an utter sack of shit but I'll save that for another time.
February 24, 2013
See more of my reviews at Bettering Me Up.
I know what you're thinking.
Wow. A fictionalized account of ITIL and Agile methodologies. That sounds so...exciting.
But it is!
Imagine my surprise when I was completely sucked into Bill's world.
IT Operations isn't always a fun place to work: servers crash; applications freeze; vulnerabilities are everywhere; and customers--both internal and external--scream for support.
So how to you manage all of the Work in Progress (WIP), emergencies, and planned work? It's enough to give any professional geek a panic attack.
Enter our heroes: ITIL and Kanban.
These Best Practice methodologies will help Bill and his team revolutionize how IT functions and contributes to the business at large.
The Phoenix Project takes a dry subject and turns it into an understandable narrative. Certain concepts that I didn't quite grasp when I studied for my ITIL certification became crystal clear during the course of this book.
I'm really looking forward to implementing a Kanban board with my team at work.
I know what you're thinking.
Wow. A fictionalized account of ITIL and Agile methodologies. That sounds so...exciting.
But it is!
Imagine my surprise when I was completely sucked into Bill's world.
IT Operations isn't always a fun place to work: servers crash; applications freeze; vulnerabilities are everywhere; and customers--both internal and external--scream for support.
So how to you manage all of the Work in Progress (WIP), emergencies, and planned work? It's enough to give any professional geek a panic attack.
Enter our heroes: ITIL and Kanban.
These Best Practice methodologies will help Bill and his team revolutionize how IT functions and contributes to the business at large.
The Phoenix Project takes a dry subject and turns it into an understandable narrative. Certain concepts that I didn't quite grasp when I studied for my ITIL certification became crystal clear during the course of this book.
I'm really looking forward to implementing a Kanban board with my team at work.
February 1, 2013
to be honest, I'm a bit embarrassed how much i enjoyed this book! It's basically a business/IT management book thinly disguised as a novel, but i must say it's very well done. It's such niche subject matter that i'm not sure anyone outside of an IT Ops role would appreciate it, but i genuinely learned a lot about how IT needs to integrate within business goals to actually achieve anything, that it doesn't exist in a vacuum, and if it does, then something is seriously out of wack. It preaches good principles, basically the silver bullet of Continuous Deployment and what value that brings to the dev cycle. I believe from what I've read that it's basically a rewrite of 'The Goal' - https://en.wikipedia.org/wiki/The_Goa... - which is "widely used in leading colleges of management to teach students about the importance of strategic capacity planning and constraint management." but with a DevOps spin on it.
Its definitely a tech book but eschews any one technology, to focus on the underlying principles.
I'm curious to see what others make of it.
Its definitely a tech book but eschews any one technology, to focus on the underlying principles.
I'm curious to see what others make of it.
January 31, 2018
This is the most cliché book I have ever read. The Phoenix Project uses a contrived narrative to deliver IT best practices like a mother would use applesauce to hide peas while spoon-feeding a toddler. The state of technology/management books might have been different five years ago, but I found the over-the-top nature insulting to the intelligence of the intended demographic. Yes, storylines help reinforce points, but the best books I encounter nowadays contain real examples sans the dramatics and three hundred pages of fluff.
All of the characters are one-dimensional and predictable. Constants. Like the NPC characters you encounter in old RPG games, you know how the dialogue will go every single time. Eventually you’re able to memorize a combination of down-arrows and X-buttons and you can skip the dialogue. You have Brent, the 10X programmer. There’s John, the manic firewall expert who basically drinks himself to death and is reincarnated as a superhero. Sarah is ambitious and it’s never clear what she does aside from ask the IT team to do work for her. You have Nancy, the main character’s wife, who understands but reminds him that his job sucks should he ever forget. And then there’s Erik.
Erik is the mysterious sensei type who guides Bill, the main character, to greener pastures and happy endings. There are a lot of riddles and descriptions of his clothing involved. By the end of the book, it turns out that Erik and Bill have a lot in common. Earlier, there is some type of seance where a few of the main characters dim the lights, sit around a table, and each reveal their “story.” Bill reveals that his father was a bad father--implying abandonment (yes, the book goes there). As I thought about it more while reflecting on why I didn’t enjoy this read, it seemed totally plausible that one of the authors, in an early draft of this book, planned to reveal Erik as Bill’s father. I'm not sure this would have taken the title for the most cringeworthy revelation.
The plot goes from bad to worse to bad. Part one lures you in, while part two is a droning mundanity. In part 3, the authors use chapter 30 to remind you that they’re well-read, and later take two pages to explain how the IT Team made a miracle happen and subsequently saved the company.
If you’re an engineer, don’t read this. If you’re on the non-technical manager spectrum, there’s something for you here. You have to parse through a lot of garbage--and I think you’re better off just digging in to more technically-oriented books--but there’s something for you here. You know how every manager has his the book? Please don’t make this your the book. You’re just a hypothetical to me right now and I’m confident that, regardless of your background, your precious time will be better spent reading something else. Truly, The Phoenix Project the book fails as embarrassingly as its namesake at Parts Unlimited.
All of the characters are one-dimensional and predictable. Constants. Like the NPC characters you encounter in old RPG games, you know how the dialogue will go every single time. Eventually you’re able to memorize a combination of down-arrows and X-buttons and you can skip the dialogue. You have Brent, the 10X programmer. There’s John, the manic firewall expert who basically drinks himself to death and is reincarnated as a superhero. Sarah is ambitious and it’s never clear what she does aside from ask the IT team to do work for her. You have Nancy, the main character’s wife, who understands but reminds him that his job sucks should he ever forget. And then there’s Erik.
Erik is the mysterious sensei type who guides Bill, the main character, to greener pastures and happy endings. There are a lot of riddles and descriptions of his clothing involved. By the end of the book, it turns out that Erik and Bill have a lot in common. Earlier, there is some type of seance where a few of the main characters dim the lights, sit around a table, and each reveal their “story.” Bill reveals that his father was a bad father--implying abandonment (yes, the book goes there). As I thought about it more while reflecting on why I didn’t enjoy this read, it seemed totally plausible that one of the authors, in an early draft of this book, planned to reveal Erik as Bill’s father. I'm not sure this would have taken the title for the most cringeworthy revelation.
The plot goes from bad to worse to bad. Part one lures you in, while part two is a droning mundanity. In part 3, the authors use chapter 30 to remind you that they’re well-read, and later take two pages to explain how the IT Team made a miracle happen and subsequently saved the company.
If you’re an engineer, don’t read this. If you’re on the non-technical manager spectrum, there’s something for you here. You have to parse through a lot of garbage--and I think you’re better off just digging in to more technically-oriented books--but there’s something for you here. You know how every manager has his the book? Please don’t make this your the book. You’re just a hypothetical to me right now and I’m confident that, regardless of your background, your precious time will be better spent reading something else. Truly, The Phoenix Project the book fails as embarrassingly as its namesake at Parts Unlimited.
September 16, 2015
Imagine an Ayn Rand novel where John Galt gives stilted lectures about ITIL and lean manufacturing instead of objectivism.
Update: It's not a great book, but if you're working in a dysfunctional IT environment and never manage to make it through any of the traditional business/tech books that could help you this would be a great place to start. Just promise you you won't stop here either. Another update: bumped up to three stars, I've read some two star stuff lately and this isn't that.
Update: It's not a great book, but if you're working in a dysfunctional IT environment and never manage to make it through any of the traditional business/tech books that could help you this would be a great place to start. Just promise you you won't stop here either. Another update: bumped up to three stars, I've read some two star stuff lately and this isn't that.
April 19, 2014
The copywriter gave up on p150, and so should you. Things start to go downhill when "illusive" replaces "ellusive", and the grammatical eccentricities snowball from there.
But wait, you ask ... if I stop now, how will I learn whether Bill masters the Three Laws? Will he develop a Mutually Supportive Working Relationship with the Information Security Officer? Will the Enigmatic guru, Erik, request an olive in his martini? Why Does This Book Make Me Want To Capitalize Everything? And however is Bill going to finally Meet Your Mother?
Some useful tools are introduced (Kanban boards, continuous deployment pipelines, etc) but with no detail -- presumably you are expected to purchase the authors' other book if you want concrete examples.
But wait, you ask ... if I stop now, how will I learn whether Bill masters the Three Laws? Will he develop a Mutually Supportive Working Relationship with the Information Security Officer? Will the Enigmatic guru, Erik, request an olive in his martini? Why Does This Book Make Me Want To Capitalize Everything? And however is Bill going to finally Meet Your Mother?
Some useful tools are introduced (Kanban boards, continuous deployment pipelines, etc) but with no detail -- presumably you are expected to purchase the authors' other book if you want concrete examples.
March 24, 2017
I lost count of the number of times my eyes almost rolled out of my head while reading this. Business-as-parable is a painful genre anyway, and this one is literally ten times longer than it needed to be.
(BTW, did you know Bill was in the Marines? I DO BECAUSE IT WAS MENTIONED EVERY CHAPTER.)
I did enjoy the part where he quit, though. Save yourself a few hours and just read the bit at the end.
(BTW, did you know Bill was in the Marines? I DO BECAUSE IT WAS MENTIONED EVERY CHAPTER.)
I did enjoy the part where he quit, though. Save yourself a few hours and just read the bit at the end.
August 27, 2017
This is the unicorn we'll be all hunting for the next 5+ years. De Marco's The Deadline finally found his spiritual successor.
Don't take this book too literally, like a prescription of rules to follow. The change that they're able to achieve in the book in the given timeframe is, well, quite unrealistic. Most companies don't face extinction and are not forced to reevaluate the way value is delivered. And if they do, changing the whole value stream and culture of a company is probably something that takes years and not weeks and months (if we talk about a normal mid-sized company).
But I very much like and appreciate the thinking model behind the novel, as expressed in The Three Ways. Quite eye opening for me. So far I always thought of 'DevOps' as 'You build it, you run it'. It never came to my mind that 'DevOps' also partially means system thinking, value stream optimization and most of all 'us' and not 'we' and 'them'.
I like to end this review with one of my favorite quotes from the book:
Being aware of this is a good start
Don't take this book too literally, like a prescription of rules to follow. The change that they're able to achieve in the book in the given timeframe is, well, quite unrealistic. Most companies don't face extinction and are not forced to reevaluate the way value is delivered. And if they do, changing the whole value stream and culture of a company is probably something that takes years and not weeks and months (if we talk about a normal mid-sized company).
But I very much like and appreciate the thinking model behind the novel, as expressed in The Three Ways. Quite eye opening for me. So far I always thought of 'DevOps' as 'You build it, you run it'. It never came to my mind that 'DevOps' also partially means system thinking, value stream optimization and most of all 'us' and not 'we' and 'them'.
I like to end this review with one of my favorite quotes from the book:
The relationship between IT and the business is like a dysfunctional marriage -- both feel powerless and held hostage by the other
Being aware of this is a good start
March 4, 2013
the prose was horrible - several very disconcerting shifts in tense were the least of it. and what did it teach me? that if I'm not in upper management nothing I do matters and I can't fix any of the problems plaguing my work. but if upper management just reads this book we will all go to a happy place and no one will balk except the moustache twirling villains who will either be fired or be reborn as if from a cocoon into their true form
July 12, 2018
This is a garbage corporate propaganda manual masquerading poorly as a novel for entitled white men in charge who want to put their fingers in their ears about the real problems of a workplace: stagnant wages, rampant sexism/racism, overwork, and other flavors of abuse.
"Maybe we don't need to pay workers more or give them sick pay, which would mean I wouldn't make $500K a year anymore...no, the solution is to 'streamline' everything. Perfect."
It's pretty ironic that the phrase "IT work has more in common with manufacturing plant work than he ever imagined" graces the back cover, since manufacturing work is highly unionized after a century of sacrifice and struggle by the lowest-paid employeed and is the go-to caricature for corrupt, selfish, greedy management.
"Maybe we don't need to pay workers more or give them sick pay, which would mean I wouldn't make $500K a year anymore...no, the solution is to 'streamline' everything. Perfect."
It's pretty ironic that the phrase "IT work has more in common with manufacturing plant work than he ever imagined" graces the back cover, since manufacturing work is highly unionized after a century of sacrifice and struggle by the lowest-paid employeed and is the go-to caricature for corrupt, selfish, greedy management.
August 17, 2015
Calling this a DevOps book is an understatement. The key to the company's success in the book wasn't automation or continuous delivery. What made the success transferable from the manufacturing plant floor to knowledge work was subordinating success criteria to top business measurements and rigorous application of the Theory of Constraints to achieve it. Of course, automation and continuous delivery are necessary intermediate steps for most traditional IT organizations on that journey.
The whole military theme was quite annoying throughout the book though.
The whole military theme was quite annoying throughout the book though.
July 4, 2018
This is the first book I've read cover-to-cover in an extremely long time. And what follows in this review are less my final impressions and more the way the book hit me as I dove into it. I still believe my criticisms are valid, but they have less impact on my enjoyment and my ability to absorb the interstitial lessons than I had expected. You are so forewarned.
As I'm reading the first few chapters, this book reminds me of my attitude towards the Agile Manifesto these days - "nobody understands how *hard* our job is - if only they'd listen - this is the bile-backed rant I'd give them - and everyone else will have to take a back seat to pitting the Developer's needs above everyone else's!" Yes I want to understand how you view the world, but when you take an extremely bitter and slanted view to everyone else's situation and needs, you aren't engendering a lot of sympathy from me in return.
I suspect for those who've been mired in the dungeon of the back office, underappreciated and never heard, this book is a godsend - "finally someone gets it!"
But here's a protip: if you cajole management (or any other players who aren't on your team) to read this, don't expect them to encounter their funhouse-mirror stereotypes in the book and make it all the way through with an open mind. Nor to wade through the pedantic, condescending lectures and be magically transformed into taking your side over everyone else's.
This is a lesson in managing up that I've learned the slow, hard way, and which I'm passing along as someone who's now part of the management layer: keep in mind that sometimes management hears you, even sometimes understand you, and *still* don't decide things your way. We generally have to take into consideration many competing perspectives, needs and constraints, and we often end up convinced of a different decision outcome than he one that most players want us to accept.
You might not like to hear that, and you may not sympathise with others' needs, and that's not something others can control. Don't like the decision?
Take a moment to imagine what other factors could have been more convincing (or constraining) *even if you don't agree they are important*. Chances are, most others in the organisation have just as unique a viewpoint as you, and rarely do they match.
The weirdest premise of the book that you're expected to swallow without question is that newly-promoted CIO-stand-in Bill, a previously mid-level-manager with no executive grooming, in a company where CIOs rotate every two years and whose initiatives are all aborted failures, will somehow be prepared for executive politics, know how to navigate the financial and interpersonal challenges at his new level, *and* will be wildly successful with this whole "DevOps" initiative than every other CIO initiative that preceded him (presumably some that even come from successful, highly experienced, externally-hired CIOs). Especially in an organisation so full of hostility towards any ideas that come from IT. When everyone around you treats you as the enemy, even objectively-successful initiatives are rarely recognised as "success".
Retroactive history-writing always goes to the victors of course, and they get to re-frame events however they like, so through that lens it's easy to see how Bill's choices are expected to be considered a deliberate winning strategy.
In the back of my mind, as they're setting the premise for how Bill will succeed at pulling the Phoenix Project from years-long delay into deployed and operational, I feel like asking someone, "Is this fairy tale grounded in any actual experience of pulling this off? Is there any reason for me to believe that by pulling the same levers Bill pulls, I too will have a great chance of succeeding at making giant software efforts live and breathe in production?"
And oh my gods are the condescending treatises thick in this book. For something attempting to read like a thriller, it takes on the start-halt style of Tom Clancy - no, more like Isaac Asimov - with stultifying regularity.
The tale of the complete clusterfuck in act one gets entertaining, but the authors lose all credibility when they create an excuse to drop a ridiculous deadline (that wouldn't be possible for an organisation 1/10 the size we're talking) on the team (and me knowing the punchline going in: our John Galt hero, knowing nothing of DevOps until now, invents, designs and implements perfect DevOps to turn a front-page disaster org into a model of efficiency and capability).
Puh-leeze.
And YET, I found myself up 2 hours past my bedtime reading this sucker two nights in a row - which must mean despite all my protestations, there’s something compelling about the story that I’m not acknowledging in all my criticisms.
Friends of mine who I talked to at the halfway point said, “it’s not exactly high literature”, “the supporting characters are more like paper dolls” and “didactic fiction isn’t meant to be enjoyed as pure storytelling”. I feel like this is an exercise in voluntary indoctrination, and I think I still have too much of an ego to submit and immerse myself into someone else’s biased point of view, without a whole lot of reflection and complaints.
By about page 300, I've finally noticed that I can't stop paying close, willing attention to every discussion (to understand exactly what change is being discussed, and how that should impact the larger efforts) and worrying what new surprises will screw with our heroes' Herculean progress.
My friggin heart is pounding, I'm stressed on behalf of Bill and crew, and I'm dying to see the evil villain Sarah smacked down hard. Maybe dragged away in chains, or pilloried for the undermining, posturing and backstabbing.
It occurs to me near the end that without an antagonist of this magnitude, the story wouldn't have such a tight lock on my attention. Dammit, for all my complaints about how painful the writing is, I still end up reading it like a madman.
My final impressions? As much as I bitch about the structure and players of this book, I'm here having made it ALL the way through (a first for me in a looong time) and I'm genuinely excited to put many of the lessons into practice myself. As skeptical as I can be of cults of personality, overall I have gratitude in my heart for Gene Kim and his co-authors, and I'll likely be an advocate for this book to others who were in my shoes just one week ago.
=== Edit ===
Looking back on this a while later, I recognise this for what it is: a religious text, meant to convert the suggestible novices over to a growing cult, told not through historical truths but through a series of parables, believable to the willing.
I can see now that nearly none of the “lessons” in the book prepared me for succeeding in a DevOps world, other than to make me suggestible for further ideas umbrella’ed under the DevOps Banner. Maybe the “working, good, fast” principle? But I suspect that comes from any systems design discipline.
But it was a fun, fictional read.
As I'm reading the first few chapters, this book reminds me of my attitude towards the Agile Manifesto these days - "nobody understands how *hard* our job is - if only they'd listen - this is the bile-backed rant I'd give them - and everyone else will have to take a back seat to pitting the Developer's needs above everyone else's!" Yes I want to understand how you view the world, but when you take an extremely bitter and slanted view to everyone else's situation and needs, you aren't engendering a lot of sympathy from me in return.
I suspect for those who've been mired in the dungeon of the back office, underappreciated and never heard, this book is a godsend - "finally someone gets it!"
But here's a protip: if you cajole management (or any other players who aren't on your team) to read this, don't expect them to encounter their funhouse-mirror stereotypes in the book and make it all the way through with an open mind. Nor to wade through the pedantic, condescending lectures and be magically transformed into taking your side over everyone else's.
This is a lesson in managing up that I've learned the slow, hard way, and which I'm passing along as someone who's now part of the management layer: keep in mind that sometimes management hears you, even sometimes understand you, and *still* don't decide things your way. We generally have to take into consideration many competing perspectives, needs and constraints, and we often end up convinced of a different decision outcome than he one that most players want us to accept.
You might not like to hear that, and you may not sympathise with others' needs, and that's not something others can control. Don't like the decision?
Take a moment to imagine what other factors could have been more convincing (or constraining) *even if you don't agree they are important*. Chances are, most others in the organisation have just as unique a viewpoint as you, and rarely do they match.
The weirdest premise of the book that you're expected to swallow without question is that newly-promoted CIO-stand-in Bill, a previously mid-level-manager with no executive grooming, in a company where CIOs rotate every two years and whose initiatives are all aborted failures, will somehow be prepared for executive politics, know how to navigate the financial and interpersonal challenges at his new level, *and* will be wildly successful with this whole "DevOps" initiative than every other CIO initiative that preceded him (presumably some that even come from successful, highly experienced, externally-hired CIOs). Especially in an organisation so full of hostility towards any ideas that come from IT. When everyone around you treats you as the enemy, even objectively-successful initiatives are rarely recognised as "success".
Retroactive history-writing always goes to the victors of course, and they get to re-frame events however they like, so through that lens it's easy to see how Bill's choices are expected to be considered a deliberate winning strategy.
In the back of my mind, as they're setting the premise for how Bill will succeed at pulling the Phoenix Project from years-long delay into deployed and operational, I feel like asking someone, "Is this fairy tale grounded in any actual experience of pulling this off? Is there any reason for me to believe that by pulling the same levers Bill pulls, I too will have a great chance of succeeding at making giant software efforts live and breathe in production?"
And oh my gods are the condescending treatises thick in this book. For something attempting to read like a thriller, it takes on the start-halt style of Tom Clancy - no, more like Isaac Asimov - with stultifying regularity.
The tale of the complete clusterfuck in act one gets entertaining, but the authors lose all credibility when they create an excuse to drop a ridiculous deadline (that wouldn't be possible for an organisation 1/10 the size we're talking) on the team (and me knowing the punchline going in: our John Galt hero, knowing nothing of DevOps until now, invents, designs and implements perfect DevOps to turn a front-page disaster org into a model of efficiency and capability).
Puh-leeze.
And YET, I found myself up 2 hours past my bedtime reading this sucker two nights in a row - which must mean despite all my protestations, there’s something compelling about the story that I’m not acknowledging in all my criticisms.
Friends of mine who I talked to at the halfway point said, “it’s not exactly high literature”, “the supporting characters are more like paper dolls” and “didactic fiction isn’t meant to be enjoyed as pure storytelling”. I feel like this is an exercise in voluntary indoctrination, and I think I still have too much of an ego to submit and immerse myself into someone else’s biased point of view, without a whole lot of reflection and complaints.
By about page 300, I've finally noticed that I can't stop paying close, willing attention to every discussion (to understand exactly what change is being discussed, and how that should impact the larger efforts) and worrying what new surprises will screw with our heroes' Herculean progress.
My friggin heart is pounding, I'm stressed on behalf of Bill and crew, and I'm dying to see the evil villain Sarah smacked down hard. Maybe dragged away in chains, or pilloried for the undermining, posturing and backstabbing.
It occurs to me near the end that without an antagonist of this magnitude, the story wouldn't have such a tight lock on my attention. Dammit, for all my complaints about how painful the writing is, I still end up reading it like a madman.
My final impressions? As much as I bitch about the structure and players of this book, I'm here having made it ALL the way through (a first for me in a looong time) and I'm genuinely excited to put many of the lessons into practice myself. As skeptical as I can be of cults of personality, overall I have gratitude in my heart for Gene Kim and his co-authors, and I'll likely be an advocate for this book to others who were in my shoes just one week ago.
=== Edit ===
Looking back on this a while later, I recognise this for what it is: a religious text, meant to convert the suggestible novices over to a growing cult, told not through historical truths but through a series of parables, believable to the willing.
I can see now that nearly none of the “lessons” in the book prepared me for succeeding in a DevOps world, other than to make me suggestible for further ideas umbrella’ed under the DevOps Banner. Maybe the “working, good, fast” principle? But I suspect that comes from any systems design discipline.
But it was a fun, fictional read.
December 27, 2017
Now this was a real treat for an IT guy! Finally I felt how the world sees us.
On a superficial, "Hey, IT guy!", everyday level.
On a deep, "Only IT guys know" level.
On a management, "What do you do, and do we even need you?" level.
On a spousal, "Are you still in the office?!" level.
I guess it's easier to see when things are happening to someone else.
Beware, for this will be just an average novel for non-IT people. Perhaps even less-than-average, as there's no standard plot you may expect.
But IT guys will love it! :-)
What would happen if CTO of your company gets fired... and you're unwillingly forced to fill in his shoes? Want the job or not, you have 2 years to get stuff sorted out, or you're next.
Then you realize how "stuff to sort out" basically means every IT resource in company, and those two years aren't really two years.
*Gulp!*
I loved every single page of this book. Although I bought Audible version [US/UK] as well, a friend loaned me his physical copy and I had a blast switching between them. Even combining, at times. Awesome narration, too!
Gene Kim, you are amazing! Thank you for showing me The Three Ways !
For IT guys this will be as educational as it will be fun. End result made me re-evaluate myself as a professional. I'm already working on purging bad habits I never realized I had, nor how far back they held me.
This was like listening to a life coach, but without all the bullshit :-)
Enjoyed 100/100.
if ($your_workplace -like "IT*") {
$grab_this_book -eq $true
} else {
pick_something_else()
}
On a superficial, "Hey, IT guy!", everyday level.
On a deep, "Only IT guys know" level.
On a management, "What do you do, and do we even need you?" level.
On a spousal, "Are you still in the office?!" level.
I guess it's easier to see when things are happening to someone else.
Beware, for this will be just an average novel for non-IT people. Perhaps even less-than-average, as there's no standard plot you may expect.
But IT guys will love it! :-)
What would happen if CTO of your company gets fired... and you're unwillingly forced to fill in his shoes? Want the job or not, you have 2 years to get stuff sorted out, or you're next.
Then you realize how "stuff to sort out" basically means every IT resource in company, and those two years aren't really two years.
*Gulp!*
I loved every single page of this book. Although I bought Audible version [US/UK] as well, a friend loaned me his physical copy and I had a blast switching between them. Even combining, at times. Awesome narration, too!
Gene Kim, you are amazing! Thank you for showing me The Three Ways !
For IT guys this will be as educational as it will be fun. End result made me re-evaluate myself as a professional. I'm already working on purging bad habits I never realized I had, nor how far back they held me.
This was like listening to a life coach, but without all the bullshit :-)
Enjoyed 100/100.
if ($your_workplace -like "IT*") {
$grab_this_book -eq $true
} else {
pick_something_else()
}
August 17, 2015
If looking for a "novel", this book will not get anything more than a 2 star from me. Very straight forward and simple story telling. But If you are in IT, this is an 5 star!
If you are a professional IT operation guy, this book is like reading a diary of your own and will guide you the way. If you are a newcomer to IT this shows you the underlying principals of some ITIL operational concepts.
Highly recommended if you are in IT.
If you are a professional IT operation guy, this book is like reading a diary of your own and will guide you the way. If you are a newcomer to IT this shows you the underlying principals of some ITIL operational concepts.
Highly recommended if you are in IT.
October 22, 2019
The very best book about this topic. I learned lot from this book — THANKS to authors.
October 18, 2019
This book garnered lots of attention, which I mostly think because the subject matter is dry and there aren't many books on the overall topic. The contrived company and scenarios in this book are far to0 simple, I didn't like the delivery mechanism for covering the tenets of the DevOps approach. I wouldn't work in these conditions, and neither should you. Go find a place that appreciates you and the important work of IT if you find yourself relating to0 closely to these shallow characters.
Some of the basic principals are valid, it doesn't take a rocket scientist to figure out things might work out better if Development and Operations work more collaboratively, does it?
Finally, this book was clearly written by an "Ops" guy. The Us vs Them throughout the entire story arc is tiring. Maybe a different approach altogether would yield the DevOps enlightenment a bit earlier.
Two stars are all I could muster here, lots of contradictory data in the story, too many "aha" moments, and everything wraps up in nice bow at the end, including promotions for the whole team. :)
Some of the basic principals are valid, it doesn't take a rocket scientist to figure out things might work out better if Development and Operations work more collaboratively, does it?
Finally, this book was clearly written by an "Ops" guy. The Us vs Them throughout the entire story arc is tiring. Maybe a different approach altogether would yield the DevOps enlightenment a bit earlier.
Two stars are all I could muster here, lots of contradictory data in the story, too many "aha" moments, and everything wraps up in nice bow at the end, including promotions for the whole team. :)
October 7, 2013
Great read, wonderful description of IT. As a novel quite OK.
October 21, 2018
This is a novel about a company in crisis because IT and software development form a bottleneck for every aspect of the business. The rest of the business has blinders on, and doesn't even really understand their dependencies on IT and software. Sound familiar?
The CEO brings in a potential new board member who enlightens the VP of IT in "lean" methodologies for IT.
For those of us devoted to agile methodologies in software, there is not a lot that is surprising in matter of detail. But the big picture is a devastating take-down of business-as-usual for non-software businesses.
In this case, the company in question is a manufacturing business for automotive and motorcycle parts (I think; the book is strangely quiet on some of the details about what the company really is) with retail stores.
Focusing on a non-tech/software business is a smart move, because the software industry has known a lot about lean for some time. But the idea here is taking the lean methodologies from manufacturing, and bringing them to IT, within a traditional company.
In short, the audience is absolutely not (or should not be) a software company, but rather something more like a brick-and-mortar business with an online store.
I will quote from near the end of the book -- this isn't a spoiler. Think of it as a tease to get you to read the book: "In ten years, I'm certain every COO worth their salt will have come from IT. Any COO who doesn't intimately understand the IT systems that actually run the business is just an empty suit, relying on someone else to do their job" (pp. 332-333).
The CEO brings in a potential new board member who enlightens the VP of IT in "lean" methodologies for IT.
For those of us devoted to agile methodologies in software, there is not a lot that is surprising in matter of detail. But the big picture is a devastating take-down of business-as-usual for non-software businesses.
In this case, the company in question is a manufacturing business for automotive and motorcycle parts (I think; the book is strangely quiet on some of the details about what the company really is) with retail stores.
Focusing on a non-tech/software business is a smart move, because the software industry has known a lot about lean for some time. But the idea here is taking the lean methodologies from manufacturing, and bringing them to IT, within a traditional company.
In short, the audience is absolutely not (or should not be) a software company, but rather something more like a brick-and-mortar business with an online store.
I will quote from near the end of the book -- this isn't a spoiler. Think of it as a tease to get you to read the book: "In ten years, I'm certain every COO worth their salt will have come from IT. Any COO who doesn't intimately understand the IT systems that actually run the business is just an empty suit, relying on someone else to do their job" (pp. 332-333).
February 8, 2018
A beautiful story about heroic manages on their journey to increase the resource throughput, the resource utilization, as well as resource task standardization. I was especially touched when all of the IT managers were gathered together and did their best to build the trust relationship between themselves by sharing the most precious memories of their lives and opening their hearts to the overwhelming human emotions of their peers. I think this was a pivotal moment for the whole management team which gave them confidence, courage, and determination to optimize the resource throughput and utilization to an extent never seen before in a prospect of a tragic company downfall. It is hard to overemphasize the importance of the key resource, Brent...
Ok, it's enough. It was incredibly frustrating to read this book. I started to wonder how different destiny of the Parts Unlimited and Phoenix Project would be if the management team would try to practice less micro-management and show just a sign of appreciation that these 150+ resources that they are managing are actual human beings quite capable of fulfilling the company's vision without their command and control, given that they at least try to create an appropriate environment for it. This book gave me an interesting new perspective on the Kanban.
I could barely stand the first half of the book. The second half of the book made me physically sick.
Ok, it's enough. It was incredibly frustrating to read this book. I started to wonder how different destiny of the Parts Unlimited and Phoenix Project would be if the management team would try to practice less micro-management and show just a sign of appreciation that these 150+ resources that they are managing are actual human beings quite capable of fulfilling the company's vision without their command and control, given that they at least try to create an appropriate environment for it. This book gave me an interesting new perspective on the Kanban.
I could barely stand the first half of the book. The second half of the book made me physically sick.
February 2, 2017
when i dove into this book, i thought i had an idea, i thought it's inspiring, tutoring..anything, it's just plain boring, it talks about working..literally working, in a cubicle , the kind of thing you read your entire life NOT to do, or even to escape it, it's like doing work with your eyes ( or in my case ears because i was listening to the audio) , i have no idea who would read this, it might appeal to some people, but i don't think that that kind of working people have the time to read this kind of books, and for the rest of us just...WHY? well when you wanna venture out side of you reading comfort zone this might happen. when this happens just GTFO and read on!
October 9, 2013
OK. So it's not The Goal. The inspiration and the parallels are obvious (even explicit) and the story is entertaining but personally I didn't find it as ground-breaking. It can be very good for people to get a basic understanding of the many concepts (flow, WIP, TOC, systems thinking, ...) The focus of the book is firmly on the operational side of IT and any parallels with software development must be taken with care.
March 20, 2021
30 Seconds In
The first paragraph is just the main character answering his cell phone. The second paragraph is establishing that he is an asshole, because he he is answering his cell phone while speeding 10 MPH over the limit, after having been at a doctor 's office "trying to keep the other toddlers from coughing on us", so basically he's a privileged self-absorbed shitheel who doesn't appear to have any regard or thought for other people. Wow. This is not an auspicious start, but this book has been flung at me by multiple people now so I shall continue on, despite the fact I already hate this fucker.
Making Progress
There he is again on page 216 "breaking every speed limit", however by this point we also have several other asshole characters for example Steve who just declares that everything must get done while ignoring the massive dysfunctionality of this mythical company, and Sarah the executive who happily undermines other teams while demanding that her own pet project gets any resource she wants at anytime.
There are quotes like this "Show me a developer who isn't crashing production systems, and I'll show you one who can't fog a mirror." that show just how horribly cynical virtually everyone depicted has become. I almost took that one personally because I think of my current team of developers who routinely produce working software without crashing production systems, on a regular cadence.
Stepping Back
But let me put aside my personal indignation and acknowledge that I have in the past worked with
1) Every single one of these characters in one form or another.
2) Worked for companies that have had similar forms of dysfunctionality.
3) Had utterly unreasonable demands placed upon my team, "no matter what the cost"
The company depicted here may be slightly exaggerated, in just how bad it is, but in the fine details each of the specific problems is quite realistic. This company represents a conglomeration of a huge number of the real life problems that IT organizations exhibit.
Personal Experience
My second long term job was with a long defunct startup company that had 5 sections each trying to do different things, but all controlled by a megalomaniacal CEO and his family, who it turned had been embezzling which explained in retrospect why the paychecks would bounce, and then he would come swooping in with money to save the day on a very regular basis. We survived multiple rounds of near death, and then funding, absurd promises made for amazing software, unrealistic deadlines, many late nights recovering from disasters (often self-made) and then finally died during the dot.com bubble crash of 2000.
My next job was with a now defunct company that made software for lean manufacturing, which is exactly what this book is about. During that job I learned about concepts like single-piece flow, WIP reduction, continuous improvement, and how to identify and correct bottlenecks. All these concepts are major parts of this book. Ironically, the company did not apply those same principles to our own software development cycle, and instead we had more or less formalized waterfall methodology with 6 months of design, 6 months of coding, 6 of QA, after which we struggled against larger behemoths who could strongarm companies into not buying our software even when it was better, because of marketing and package deals, done in corporate bedrooms. I mean boardrooms. At that company there was one project that had been promised to be done in 3 months by a sales guy, which the dev team said would take minimum 9 months, but we were tasked to "get it done". I worked a run of 32 continuous days 16 to 18 hours a day, sleeping under my desk when I couldn't function, and working a short 10 hour day on either Saturday or Sunday so I could go home and take care of basics. After 32 days I told my boss I was going to take a weekend or else I was "going to kill someone". He let me take the weekend. Ultimately we were acquired by one of the behemoths, and then slowly and systematically dismantled and the entire team was terminated 1.5 years later.
My next job was with yet another startup, and when I got there it was a mess, but at least we had customers, and a reasonable runway. However the market was tough, there were ups and downs, and development was shaky. Deployments were exciting, and could sometimes run overnight as problems were found, fixed on the fly, and occasionally after overnight attempts to fix would be backed out, which was also fraught with danger. We slowly switched over to Agile practices. At some point one of my bosses brought in an Agile expert. I was skeptical, but fortunately he was not a smug, mysterious asshole like the one depicted here in this book. We listened, we argued, and then slowly we started adopting practices and making changes.
And it worked.
Not all at once, and the transformation was not on the magically short time-frame that is presented in this book, but with persistent and diligent application of key concepts we slowly progressed from being constantly in fire-fighting mode into a mature development organization that delivers working software on a continuous pace, with relatively few defects, and moreover we are predictable. When new work is brought to us, we are able to provide surprisingly accurate estimates based on story points, which my direct report boss can turn into road maps that he present to the higher-ups. Deployments are now boring, as they should be, and on the rare occasions when something goes wrong, we can easily back out, and then we follow up with an analysis to determine what went wrong, and we fix it.
To me, some of the most important lessons to learn included the idea of always looking for ways to improve processes. If something doesn't work - stop doing it. Focus on problems that you have the ability to fix. Focus on those problems that create the most waste. Remove bottlenecks. Make things repeatable. There are plenty more.
There were other factors in our journey to improvement, including substantial attrition. There were lots of developers that just needed to go because they either could not wrap their heads around the ideas, or were extremely difficult to work with, or wanted to be rock stars. This book really only deals with that aspect in the character of Sarah, but she was executive level, not development.
The team I work with now still has a long way to go, but we are on the right path, and we keep working towards ideas in this book.
Wrap It up, You Long Winded Bastard
If I were to rate this book as a fictional novel, it would be at best 2 stars. The characters are wafer-thin and would certainly make Mr. Creosote vomit. The plot is relatively straight-forward, and is compacted a bit too much if the intent is to depict a real company transformation. But that's not really the point. This book is intended to convey certain ideas, and whether or not all people would agree (I have personal friends who screech and wail on a regular basis about how much they hate Agile - but in every case they attack with strawman arguments) those ideas can in fact make vast improvements in an IT organization. If you are reading this novel it should be with the goal to understand those ideas.
The first paragraph is just the main character answering his cell phone. The second paragraph is establishing that he is an asshole, because he he is answering his cell phone while speeding 10 MPH over the limit, after having been at a doctor 's office "trying to keep the other toddlers from coughing on us", so basically he's a privileged self-absorbed shitheel who doesn't appear to have any regard or thought for other people. Wow. This is not an auspicious start, but this book has been flung at me by multiple people now so I shall continue on, despite the fact I already hate this fucker.
Making Progress
There he is again on page 216 "breaking every speed limit", however by this point we also have several other asshole characters for example Steve who just declares that everything must get done while ignoring the massive dysfunctionality of this mythical company, and Sarah the executive who happily undermines other teams while demanding that her own pet project gets any resource she wants at anytime.
There are quotes like this "Show me a developer who isn't crashing production systems, and I'll show you one who can't fog a mirror." that show just how horribly cynical virtually everyone depicted has become. I almost took that one personally because I think of my current team of developers who routinely produce working software without crashing production systems, on a regular cadence.
Stepping Back
But let me put aside my personal indignation and acknowledge that I have in the past worked with
1) Every single one of these characters in one form or another.
2) Worked for companies that have had similar forms of dysfunctionality.
3) Had utterly unreasonable demands placed upon my team, "no matter what the cost"
The company depicted here may be slightly exaggerated, in just how bad it is, but in the fine details each of the specific problems is quite realistic. This company represents a conglomeration of a huge number of the real life problems that IT organizations exhibit.
Personal Experience
My second long term job was with a long defunct startup company that had 5 sections each trying to do different things, but all controlled by a megalomaniacal CEO and his family, who it turned had been embezzling which explained in retrospect why the paychecks would bounce, and then he would come swooping in with money to save the day on a very regular basis. We survived multiple rounds of near death, and then funding, absurd promises made for amazing software, unrealistic deadlines, many late nights recovering from disasters (often self-made) and then finally died during the dot.com bubble crash of 2000.
My next job was with a now defunct company that made software for lean manufacturing, which is exactly what this book is about. During that job I learned about concepts like single-piece flow, WIP reduction, continuous improvement, and how to identify and correct bottlenecks. All these concepts are major parts of this book. Ironically, the company did not apply those same principles to our own software development cycle, and instead we had more or less formalized waterfall methodology with 6 months of design, 6 months of coding, 6 of QA, after which we struggled against larger behemoths who could strongarm companies into not buying our software even when it was better, because of marketing and package deals, done in corporate bedrooms. I mean boardrooms. At that company there was one project that had been promised to be done in 3 months by a sales guy, which the dev team said would take minimum 9 months, but we were tasked to "get it done". I worked a run of 32 continuous days 16 to 18 hours a day, sleeping under my desk when I couldn't function, and working a short 10 hour day on either Saturday or Sunday so I could go home and take care of basics. After 32 days I told my boss I was going to take a weekend or else I was "going to kill someone". He let me take the weekend. Ultimately we were acquired by one of the behemoths, and then slowly and systematically dismantled and the entire team was terminated 1.5 years later.
My next job was with yet another startup, and when I got there it was a mess, but at least we had customers, and a reasonable runway. However the market was tough, there were ups and downs, and development was shaky. Deployments were exciting, and could sometimes run overnight as problems were found, fixed on the fly, and occasionally after overnight attempts to fix would be backed out, which was also fraught with danger. We slowly switched over to Agile practices. At some point one of my bosses brought in an Agile expert. I was skeptical, but fortunately he was not a smug, mysterious asshole like the one depicted here in this book. We listened, we argued, and then slowly we started adopting practices and making changes.
And it worked.
Not all at once, and the transformation was not on the magically short time-frame that is presented in this book, but with persistent and diligent application of key concepts we slowly progressed from being constantly in fire-fighting mode into a mature development organization that delivers working software on a continuous pace, with relatively few defects, and moreover we are predictable. When new work is brought to us, we are able to provide surprisingly accurate estimates based on story points, which my direct report boss can turn into road maps that he present to the higher-ups. Deployments are now boring, as they should be, and on the rare occasions when something goes wrong, we can easily back out, and then we follow up with an analysis to determine what went wrong, and we fix it.
To me, some of the most important lessons to learn included the idea of always looking for ways to improve processes. If something doesn't work - stop doing it. Focus on problems that you have the ability to fix. Focus on those problems that create the most waste. Remove bottlenecks. Make things repeatable. There are plenty more.
There were other factors in our journey to improvement, including substantial attrition. There were lots of developers that just needed to go because they either could not wrap their heads around the ideas, or were extremely difficult to work with, or wanted to be rock stars. This book really only deals with that aspect in the character of Sarah, but she was executive level, not development.
The team I work with now still has a long way to go, but we are on the right path, and we keep working towards ideas in this book.
Wrap It up, You Long Winded Bastard
If I were to rate this book as a fictional novel, it would be at best 2 stars. The characters are wafer-thin and would certainly make Mr. Creosote vomit. The plot is relatively straight-forward, and is compacted a bit too much if the intent is to depict a real company transformation. But that's not really the point. This book is intended to convey certain ideas, and whether or not all people would agree (I have personal friends who screech and wail on a regular basis about how much they hate Agile - but in every case they attack with strawman arguments) those ideas can in fact make vast improvements in an IT organization. If you are reading this novel it should be with the goal to understand those ideas.
May 5, 2018
Aufgrund hymnischer Amazon Bewertungen und Nennungen auf Security Konferenzen habe ich mich zu diesem Buch hinreissen lassen. Es Roman zu nennen ist leicht übertrieben.
Im Minutentakt wird in Form eines Bullshit-Bingo jede verfügbare Business-Sau durchs Dorf getrieben, die auffindbar ist. Bei Begriffen wie Lean-Management, Kanban, usw. riegelt mein Gehirn automatisch ab. Etwa so, wenn die Zeugen Jehovas vor der Tür stehen und mit mir über Glück reden wollen.
Abgesehen davon, dass dieses Buch aus literarischer Sicht Mist ist, eine Beleidigung jeden Intellekts und in der Tat ein Sachbuch - ist es aus soziologischer und sozialanthropologischer Sicht dennoch interessant.
Ganz in US-Manier erinnert sich der Protagonist immer an seine lehrreiche Zeit bei den Marines und vergleicht diese mit dem Business. Gearbeitet wird grundsätzlich immer bis zum umfallen. Nächtelang durch, alle sind topmotiviert - Anrufe werden während des hinlegens der Kinder angenommen und zeitgleich werden bei der Gutenachtgeschichte Firmen-Emails gecheckt. Das ist alles so selbstverständlich wie der Otto-Normal-Ami eben keine Krankenversicherung hat. Ayn Rand lässt grüßen. Wochenden mit der Familie fallen eben mal aus, weil es einen "Sev-1 Vorfall" gibt. Bei der Erwähnung von Rüstzeiten und Taktzeiten am Fließband fühlt man sich endgültig in die industrielle Produktion des Fordismus zurückversetzt.
Leid kann einem nur der US-Amerikanische Leser tun. Der hat zwischen O'Reilly Fachbüchern und diesem Schmonzes nur mehr die Wahl zwischen Harry Potter, Ken Follet oder seichten Krimi/Thriller/Fantasygeschichten mit bunten Covern.
Im Minutentakt wird in Form eines Bullshit-Bingo jede verfügbare Business-Sau durchs Dorf getrieben, die auffindbar ist. Bei Begriffen wie Lean-Management, Kanban, usw. riegelt mein Gehirn automatisch ab. Etwa so, wenn die Zeugen Jehovas vor der Tür stehen und mit mir über Glück reden wollen.
Abgesehen davon, dass dieses Buch aus literarischer Sicht Mist ist, eine Beleidigung jeden Intellekts und in der Tat ein Sachbuch - ist es aus soziologischer und sozialanthropologischer Sicht dennoch interessant.
Ganz in US-Manier erinnert sich der Protagonist immer an seine lehrreiche Zeit bei den Marines und vergleicht diese mit dem Business. Gearbeitet wird grundsätzlich immer bis zum umfallen. Nächtelang durch, alle sind topmotiviert - Anrufe werden während des hinlegens der Kinder angenommen und zeitgleich werden bei der Gutenachtgeschichte Firmen-Emails gecheckt. Das ist alles so selbstverständlich wie der Otto-Normal-Ami eben keine Krankenversicherung hat. Ayn Rand lässt grüßen. Wochenden mit der Familie fallen eben mal aus, weil es einen "Sev-1 Vorfall" gibt. Bei der Erwähnung von Rüstzeiten und Taktzeiten am Fließband fühlt man sich endgültig in die industrielle Produktion des Fordismus zurückversetzt.
Leid kann einem nur der US-Amerikanische Leser tun. Der hat zwischen O'Reilly Fachbüchern und diesem Schmonzes nur mehr die Wahl zwischen Harry Potter, Ken Follet oder seichten Krimi/Thriller/Fantasygeschichten mit bunten Covern.
January 24, 2018
Love this book for every reason I didn't think I would get out of it when I started it. Picked it up on a friend's rec. I've read other biz books including those that focus on IT, but what I really enjoyed with this one is that it told a story rather than lectured. About half-way through I switched from being entertained to thinking more about my process (creating an info product... an online video course) and how I can improve it. The story part of the book helped me personally because while I get what you're supposed to be doing, the *process* part was my big takeaway. That's what I applied to my business and already reaping the rewards wiht many more things to experiment and implement.
BTW... Sarah is a dumbass arrogant bitch and Bill should have told her that to her face on more than one occasion.
BTW... Sarah is a dumbass arrogant bitch and Bill should have told her that to her face on more than one occasion.
March 21, 2018
It starts promising, and it gets you hooked. The story of a failing IT department due to unreasonable business behaviour is all too familiar. The book takes you on an interesting journey along side it's characters and it provides a glimpse inside the day to day life of software people. The ending however is rushed and feels like a romantic comedy when good prevails in the end and all evil is beaten. I would still recommend this book to any business person that has no idea on how software works and wants to start a software project.
August 1, 2020
This is an IT business book, cast as a work of fiction. A middle-management IT guy who works for an auto-parts manufacturer is suddenly thrust into a high-level position by an insistent CEO. The IT guy doesn't really understand what led him to accept the promotion--he certainly didn't want it. Immediately after accepting the new job, a cascade of IT disasters hits the fan. Employees aren't going to be paid because of software glitches, A very important "Phoenix Project" that will be a new point-of-sale program is overdue and over-budget, and the CEO insists that it be deployed despite the fact that it is untested. And auditors are at the door, with growing evidence that customer information is leaking out due to faulty security patches.
A grey-beard on the board gives advice to the IT guy--well, he gives him some ambiguous guidance, allowing the IT guy figure much of it out by himself.
This is really a book about IT administration, and it is very clever how the reader starts to sympathize with the characters. There is even a villain in the story, who seems to cause trouble at every step.
I am not in the IT business, but the book was quite entertaining nevertheless. There is lots of jargon and IT-speak, but that does not detract from the enjoyment. And, for programmers as well as managers, this book could be very useful.
A grey-beard on the board gives advice to the IT guy--well, he gives him some ambiguous guidance, allowing the IT guy figure much of it out by himself.
This is really a book about IT administration, and it is very clever how the reader starts to sympathize with the characters. There is even a villain in the story, who seems to cause trouble at every step.
I am not in the IT business, but the book was quite entertaining nevertheless. There is lots of jargon and IT-speak, but that does not detract from the enjoyment. And, for programmers as well as managers, this book could be very useful.
April 6, 2021
Grāmata specifiskam interesentu lokam. Aizraujošā veidā (šis nav non-fiction) māca par to, ko sola nosaukumā.
August 1, 2017
This is a great book and a must read for any IT professional or manager. Anyone who ever worked for a medium to large organisation will immediately identify themselves with the situations described in the book. If you are not familiar with Lean, Theory of Constraints, Agile methodologies, and DevOps, you have an extra motive to read this book. But if you are already familiar with those things, you should read this book anyway, purely for the entertainment value. I'm sure you will learn a few good lessons from it. Highly recommended.
February 13, 2013
"The Goal" for IT DevOps. Great read, packed with plenty of real-life project-based observations that are both credible and meaningful in terms of improving devops perspective of IT projects. A-must-read for every Kanban practicioner-wannabe. As well a great pre-requisite for Jez Humble's "Continuous Delivery" (that is even mentioned in the book literally).
August 17, 2015
Just like Tom DeMarco's Deadline almost two decades ago this is an absolute must read for everyone who's even remotely involved with IT, management, and operations in any kind of business in this day and age.
Displaying 1 - 30 of 3,827 reviews