One thing is certain in DevOps: There is no formula, no silver bullet, no cadre of consultants who can make it take off in a business.

Instead, enterprise implementation is left to a grassroots movement, ideally paired with top-down support from leadership. 

The 2013 novel, "The Phoenix Project," tackled the complexities of DevOps in a fictional environment, highlighting what leadership has to contend with when overhauling an organization and making room for technology potential.

Co-author Gene Kim is back with a solo sequel, "The Unicorn Project," out Tuesday. The novel follows a developer, Maxine, as she and a group of rebels work cross department lines to save the lagging auto parts supplier Parts Unlimited, which is facing investor pressure and is continuously out-maneuvered by more tech-savvy competitors in the changing retail landscape. 

Kim is an author, researcher and founder of IT Revolution, which produces the DevOps Enterprise Summit and conducts research projects and publishes for the DevOps community. Kim was also the founder of software company Tripwire and served as CTO for 13 years. 

CIO Dive spoke with Kim about why he wrote a sequel for "The Phoenix Project," the need to remain technical and the role feature freezes play in big tech.

This interview has been lightly edited for clarity and brevity.

CIO DIVE: What was your biggest motivation for writing "The Unicorn Project"? 

GENE KIM: A couple of things. One is, I learned so much since writing "The Phoenix Project" and a lot of it was through studying these transformations of technology leaders at the DevOps Enterprise Summit. These tales of rebellion, courageous leaders out to overthrow an ancient powerful, unjust order — people who want to do things the way that we've done it for 30 to 40 years.

The book is really inspired by and dedicated to that community. But there's also these other kind of things I want to explore. One was, there's all these invisible structures that are required to make developers productive. ... Maxine wants to do the right thing but she can't do anything despite her amazing kung fu and skills and persuasive abilities.

Everything she wants to do is blocked by process and approvals and committees, security and compliance and change management, etc. ...

Another thing is that just like the DevOps movement, they identified this huge problem [of] how do we get code from where it is to where it needs to go, which is in production. ... Data is trapped in data warehouses and systems of record were so expensive to do queries, you can't ever get it out. And it's difficult to get to where it needs to go, which is the hands of developers and the daily work. ... In the age of data now, that's super important.

The other thing that I really [wanted] to hit on was, I think there's ambiguity about what leaders need to do to support the transformation. Even willing allies, what is really helpful and what does the opposition really look like? And I love it that the villain Sarah comes back with powerful allies and even Chris, the VP of R&D, turns out to be a very weak character that was always having to be towed along. 

Are there businesses able to do feature freezes to catch up on tech debt? Is that possible in the wild? 

KIM: I would say every tech giant has. Amazon, eBay has been for years until after the late 90s, shoring up the site just to keep the site up. 

The VP of product management didn't ship a product for two years at Microsoft. They went through a year long, what they called, security span down after the summer of worms, where he put up this famous trustworthy computing memo to all employees in the world saying, if a developer has to choose between a feature or fixing a security issue, fix the security issue, because he knows Office, Windows, .Net.

Google, same thing in 2005. Amazon, 2004. There was that famous Jeff Bezos memo about everything will be done through API's. I mean, that was essentially a feature freeze.

LinkedIn after they went public, they've actually said, despite all the promises made to the public markets we're not going to become so dangerous to deploy code that we cannot do it any longer — 90 day feature freeze, they call it Project Conversion.

I would guess in like a decade or two, this will just be well known. This just has to be a part of the way we do work. A real quick, kind of interesting thing to me is that all of those were led by CEOs that came from software background. I think they just kind of internally knew that you just can't keep the pedal the metal the whole time.

I think it's just hopefully kind of that's the direction that all industries will move towards.

In this environment with technical debt in everything, what are the big obstacles you see technical staff having to deal with?

KIM: I think at the minimum, it's indifference. I love that quote, like people and people say, "I'm not technical." I was like, well, that might have been okay to say 20 years ago. But what element of strategy doesn't involve technology at some point? How can you be responsible for carrying a strategy if you can't have an interest in it?

That jut seems very peculiar to me. Then I think, kind of at its worst, is this sort of really corrosive culture where ... I think it was driven by the outsourcing movement many years ago, [businesses] just want to hold one throat to choke, we hold someone accountable, someone will take our mess for less.

I think that's actually driven a lot of the behaviors that we see where, in fact, even technologists, we call it technology and the business instead of our business. They're not our customers or our colleagues. We're actually on the same team. It's not a utility, it's not a customer-vendor relationship. This is really about a collegial relationship with shared goals.

Do you still get time to code and tinker with technology?

KIM: I do. In fact, something happened about three years ago.

I got my graduate degree in compiler design and high speed networking. But despite being formally trained as a computer science person for most of my career, I've identified it primarily as an ops person. It was exciting. That's where the saves are made. That's where we save the world from terrible developers.

I started learning this programming language called Clojure and it brought the joy of programming back into my daily life.

These days, on a good month, I spend half the time writing ... half the time hanging out with the best in the game and then 20% coding. I just love that I can solve my own problems. I looked for a vendor and they all go out of business because my problems aren't really real problems. So I can fix it myself, which has been amazing. I really genuinely enjoy it. 

[What] I really tried to get with Maxine is how much she loves solving problems. It's something I've really learned to reconnect with over the last three years.