I recently read The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win and it was one of the most insightful books I’ve ever read. It’s about a fictitious company called Parts Unlimited that is struggling to keep up with the competition. In an attempt to make up market share and get the company back on track, Parts Unlimited launches codename, Phoenix Project. It follows the newly promoted VP of Information Technology, Bill Palmer, as he unexpectedly inherits a chaotic IT team and must find a way to fix it before his entire department is outsourced.
I speak to IT executives almost everyday and I typically only see a small subset of what they are dealing with on a day-to-day basis. This book is a humbling look into everything an IT team tackles and how they interact with other departments within their organization. The Phoenix Project touches on several themes but instead of analyzing the Three Ways or the Four Types of Work, I wanted to give an outsiders perspective on what resonated with me.
Manufacturing Operations vs Developer Operations
In The Phoenix Project, Bill was often guided by a prospective board member on how best to visualize the flow of work through his IT organization. To illustrate this, the Parts Unlimited manufacturing plant was almost always the source of truth; at the plant, you could easily see how inventory gets processed through WIP (Work in Progress) and finally shipped out to customers. Similarly, the IT department needed to identify where work gets introduced into the group, what (or who) the constraints are that prevented work from getting done and how work is delivered to the ‘end customer’.
In a previous life, I was often on the ground floor of a medical device manufacturing plant and this book brought me back to the days I had to coordinate an assembly line and optimize it. Using Kanban and other lean manufacturing techniques you could reduce the Takt Time of each part of the manufacturing process. What leaders sometimes don’t realize is that you can’t optimize a process like you would a machine or a piece of code; in manufacturing (and now realizing in IT), you are optimizing the movement of people. If you’ve ever watched The Founder with Michael Keaton, there is a scene in the movie where the McDonald brother’s were describing their “Speedy System” and how they orchestrated the movement of people as they assembled a burger and an order. What they figured out was that to deliver great customer service, they needed fast service and in order to achieve fast service, they needed to restructure their kitchen based on human behavior.
The Relationship Between IT and Security Groups
It’s easy to assume that IT and Information Security teams are connected at the hip. In small teams, they are sometimes the same person; however, in large organizations, they may not even sit in the same building. The Phoenix Project initially vilifies the Chief Information Security Officer (CISO), John Pesche, and, as a reader, I found it easy to dislike his character. John just always seemed to be the one holding up every project. In many cases, you can’t assume that the security team always shares the same thoughts or goals as the rest of IT. They often deal with rules and regulations that others in the organization don’t have visibility of; it’s presumptuous to think that security decisions are always black and white.
In the end, you realize that John’s job isn’t as simple as it sounds; he must constantly balance the need to support the company’s revenue goals, identify IT risks they are willing to take and assure that compliance and security is integrated into every process. The InfoSec team are sometimes at odds with even the overall IT team.
The Goal
The novel was written in the same style as The Goal by Eliyahu Goldratt, and it doesn’t hide from that fact as it was referenced several times in The Phoenix Project. While The Goal focused on a manufacturing setting, The Phoenix Project uses the manufacturing ideologies and overlaid the foundation of those values onto an IT organization. But the theme remains the same. No matter what department you’re in or what industry, everyone should be working towards a common goal. In almost all corporate cases, the goal is to increase profits.
In reality, it can sometimes feel like each team is silo’ed and the goals of one team can undermine those of another. With egos, office politics and individual career aspirations, the goal is sometimes lost in an overwhelming list of projects. In any organization, there is always tension between different departments; IT and Engineering, Engineering and Marketing, Marketing and Sales, Sales and Engineering. In a good organization, this tension can be a healthy one; each supporting their counterpart, cooperating on project hand-offs and keeping accountability across teams. In a bad organization, this tension can be toxic; lots of pointing fingers, rogue individuals, and project expectations spiraling out of control. Leaders and team members need to be constantly reminded of the goal and how their part affects the goal.
How This Changes My Conversations With IT Leaders
This book doesn’t necessarily change my perception of the IT department, but it clarifies much of the team dynamics that were previously unclear to me. The Phoenix Project does a great job portraying the different types of personalities you have to deal with on any team. Brent is the team member that has all of the knowledge but no one to distribute it to, Patty is the detail-oriented manager who creates processes that no one can follow, Wes is the loose cannon who holds no punches and tells it like it is. Whether you have to navigate these personalities within internal office politics or you’re a vendor looking to deliver great customer service, you have to make sure you align goals with how each person works; it should be obvious, by now, that each person works differently.
Lastly, you have to understand that despite a project being high priority, there are inevitable fires that occur within the IT organization that jumps to the top of the list and requires people to literally drop what they’re doing. As the novel comes to a close, you begin to realize that, today, IT isn’t a standalone department; it’s integrated into every department and team in a company. Every person in an organization is affected by IT in some way, whether you’re a new hire getting a company-issued phone or a CEO communicating with board members, IT is often in the background keeping things running.
Alvin is a network security evangelist and entrepreneur. His ramblings can be found at www.alvintai.com. Follow him @thealvintai
