The Phoenix Project: 10 Years of Transformation

The Phoenix Project, the seminal DevOps novel written by Gene Kim, Kevin Behr, and George Spafford, was released on this day in 2013. Now, 10 years on, we wanted to take a minute to look back and take a peak at the influence of this title.

Since its original release, The Phoenix Project has sold over 700,000 copies and been translated into 12 languages! It is constantly given by consultants as gifts to clients, by managers as training material to employees, and by co-workers as an example of a new way of working. It has become so ubiquitous with a certain way of thinking, that when you spot it on someone’s bookshelf, you know you’re with kin.

In 2018, IT Revolution released a special edition of the book with a new afterword from coauthor Gene Kim. Let’s take a look back at that note from Gene here.

The Past—An Homage to The Goal

When Kevin Behr, George Spafford, and I first started writing The Phoenix Project we never suspected how quickly DevOps would be embraced by technology professionals within all types of organizations. When this book was first published in January 2013, DevOps was very much in its early years, less than four years after the famous “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr” was presented by John Allspaw and Paul Hammond, and a little over two years after the first DevOpsDays conference in the United States.

However, virtually everyone in technology was already all too familiar with the problems commonly associated with Waterfall software delivery processes and large, complex, “big bang” production deployments. This dissatisfaction with the status quo was driving increased adoption of not just DevOps, but also Agile and Lean.

We knew from first-hand experience that these problems were being faced by almost every modern enterprise and across every industry vertical regardless of the size of the organization or whether it was for profit or non-profit!

This nearly universal problem led to chronic underperformance throughout the entire technology value stream, which included Development, Operations, and Information Security. But worst of all, it led to chronic underperformance of the organization these technologists all served.

With The Phoenix Project, we wanted to capture what the downward spiral looked and felt like, as well as what the surprising solutions felt like. So much about DevOps is counterintuitive, contrary to common practice, and even controversial. If production deployments are problematic, how on earth can deploying more frequently be a good idea? How can reducing the number of controls actually increase the security of our applications and environments? And can technology really learn anything from manufacturing? There are countless more examples of these difficult to believe claims. 

Because we wanted to show both the problems and solutions in a recognizable and relatable form, we decided very early on that the only way we could describe with adequate fidelity the enormous complexity of this problem was in the form of novel, just like Dr. Eliyahu Goldratt did in The Goal, the seminal book he published in 1984.

The Goal helped many of us have a giant and meaningful “aha” moment. It has been credited for helping make Lean manufacturing principles become mainstream, and, since its publication, The Goal has been integrated into almost every mainstream MBA curriculum and operations management course, influencing our next generation of leaders.

When I first read The Goal around 2000, it was life-changing. Even though I had never worked in manufacturing, certainly never as a plant manager, there was no doubt that this book contained lessons that were relevant to the work that we do every day in technology. For over a decade, my co-authors and I wanted to write a version of The Goal for the technology value stream—this book obviously became The Phoenix Project, the book you’re holding right now.

Dr. Goldratt passed away in 2011 but left behind an incredible legacy. I’m particularly grateful for how he made time in 2004 to talk with Kevin Behr and me. It was amazing to see how he helped continually expand the Theory of Constraints body of knowledge.

I would recommend to anyone who has an interest in Dr. Goldratt’s work to listen to his audiobook Beyond the Goal, which was released twenty-one years after The Goal. It brilliantly captures in one place his own lifetime of learnings, and synthesizes those learnings into a comprehensible and comprehensive whole.  

In Beyond the Goal, Dr. Goldratt shares a story that was incredibly prescient for us. After The Goal was first published, Dr. Goldratt quickly started to receive letters in the mail about how people claimed that he must have been hiding in their manufacturing plants because he described all the problems they were facing in their daily work, as well as how the Theory of Constraints enabled them to solve their problem. 

I can’t think of a better or more persuasive testament to how well Dr. Goldratt understood the universality of the root cause of the problem, as well as the rules that described a generic direction for the solution. 

Without a doubt, we wrote The Phoenix Project as an homage to The Goal, hoping to show that the same principles that Dr. Goldratt espoused originally for manufacturing could be used to improve technology work as well.

As another nod to both the work of Dr. Goldratt and the way he released it, in 2018 we released Beyond the Phoenix Project, an audio series collaboration between John Willis (co-author of The DevOps Handbook) and me. The project covers both the figures and philosophies that serve as the foundation for the DevOps movement, including a whole module on Dr. Goldratt.

I’m so pleased that The Phoenix Project is following in the footsteps of The Goal. The Phoenix Project has sold 700,000 copies to date, and like The Goal, it is being integrated into MIS programs, MBA curriculums, and even computer science programs. 

Sometimes, the similarities to The Goal are downright uncanny. Shortly after the publication of The Phoenix Project, we started receiving emails. Many espoused sentiments like the following,  “Holy cow, you are writing about our organization—It’s like you’ve been hiding in our building. I know these characters. In fact, the application disaster in the book just happened to us.” (And incredibly, in one case, the application being deployed was even called Project Phoenix!)

It has been particularly gratifying to see how this book has been used across technology organizations, often in a book club format to discuss how the current system can pit Development, Operations, and Information Security against each other, making it virtually impossible to achieve the most important organizational objectives, and more importantly, how this led to completely new types of interactions to explore a better way of working, with much improved outcomes.

I’m always amazed at stories where people have used The Phoenix Project to find each other: often a change agent will recommend or give out copies of The Phoenix Project to scores of people, paying careful attention to who comes back saying, “Wow, what’s happening to Parts Unlimited is happening to us, isn’t it?” Sometimes seeing a copy of the book prominently on someone’s desk or bookshelf serves as a signal that this person is a fellow traveler, one who sees a common problem that spans functional domains and is potentially a fellow conspirator, a fellow risk-taker, who is willing to work together to create a coalition to overcome powerful, entrenched incumbent systems.

The Phoenix Project is ultimately a book about transformation, and so it is incredibly gratifying to see it being used as an instrument to create transformations in real life as well.

Surprises on the Journey

There are so many surprises and learnings on this journey, and I wanted to share a couple that seemed fitting for this afterword.

One of the most delightful and startling blog posts I’ve read about The Phoenix Project was by Dave Lutz, famous for many things, including the server-room inspired cover song of “Imagine” by The Beatles that he performed at DevOpsDays Mountain View 2011. In this post, he ponders the role of Brent, an all too familiar character in Operations. He writes, “I find myself wondering what the outcome of the project would have been if Bill’s first action was to fire Brent. Would the project have been finished earlier? (I don’t have a moral problem firing a fictitious character in a thought experiment. I wouldn’t do this in real life of course!)”

Mr. Lutz writes about how there are two types of Brents: hoarders and sharers.  He writes: 

I’ve also come across otherwise smart [people] who are of the mistaken belief that if they hold on to a task, something only they know how to do, it’ll ensure job security. These people are knowledge Hoarders. 

This doesn’t work. Everyone is replaceable. No matter how talented they are. Sure it may take longer at first to find out how to do that special task, but it will happen without them.

For me, what Lutz wrote was fascinating for so many reason, like how The Phoenix Project has become shorthand to describe certain categories of problems and a safe way to discuss and conduct thought experiments, not just on the effects of processes, but on people. 

And by the way, Mr. Lutz, I can state for the record that during the writing of this book we always knew that Brent was a sharer, not a hoarder; in fact, Brent is the only character whose name we didn’t change. And without doubt, as you speculated, our real-life Brent always had the best interests of the organization at heart and was merely a victim of the system.

Another genuine surprise for me is how some people have written that we (the authors) must hate Information Security, and more specifically, that we hate Information Security people. One of the best examples actually came from a friend of mine, Paul Love, who was a co-author with me on Visible Ops Security.

In a blog post, I published an email that he wrote me: “When I first read The Phoenix Project: A Novel About IT DevOps, and Helping Your Business Win, John [the CISO character] made me angry. As a 20 year [sic] security veteran, John’s totally selfish ‘my way or the highway’ attitude actually made me physically mad. Who did this guy think he was anyway? Why was Gene painting the infosec practitioner in such an unflattering light?”

He continued: 

“After finishing the book, I took a moment to look back on my career. Thinking of all of the people like John who I’d run into and worked with over the year I realized, with a little bit of terror, why I hated him so much. Before I studied Visible Ops and DevOps, I was John.”

I’ve sometimes received the same sort of reaction from people who don’t know that I spent the majority of my career in the Information Security field as co-inventor of Tripwire, spending thirteen years as the founder and CTO of a company focusing on automating security and compliance.

As the saying goes, “We tease who we love.” In many ways, John the CISO is my favorite character, and in many ways, his journey most closely mirrors my own. As my friend Jez Humble, co-author of The DevOps Handbook, observed, “[John] is a phoenix, too.” Well put, Jez!

Whether we are a John, a Brent, a Wes, a Patty, or a Bill, when we’re trapped in a system that prevents us from succeeding, our job becomes thankless, reinforces a feeling of powerlessness, and we feel like we are trapped in a system that preordains failure. And worse, the nature of technical debt that is not paid down ensures that the system gets worse over time, regardless of how hard we try.

We now know that DevOps principles and patterns are what allow us to turn this downward spiral into a virtuous spiral, through a combination of cultural norms, architecture, and technical practices. 

As The Phoenix Project found it’s way into the world, another group of us were working on The DevOps Handbook (Jez Humble, John Willis, Patrick DuBois, and me). One of the amazing moments during the creation of this book was when our editor, Anna, asked us each to describe our DevOps “aha” moment. 

The amazing thing was that all of our answers were uncannily similar: We each described the incredible frustration of how difficult it was to do our work, whether it was the toil or the suffering. And we all shared the exhilaration of discovering a better way, under this broad umbrella of practices we call DevOps. 

You can read about all of our “aha: moments in the first pages of the extended excerpt of The DevOps Handbook included in the back of this 5th Anniversary Edition of The Phoenix Project.

Looking into the Future

The problems that DevOps solve are at the center of what every modern organization is facing. Now more than ever, technology is not just the nervous system of an organization—it actually composes the majority of the muscle mass. 

As Jeff Immelt, former CEO of GE, wrote, “Every industry and company that is not bringing software to the core of their business will be disrupted.” Or as Jeffrey Snover, Technical Fellow at Microsoft, paraphrasing Dr. Nicholas Negroponte, wrote, “In previous economic eras, businesses created value by moving atoms. Now they create value by moving bits.” 

When The Phoenix Project was first published in 2013, DevOps was primarily used in Internet companies, commonly known as the FAANGs (Facebook, Amazon, Apple, Netflix, and Google). Of course, also in this category are Flickr, LinkedIn, Microsoft, Yahoo, Twitter, GitHub, and countless more.

Now, five years later, it has been amazing to see these principles and practices in large, complex organizations across every industry vertical. This is incredibly exciting, because this is undoubtedly where the majority of the economic value of DevOps will be created.  

IDC, the analyst firm, says that there are about eleven million developers on the planet and seven million operations people on the planet. At the time of this writing, it would be wildly optimistic to project that one million of these engineers are already using DevOps principles and practices.  

If that’s the case, DevOps has 6.5% market share, leaving 93.5% of the market to go. The majority of these engineers are in large, complex organizations—these are the most well-known brands across every industry vertical or supporting our largest government agencies or military services.

The mission at hand is how we can elevate their productivity so that they’re as productive as the high performers. We know through more than four years of State of DevOps Reports conducted by Puppet that high perfomers are two to three orders of magnitude more productive than their peers. In my mind, helping everyone reach this level of high performace will create trillions of dollars of economic value per year and is where the next surge of productivity will come from.

In 2016, I was talking with my friend Rob England, often known as his moniker The IT Skeptic. We were fellow travelers in the ITIL space ten years ago. We talked about how he famously and visibly changed his mind about DevOps. Initially, he believed, as many do, that anything that increases deployment frequency and enables developers more freedom inevitably leads to disaster. But through many interactions, he eventually realized that DevOps can lead to far better outcomes. If you want to explore his journey more, you can read my full interview with him on CA.com, “Face-to-Face DevOps: To Protect and Serve.” 

In our conversations together, we talked about how DevOps is inevitable, inexorable, and remorseless, and how DevOps is incredibly disruptive to the technology sector, to the technology field, and for anyone in technology. 

There’s no doubt that DevOps is radically changing and transforming how we work in technology. Organizations that cannot adopt DevOps practices will be at a massive competitive disadvantage. As Dr. W. Edwards Deming is famously paraphrased, “Learning is not compulsory . . . neither is survival.” 

Without a doubt, the best times for technology are ahead of us, not behind us. There’s never been a better time to be in the technology field, and to be a lifelong learner.

On behalf of my co-authors, thanks to everyone who has made this journey so amazing and worthwhile!

—Gene Kim

Thank you for joining us for this walk through memory lane! In addition to The Phoenix Project celebrating it’s anniversary, it is also our 10th anniversary as a press, so tune in all year for more celebrations, reminiscing, and, of course, new books!

- About The Authors

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

• 
• 
•