Top Lessons and Thoughts From The Phoenix Project

Below are the highlights from the post I just published. To read the full post with highlights from the book go here

My Thoughts

Listing to this book is the only method of consumption I can recommend. I am a little biased since this is the way I have decided to approach it. However hear me out:

It is not as dense with useful material as pure nonfiction books, so you don't need to make a ton of highlights.
It is a little to basic to be read like a proper novel.
It is a great way to learn about DevOps principles while doing simple activities like exercising, dish washing, etc.

In my experience I have been not to succesfull in staying engaging when listening to non-fiction books. This was perfect however. So, with the method of consumption out of the way, what did I think about this book.

It is really good. If you are a programmer, you journey is very likely to be a unique one. In my case for example, I learnt to program myself, and when I got my first full-time gig programming, the team I was on was already implenenting the principles mentioned in this book. Everything was documented, all the processes were automated with Github Actions and or project manager did a great job keeping the projects in Agile format.

If you have never heard of DevOps procedures, than you might recognize a lot of characters from this book. You will likely learn quite a few things.

All of that said, the principles described in this books have already penetrated the industry deep enough, so anyone who is doing programming these days, even if you are an Indiehacker you likely you something like that.

I would certainly recommend people listen to this book as a complement to the everyday routine. It might motivate you to be more structured about your work, like it did for me.

Summary

The story revolves around the character of Bill, who is tasked with reviving a struggling IT department at a company called Parts Unlimited. Through his journey, the reader is introduced to various IT concepts, such as Agile, Lean, and DevOps, and the benefits they can bring to an organization. Here are some of the lessons you will encounter while consuming this book:

Document as many procedures as possible.
Don't have a star programmer who is the only one who knows how to fix something. If you see someone like that tell them to follow step one to make sure as many people know how to do any given thing.
Automate all the repetetive processes: Unit testing, Deployments, Updates, etc. You may find more tutorial on this topic by searching for terms like continuous integration, continuous delivery, and continuous improvement.
Try to keep tech debt to a minimum and if that exists resolve as soon as possible. Point 1 and 3 will help with that a lot!
Consider learning about Agile and Lean methodologies. Optional! I think (personally) that this mostly means that you should use a Kanban board and move things along as you work through them. This point might mean more to bigger teams, I don't have such experience.