If you are reading this blog there is a good chance you work in (or around) a formalized IT department.
That also means you are on, or near, a sinking ship.
Don’t believe me? Then do what I did and read The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win
Two weeks ago I was told by my friend Karen López (blog | @datachick) that I needed to read this book. As with most of her recommendations to me this one did not disappoint. The Phoenix Project is the story of the IT department for a fictional manufacturing plant and the struggles they face daily. This book is not a “how-to” manual, it is a fictional story that resonated well.
To me the beauty in this book is that the industry didn’t matter. It could have been an insurance company, financial services, or software. The scenarios described in The Phoenix Project will strike a chord with anyone.
I don’t want to spoil the book for anyone that decides to purchase and read, but I will note a few items that I think need mentioning here. These are the items that are the reason your ship is taking on water.
1. Unplanned work
Ever feel that the reason you can’t get your work done is because you are too busy doing work? You should read this book.
2. IT departments are not treated as a core competency
Ever known an entire IT department to be outsourced because the business felt that was the best option? You should read this book.
3. Deployments only go one way: forward
Ever try to deploy something and be told that you can’t roll back changes, that you need to just “make it work”? You should read this book.
4. Self service tools
Ever have a department decide to simply go around IT because IT was “too slow”? You should read this book.
5. Collaboration
Ever feel as if nobody in your company can talk to each other or work together towards a common goal? You should read this book.
I don’t want you to believe that I am writing this review and thinking that “DevOps” is the answer for every IT issue. It isn’t. In fact DevOps isn’t anything new to me. I consider it to be just a buzzword to describe a business problem that has existed for decades. I further believe that the DevOps movement is really being borne out of necessity, a necessity that has been brought about as a result that there is a dearth of good managers in IT today.
However there is no question in my mind that every business leader and IT professional should read this book. It offers many insights that are lacking within many IT on-boarding programs. That’s why I have added The Phoenix Project to my SQL Server Books page, under the Professional Development section.
Looks great. By freak accident I came across this and bought it today too. Looking forward to reading it.
So, Tom… is this book going to make me depressed? Because, seriously, just reading this post made me depressed :-/
The book didn’t make me depressed, no. It gave me hope.
I just finshed reading this book, based on your recommendation, and had no problem identifying a real person with all of the fictional characters. It brought back some bad memories of failed deployments and the heroics required to get the job done.
Tim,
Glad you enjoyed the book! I also found it easy to identify specific persons to the fictional characters.
I just finished reading “Tribes” by Seth Godin. A co-worker suggested it to me because they knew I am interested in that subject matter as I had mentioned “The Phoenix Project” book to them a while ago. It is focused on leadership and I believe you epitomize what he describes a leader to be. A quick read and I think you may enjoy it if you haven’t read it already.
Yessir, I’ve got that book on my shelf already. Thanks!
Took forever, but finally got to where I read this book. The sad thing about this book, listening to a lot of folks that have read it, is they are picking and choosing what they like (basically, what support their positions) rather than paying attention to the overall narrative. There are a LOT of changes the IT team implements. Those changes deal with issues they had up and down their deployment and operations departments. And each one attacked a particular problem area that we frequently see in dev and IT operations regardless of organization. Cherry picking isn’t enough.
Thanks for the comment KBK, and I agree with your summary. However…it’s a book, and the author seemed to want to paint a very specific picture IMO. I don’t find that sad, I see it as the beginning of a good dialogue for IT pros to have.