Some Thoughts on Reading "The Phoenix Project"

Like a whole bunch of people, I expect, I've just finished reading The Phoenix Project, and I thought it was pretty good. Readable and engaging, and full of good ideas.

If you haven't read it, the basic premise is that a middle-grade IT ops manager is unwillingly and abruptly catapulted into the role of acting VP of IT Operations in a big, traditional, but failing, parts manufacturing firm. The firm's on the brink of collapse, losing market share and full of problems that everyone can see but no-one knows how to solve. With the help of a rather mysterious mentor figure - who may or may not be on the board - our hero studies the manufacturing side of the company, heals the rifts between dev and ops, integrates IT throughout the whole company and learns to love Devops.

Something I didn't expect from reading it was that I was struck by how much of the 'reform' presented in it sounded like basic common sense and normal practice to me. I mean, what's so radical about continuous deployment?! I guess that just shows I've "grown up" professionally in the world of Devops, infrastructure as code, automation and all that. And when I last worked in a large or traditional company, IT was the guy who came in and fixed the printer.

So I wonder how many readers of The Phoenix Project found it radical and new, and how much is it just preaching to the choir? I guess that depends on how well it's being marketed outside the Devops space. And I guess how fast new people are starting to explore the Devops idea space.

I was at DevopsDays London earlier this month, as my company was one of the sponsors, and the book got a lot of mentions and a sponsored free Kindle download. In the pub on Monday night I got talking to Nick Stacey about the book, Devopsdays and Devops - among other things - and his perspective was interesting, and relevant to my thoughts on Phoenix.

So, Nick is new to Devops, Devopsdays was his first exploration of the concept, yet much of what he's seen and heard seem familiar to him. Some companies, he told me, in his experience have always been this way. Digital agencies and startups - which form his background - have to be that way to survive. "Anyone trying to empire build has to be stopped, because they'd impact profit. Agencies are constantly battling to make money, working on project basis and have to constantly drive the projects through".

This brought me to another observation I had which was how much of the book was specific to a very big, long-established firm. That's very interesting of course, but now I'd really like to read a similar book, only about a small but expanding startup. Any recommendations for further reading along these lines?

Published on in Devops