As Elevate co-founders are working on writing a couple of our own books, we’re interviewing authors of books we LOVE. Eric and I interviewed Gene for this first installment of Elevate’s Author Interview series.
Why We Interviewed Gene
My top 5 reading list for transformation leaders includes The Phoenix Project, co-authored by Gene Kim. It’s an engaging, accessible story–with dialogue that sounds like every IT shop I’ve ever been in, ever–that helps leaders think clearly about value flow, feedback and continuous learning. It also depicts the real emotions and pains that we’re putting leaders and boots-on-the-ground employees through, along with great, practical advice for alleviating that pain. I’ve often given this book to leaders I’m working with, and have even given this book as a present to friends and family.
I love Gene as a person, how he brings a kindness and humanness to tough issues and cutting insights, how he strives to increase inclusivity in the DevOps community–not just in tech itself, but also in the broader realm of people who contribute research and present their findings. I especially love how he stays curious about what really works–and when and how and why.
Beyond The Phoenix Project, Gene Kim continues to author and co-author books that are required reading for transformation leaders (such as the upcoming book with Dr. Steven J. Spear on management models and the Shingo-award-winning Accelerate) and for the people in the transformation trenches. Really, his books are outstanding for anyone who wants to have more empathy for what humans suffer in IT work and transformation (see especially the recent Wall Street Journal bestseller The Unicorn Project).
His publishing company, IT Revolution, helps writers who provide similar insights (check out the phenomenal Sooner Safer Happier), and hosts the DevOps Enterprise Summit, a conference on creating practical lean/agile/devops/digital practices at enterprise scale.
He was kind enough to allow us to interview him about his book-writing journey. Here are excerpts from our conversation.
Christine: Gene, please share a bit about your background, especially as it pertains to writing.
Gene: I’ve been studying high-performing technology organizations for 23 years. The journey started back when I was a CTO and founder of a company called Tripwire in the information security space. I was there for 13 years. It was the study of high performers that brought me into the DevOps movement, which is actually how I met both of you nearly a decade ago! If I were to self-identify what I love doing and how I label what I do, I would say I’m a researcher and DevOps enthusiast. More than anything, I love research and the writing process — especially the long-form writing style. That is, books, as opposed to blog articles, because you have the space to explain concepts that defy easy explanation. I’m so delighted that you also may be working on a book, and this leading to our reconnection.
Christine: You’ve written six books; what’s your favorite book that you’ve written and why?
Gene: I must say that I love The Unicorn Project the most, just because it was inspired by a community that so inspired me: The DevOps Enterprise community.
Studying the DevOps Enterprise community has been my primary area of passion since 2014. We’ve been studying devops adoption, not by the tech giants, not the unicorns (e.g., Facebook, Amazon, Netflix, Google, Microsoft). Instead, we study how DevOps principles and patterns are being adopted by the horses: large complex organizations that have been around for decades or even centuries. For example, Barclays presented, which was founded in 1635, which predates the invention of paper cash. Even older is UK HMRC, the British version of the IRS, which was founded in the year 1200.
These are such amazing and storied organizations, representing some of the largest brands across every industry vertical. It’s my genuine belief that as much value that the tech giants have created (between them, easily over $10 trillion market capitalization), I think that value will be dwarfed by how much economic value will be created when every large complex organization, every well-known brand across every industry vertical adopts the same principles and patterns that unleash productivity and human creativity as if they were at a Facebook, Amazon, Apple, Google, Microsoft.
That’s really the community we’re trying to create around the DevOps Enterprise Summit.
It’s just dazzling to see these rebellions get created, led by courageous fearless leaders who are savvy enough to find collaborators and overthrow ancient powerful orders, and who are quite happy to do things differently from the way work has been done for the last 30-40 years. How can you not be inspired by that?
The last thing about The Unicorn Project: I love the mental model for the book that I had in my head to write. Combining the elements of the “A team,” “Hogan’s Heroes,” and also the movies Castaway and Brazil. Brazil, where the hero is the rogue air conditioner repairman who breaks into people’s apartments and fixes their air conditioning because Central Services wouldn’t do it for them. He’s the number one fugitive of the state. It was such a fun process of trying to write that and trying to evoke the same emotions that The Phoenix Project did.
Christine: It was great, thank you! I think one of the things that I loved about The Unicorn Project–that you and I chatted about early on–was the inclusion of a female protagonist, Maxine. I mean, I love that you bring inclusivity to every part of your work, especially in supporting researchers and encouraging speakers at the DevOps Enterprise Summit.
Gene: For the DevOps Enterprise programming, we just wanted the speaker population to look like the enterprise IT population. So it was actually a very modest goal. But to achieve that goal requires us being very deliberate about representation at all stages of the programming and speaker selection process.
Christine: Can you tease apart your reasons for writing your books into personal, professional, and maybe even social motivators for you?
Gene: Yeah, for sure. So, with The Phoenix Project, I co-wrote that with George Stafford and Kevin Bear. The earliest writings went back to 2004, 2005. We had written a book together called the Visible Ops Handbook — my favorite part of that book was that every chapter began with issues and indicators. Little stories about how we spend too much time firefighting, and about how when things go wrong, it was so difficult to find out what changes could have caused it. About how all work seems to be urgent and unplanned, instead of the planned strategic activities. And how we feel doomed to repeat the past technical debt building up…and so that was really the funnest part of the book to write. Even though it was only maybe 5% of the book, I think that really painted the path for what we really wanted to do–which was to write The Goal but for IT.
The Goal is a famous book in the manufacturing community. It was published in 1986 by Dr Eliyahu Goldratt about a manufacturing plant that needed to fix cost and due date issues in 90 days; otherwise, they shut the plant down. It’s credited for really bringing lean manufacturing and the theory of constraints into “mainstream” thinking within operations departments and MBA programs. So The Phoenix Project was really an homage to that. George Spafford and I took two graduate courses at Washington State University in constraints management just while we were writing that book.
A lot of the source material came from something I started in the Notes app on my Palm Pilot back in 2000, which later migrated to my BlackBerry, and then my iPhone. I called it my Quotes file. Every time I was in a meeting and heard something preposterous or funny it went in the quotes file. I kept that for like 15 years–and I bet about 80% of those statements made it into The Phoenix Project.
The next step was to create the characters, also closely modeled after The Goal. The formula was the protagonist is Bill Palmer, the VP of Operations, who did very little of the thinking. All the cynical lines went to Wes; his job was to come up with all the objections about why you couldn’t do something that was actually a good idea. And Patty was the idealist, who loved process and order — she actually came up with most of the good ideas.
And of course, Brent the engineer is the bottleneck for the entire organization, which I think resonated with so many in the DevOps community.
The motivation of the book was very clear: to show the moral injustice of what was happening in most technology organizations. That if you set these organizational structures in a certain way, to have silos where people can’t do integrated problem solving together, you’re preordained to get horrible outcomes. With silos and phase gates, it’s a minor miracle we can actually get anything out the other side. So much of the writing was really designed to evoke emotion of just utter hopelessness and futility of doing work this way.
Christine: Hearing this, I’m again feeling so badly for people who are still stuck there.
Eric: I love what you shared about the quotes file. One of the most memorable things for me was how realistic the language was that the characters used.
Gene: Yes, without a doubt. And it is kind of–as Christine would say–heartbreaking. You want to think “oh, we’re past that!”, but I was in a leadership offsite this morning and it’s like … no. They are still very much suffering from these situations that are so ridiculous … and so familiar.
Oh, can I mention one sort of funny thing? Charlie Betz, an enterprise architect at Wells Fargo at the time, was one of the early reviewers, he was one of my friends that I would send early drafts to. He said “This book is compelling, but not in the least bit enjoyable. I already have a day job like this. Why would I want to read this?”
It was a hilarious comment, but also quite terrifying — what if no one actually wanted to read this book? It’s like if you write music and people tell you that they feel terrible listening to it.
But what that taught me was the value of modulation — the goal wasn’t to inventory every moral wrong I had observed in technology. Instead, it was to tell a story. And that’s when more humorous elements were written in. That’s when the laptop came in as a sort of a comic device. I deleted about 30% of all the bad things that happened to Bill.
Christine: You mentioned your co-authors; how did you decide to co-author? Did you geek out with your friends like “we should all write a book together” or was it more like you picked a topic you were passionate about, and then based on that topic, chose people with related expertise, passion?
Gene: I’ve never started a band, but I think the writing process, especially with co-authors, is like starting a band. These are the people that you want to co-create things with, to learn together, to perform together.
I’m sure the genesis of Elevate was formed around similar goals, right? You want to hang around the best in the game.
Christine: What are the tips and tricks you’ve used to keep yourself going, to make sure that you keep writing?
Gene: I was listening to the Tim Ferriss’ interview of Jerry Seinfeld, and one of the things I just loved that Seinfeld said was, “Standup comedy is a game of tonnage.” He says his real skill is writing and performing. He says that the two places where he works is at his desk, where it’s all about writing, and then on the stage, where it’s all about getting feedback from the audience, which tells him if what he wrote is any good.
He has a shockingly clear, even clinical, view of everything being part of a scientific method.
For me, the way that manifests into my daily work is in a spreadsheet that I’ve been keeping in some shape or form for over 14 years. It’s just a work log. Every day, there’s one row that gives the date, what I need to write, and what the word count is at the beginning of the day, and at the end of the day.
Because of the pandemic, this is the first time I’ve been writing a book where where I’m not at a very specific Starbucks near my kids school, or by Portland State University. I’m glad that I eventually found that I could write without being in a coffee shop!
My usual goal is 800 words per day. Sometimes this requires playing games with myself, such as saying, “I won’t get lunch until after I’ve written 800 words.”
I think without rituals like this, there’s just no way you’re going to finish a book.
Christine: How did you choose the style of your books?
Gene: For me it’s really fun to sort of take the narrative fiction style, sometimes known as the business fable. And I usually follow that up with a nonfiction, prescriptive companion guide. I’ve found that you can get away with a lot of imprecision in the business fable style — you need a lot more rigor for nonfiction books, which are fun to write, in a different way.
Christine: Which did you write first?
Gene: The Phoenix Project was written first, which came out in 2013. But we were also trying to write The DevOps Handbook at the same time. Maybe not the best idea. You know, the multitasking problem! You probably could have predicted what would happen: The DevOps Handbook was four years late.
Christine: You sort of answered the next question that I had for you, which was, how did you choose the format of your books… But maybe there’s a little more to it?
Gene: I think the best thing that any author can do is write a one-pager. The first thing you write is the back cover of the book, where you basically describe the problem, why it’s important, and describe what you will teach them to ameliorate and solve the problem.
Then describe the book — my favorite way to do this is describing the book using only other books…to triangulate what you’re trying to write. In Hollywood, they often pitch movies by describing it with other movies. For example, Aliens was pitched as Jaws, but in space.
The Phoenix Project was The Goal but for IT.
The DevOps Handbook was a combination of Getting the Right Things Done and Reengineering the Corporation.
It’s such an efficient way of describing your desired narrative style, the positioning of the book, the reader, and even things like word count.
And I think that to be a good author you have to study other books. Which books do you like? Which sensibilities are going to inform your book?
For The Unicorn Project, my editor and I referred to that one-pager numerous times, especially at the end of the development process when we had tough choices to make — such as, do we cut this scene where we describe how Maxine cleaned up the code? Do we need to define what an “IDE” is? Well, it really depends on who the the target audience? The technology leader or the developer?
It was agonizing to pick one, but we finally decided that the audience was the developer. And if it was a good book, developers would give it to their managers.
I think it was the right decision, and we modified the one-pager. It helps define precisely what you want to build, and it informs the book manuscript. I’ve often been updating the one-pager throughout the book development process.
Can I tell you another quick story about how important that one-pager is?
One of the toughest decisions for The Phoenix Project was also being very specific of who the audience would be. In 2009, I was so dazzled when I gave a talk to the Society of Information Managers about the concept behind The Phoenix Project, back when we were in the early stages of writing it. The CIO at the time of Columbia Sportswear said “When you finish that book, everyone on my team will need to read it, my boss will need to read it, and the CEO will need to read it.”.
Wow, that was such an inspiration to me.
But just like in The Unicorn Project, during the editing process, when it came down to what we would need to cut in The Phoenix Project, we asked ourselves: Who is this book for, is it for the technology leader? If so, we need to cut the board meetings, which I loved so much.
But if the book is for the business leader, then we would keep the board meetings. But then we shouldn’t be talking about the details of database changes or deployments.
I can’t overstate the amount of anguish I felt when we decided that the primary audience was the technology leader, because I think we had something important to say to business leaders, too.
But I finally realized that it wasn’t our job to communicate to the business leaders — that was the job of the technology leader. The book had to be good enough for them to give it to their business counterpart.
Eventually, we targeted the VP of IT Operations — and I think that is what made the book resonate so well. Just like in product design, the more specific you are about who you are designing for, usually, the better the outcomes.
The Unicorn Project is for a developer. You don’t need to define what an IDE is — maybe you do once, just in case the reader isn’t from a technology background. So I was prepared to hear criticism that the book is too technical, because it talks about things like Clojure and functional programming.
I don’t care — that’s the book I wanted to write, and I’m so glad that it resonated with that audience.
So my advice: be very clear about who you are writing for. It’s tough to really pick one, and, again, I believe that the more specific you are, the better. And as I’ve described, these are things you revisit and change throughout the writing process.
Eric: Has that reframe ever happened late in the book, and then you have to do a lot of re-writing? Or do you find the fork fairly early, and you just decide, and keep riding down one road?
Gene: I think the question comes up continually. For The DevOps Handbook, where does Security belong? After much wrangling, we decided that it belonged at the end, which was sort of amusing, because it could be interpreted that security really is just an afterthought. Funny, right?
But it didn’t belong at the front of the book. Over and over again we agonized about it. Ultimately we made the call that it really belongs in its own chapter at the end. I think that was the right call. Now I think there’s a great opportunity for a DevSecOps book that address it a different way, maybe with the security practitioner as the primary audience.
In the case of The Unicorn Project, literally in the last week before we had to turn over the files to the printer, there was one scene we were debating on cutting or keeping. It was about event-sourcing and the architecture of applications. It was pretty technical, and, worse, it was multiple pages long.
But after we recommitted that the book is for developers, and, better yet, awesome architects, we decided to keep it in.
As Jerry Seinfeld said, writing is a game of tonnage. You always overproduce. So in the end you’re always cutting. For The Unicorn Project, I think the total word count at one point was 130,000 words, which we cut down to 110,000 words.
If all goes well, it’s mostly cutting things, and not a huge amount of rewriting.
Christine: How did you right-size the research you did for each book? Did you ever find yourself getting lost in research, or stopping too soon?
Gene: I love books that have great citations. For The DevOps Handbook, the indexing and the end notes cost over $10,000. But for me, that was awesome, because I’m so proud of how we fact-checked everything and give the reader the primary source for so many amazing statistics and stories.
The research process for The Phoenix Project got difficult —I stopped reading non-fiction books for almost five years. I stopped being able to read non-fiction at night. At that time, I wanted to stop learning new things, because I often felt obligated to add it to the book.
I love research, but I have found that at some point you just have to turn it off and say, “No more input, it’s all about output.”
Christine: Would you share more about the editing process?
Gene: The way the typical process goes is that once you choose a publisher, they’ll assign you an editor. Then it’s about gaining agreement on that one-pager, describing the audience, the scope of the book, positioning, and narrative style.
There’s another thread of discussion about the planning process — in other words, when does the book come out? Usually, it takes about two years.
As aggressive as people want to be, they rarely take less than 2 years. I’m averaging about 3 years. Then comes manuscript generation. Just filling out the outline, until you’re at 5,000 words, 50,000 words, 80,000 words.
Then you go into developmental editing, which is where the editor studies the book. Most of them will come up with an editorial letter, which is basically just a long-form, narrative description of what worked, what didn’t work, suggestions on fixes.
This is why I think there is value in the long-form writing style — even though to some, it will seem archaic and very “big batch.” I think there are some things that you just can’t do in small batches. You need to pick it up and read it from start to finish, and see the entire whole. For me, that’s the most painful part.
I would recommend you overproduce — having too much is better than having too little. At a certain point, you work through all the major structural issues, and then it goes into copyediting, proofing and so forth. This is usually where you run into huge deadline pressures. “No no no I want to change this thing, give me three more days!”
Everything comes crashing down at the end. Like you want to add diagrams, but you can’t, because you’ve run out of pages, and you have to layout the entire book again. Fun times.
Christine: What are two things that surprised you about the book writing process?
Gene: It’s how much you learn from it. I’ll give you three.
- It’s especially how much you learn when you have co-authors. There’s just bound to be some dazzling insights. One from The DevOps Handbook came from Jez Humble. He’s the second author on the book. He’s written numerous books. I think one of the reasons people drop out of writing projects is because they don’t love writing. He is a writer. We had so many working calls. I learned so much from him. He described the biggest a-ha moment when he was writing The Lean Enterprise: “The same sort of experimentation that you do in the product development process is also required in the process improvement process.” It’s like they’re orthogonal but the principles are still the same. You can’t know what’s coming.
- I heard Dr. Adam Grant speak, he wrote the book Give and Take, and he talks about having a circle of energetic dissenters — basically your biggest critics, whose opinions you trust. Over the years — you both have been in my early review list — I’ve always loved hearing what you think, your insights and a-ha moments. How many great learnings you’ll get just from this group — that was a wonderful surprise. And there’s no doubt that you end up with a much better book when you have fantastic comments from smart people reviewing your book.
- If you look at the business book category, over half, maybe three-quarters of the authors are consultants. The reason, I think: They’re integrating their marketing work into their daily work, using it as a calling card as a minimum, but also integrating it into their consulting engagements, perhaps even encouraging bulk purchase orders. Books have a virality factor; good books get recommended to friends. You want to maximize that: how quickly and to what extent can you get books into people’s hands to increase that vitality factor.
Christine: Gene, thanks so much for making time to share all this with us. It is so lovely to just see you and connect with you, and even more fun to hear about your book-writing journey, and all the lessons learned. We’re looking forward to DevOps Enterprise (US) October 5-7…. And your upcoming book!
If you don’t already have copies of Gene’s amazing books, we highly recommend The Phoenix Project for transformation leaders and The Unicorn Project for developers.
Want to get regular updates from the Elevate team as we interview more amazing authors of books we love? Sign up here: