I just finished reading The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford. And wow, what a great book! It really captures the organizational trends and individual behaviors that screw up software & IT projects. And, better yet, it offers some concrete examples for how to address these issues. The Phoenix Project is a bit like a time machine for me, because it so accurately captures the entire ecosystem of dysfunction at one of my former companies that it could have been based on that organization. I have worked with these people and witnessed those behaviors – but my Brent was a guy named Yudong who was very bright and well-intentioned, but without a clue how to operate. Those weekly emergency hair-on-fire sessions were typically caused by him. Low-quality software and badly managed deployments make productivity go backwards. Worse, repeat failures and lack of reliability create tension and distrust between all the groups in a company, to the point when they become rival factions. Not a pleasant work environment – everyone thinks everyone else is bad at their jobs! The Phoenix Project does a wonderful job of capturing these situations, and why companies fall into these behavioral patterns.

Had this book been written 10 years ago it would have saved a different firm I worked for. A certain CEO who did things like mandate a waterfall development process shorter than the development cycle, commit to features without specifications and forget to tell development, and only allow user features – not scalability, reliability, management, or testing infrastructure improvements – into development might not have failed so spectacularly. Look at blog posts from Facebook and Twitter and Netflix and Google – companies who have succeeded at building products during explosive growth. They don’t talk about fancy UI or customer-centric features – they talk about how to advance their infrastructure while making their jobs easier over the long term. Steady improvement. In some of my previous firms more money went into prototype apps to show off a technology than the technology and supporting infrastructure.

Anyway, as an ex-VP of Engineering & CTO, I like this book a lot and think it would be very helpful for anyone who needs to manage technology or technical people. We all make mistakes, and it is valuable for executive management to have the essential threads of dysfunction exposed this way. When you are in the middle of the soup it is hard to explain why certain actions are disastrous, especially when they come from, say, the CEO. And no, I am not getting paid for this and no, I did not get a free copy of the book. This enthusiastic endorsement is because I think it will help managers avoid some misery. Well, that, and I am enjoying the mental image of the looks on some people’s face when they each receive a highlighted copy anonymously in the mail. Regardless, highly recommended, especially if you manage technology efforts. It might save your bacon!

We have not done the Summary in a couple weeks, so there is a lot of news!


On to the Summary:

Webcasts, Podcasts, Outside Writing, and Conferences

Favorite Securosis Posts

Other Securosis Posts

Favorite Outside Posts

Research Reports and Presentations

Top News and Posts

Blog Comment of the Week

This week’s best comment goes to Marco Tietz, in response to Responsibly (Heart)Bleeding.

Agreed. a bit of bumpy road pre-disclosure (why only a few groups etc pp, you guys covered that in the firestarter), but responsible handling from akamai along the way. maybe I’m too optimistic but it seems to be happening more often than it used to.

Share: