(Warning: You’ll never look at the toilet in the same way again)
So I’ve been enjoying the great Green Circle Podcast over the last few months (and if you haven’t been listening, you should!). At the end of each podcast, Eric asks the guest what books they are reading or what books they want everyone to check out. And pretty much every single person recommends the same book – The Phoenix Project. As an avid reader, I added this to my reading list, and finally read the book a couple of weeks ago.
At first, I wasn’t sure I was going to enjoy this. It’s a novel about DevOps, written from the perspective from the VP of Operations in a publicly traded company, their IT was literally about to destroy the company from the beginning of the book. My expectations were measured. A few hours later, I had not only read the book, I had highlighted several passages, written a couple of notes, and had a long list of follow up material I wanted to read as well. In other words, GREAT book, if you haven’t read it and you work in IT, you need to get this ASAP. I’ll try and give you a spoiler-free review.
The main character in the story is Bill, who starts out as an IT manager. He gets a call saying the CEO wants to see him. Apparently, the CIO and VP of Operations have left the company, and he’s been promoted to VP of Operations while the CEO will act as CIO for the time being. Which should be good news right? Not for Bill. In his view, Senior Management have very short tenures (CIO stands for Career Is Over apparently, I chuckled at that).
Just before he leaves the room, they have this conversation:
“What I want is for IT to keep the lights on. It should be like using the toilet. I use the toilet and, hell, I don’t ever worry about it not working. What I don’t want is to have the toilets back up and flood the entire building”
Great. In his mind, I’m a glorified janitor.
I love this line so much, I’ve incorporated it into a training exercise at work. As cheesy as it sounds, it’s a great analogy for how IT should function in an organization.
The story then begins. In fact, before he even leaves the room, the CEO gives him a printed out email asking him to solve a HUGE crisis with the Payroll systems. Let’s just say that at the end of that weekend, it would have been better if the toilets had backed up and flooded the building.
The IT at Parts Unlimited is basically lurching from Crisis to Crisis. As a result, no one can focus on Project Phoenix, a huge project that will allow the company to catch up with the competition. The Operations and the Development teams are pointing fingers at each other as they struggle to keep the lights on and work on Phoenix at the same time. The Phoenix project co-ordinator is tenacious, and she won’t budge on the deployment date. Poor Bill initially gets completely overwhelmed.
There’s a virtualization reference in the story, which I’ll highlight, again, something which sounds very familiar to many, it’s a story I hear frequently in my current role.
“We made a huge investment in virtualization, which was supposed to save us from things like this. But when Development couldn’t fix the performance problems, they blamed the virtualization. So we had to move everything back to physical servers!”
Side note(and shameless self promotion): Ask them to read this article if they want to solve that problem.
It’s hard for me to say much more without ruining the story for anyone else. All I’ll say is that it’s kinda like an American movie. A wise old man (in the form of a prospective board member) comes in, and kinda like Yoda, he’s a weirdo, but he knows his stuff. He shows Bill the ropes, by making him look at IT from a different perspective, and slowly by surely, Bill manages to steady the ship, and becomes an unlikely hero. There’s moments when it looks like it’s all going to come crashing down (it almost does), but thankfully it all ends well, and our hero has his day in the sun.
There’s lots to learn as well about DevOps. When I was in Operations, I was fortunate enough to be managed by a former developer, and have great relationships with the Dev team, so we were able to function quite seamlessly, and nip most problems in the bud. This book gives a great example of how to move to a DevOps operation and the ensuing benefits. There’s a lot in it about how to manage teams effectively. Lots of stuff about ITIL in there as well, which I was very happy to see, and I’ve decided to read up on Kanban after this, I had never heard about that before this book.
The above paragraph looks very nerdy and boring. Let me assure you, that the books makes digesting all the topics very enjoyable. It’s a great story and a very educational book, go and read it now !