This week I am going over a few resources that I have run across that have shaped, changed, or completely rocked my career in technology. Today I want to start with the book that started my current career arc in a way that led to some of the best outcomes like working a sane number of hours per week, dealing with fewer panicky late night issues, and having an overall increase in career and personal wellness. I know that is a lot to put on just one book, but it was so impacting in a way that made me realize that I should not just keep doing my job the same way “because that’s the way we’ve always done it”.
In the same way that manufacturing and the auto industry woke up to the various ideas around Kanban and continuous improvement, the software and technologies industries had edge cases of companies and organizations adhering to these unique ideas. But it’s only been in the last decade or so that you see technology across the board grasp onto ideals like Agile, Scrum, and Continuous Delivery among so many other buzzwords. However, most organizations are using these efficient processes around only software delivery or IT infrastructure, but the entire organization still sticks to a waterfall mentality. You see this with many companies talking about “water-scrum-fall” or “water-agile-fall” and other such amalgamations of cultures. While efficiency improvement in tech departments is something to strive for, these tenants are about more than just making tech be a better version of itself.
In 2013 I ran across a random internet thing about this book and got the digital version on Amazon. I wish I could remember the details, maybe it was a blog post or a tweet from Gene Kim. Regardless, once I opened it up, I stayed up until 3 AM the next morning to finish it. It made me feel crazy and alive like the first time Neo sees the Matrix for what it is. I wanted to, as my colleagues put it, “DevOps All The Things!” After some tempering and directional assaults on a few pain points, we realized that we were not just solving a problem with some automation. We were actually changing the mindset of people on our team, and it was starting to positively affect the culture of the rest of the organization as well. People were happy to collaborate with the Ops team because we were working to solve problems, not just continuing to be an obstacle that people navigated around.
The most difficult lesson we learned from the book and still have to re-learn every so often, is that the organization as a whole is hesitant to change. We learn that we do not directly change the company or its processes, we first change ourselves. Time and time again, we ask others around us to change their processes like “put in a ticket before you talk to us” or “do not expect an immediate response on email or IM”. And again we have to realize that culture change is behavior change or training. We start putting in tickets for people that walk up to us with requests or we intentionally stop immediate response to messaging platforms by checking at regular times/intervals. I keep repeating to myself and team, we have to change ourselves before we can ask others to change with us.
I hear this response often when I bring up this book in my Kanban workshops and talks every time: “That’s great what you did and they describe, but we can’t do that because we’re special and different and that would never work around here”. I hear: “I’m not willing to put in the work to try to change something because the momentum required to shift this thing it too huge”. It is tough to fathom because I clearly explain at the beginning of each talk just how difficult and complex the challenge was at my organization and why it has been a four year and continually changing journey. How did I convince people that a Kanban board was a good method of organization? I had my own on my own little whiteboard. How did I convince people we needed a centralized source of documentation? I had a local installation of MediaWiki for my own documentation. I did these things for myself to improve, it caught on to my team, and the clear benefits were shared and spread like wildfire into the organization.
There are so many thought provoking questions like “How do you eat an elephant?” or “How do you change the direction of an aircraft carrier?”. The answers are usually oversimplified anecdotes to solve complex problems. But an allegory like The Phoenix Project gives the proper amount of nuance and reflection opportunity needed to realize that the solutions are often as complex as they need to be in order to match the complexity of the organization itself. A simple sounding solution often requires a lot of energy or inertia to push an effort forward, but a complex solution can put complicated gears in the right place to use a company’s own inertia to benefit itself. That is what we learned from this book. We figured out how to implement complex solutions that work for everyone by using the energy of our organization to drive the power needed to make improvements like deployment automation, code review practices, learning cultures, or testing automation.
If you have not read the book, please check it out:
The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win