The book bills itself as being for the CEO that’s looking to make sense of how the changes in IT should change the way they view the CIO and IT. It mostly lives up to that, though you’ll need to have some knowledge of agile/cloud. As a technologist, I also found it valuable to hear the language and examples the author uses because I think they’ll be valuable as I talk to development managers and infrastructure executives who are trying to figure out how to sell the agile/devops/product/team approach to a business that is used to thinking about “keep the lights on”/multi-year initiatives/chargeback. Overall, I’d recommend the book as a quick read. Mostly to remind you of things you already know/feel and to give you words that’ll help you say them.
A few things I liked in particular:
- One of the primary points that he makes is that the world is changing so quickly right now that the biggest risk facing most companies is that they won’t be able to change fast enough. With that in mind he argues that DevOps and Cloud are actually investments in Risk Management. I find this powerful for two reasons:
- In many companies it’s the people carrying the title “Risk Manager” who want to stop things like deployments during business hours and hosting data outside the data center. This points out that (often, not always) those risk managers are protecting the company from the wrong/lesser risk of small outages at the expense of the big risk (not being able to innovate as fast as your competitors).
- It helps justify the cost of some of the DevOps Transformations and Cloud Transformations that need to happen. Often these are hard to justify when they’re compared with the opportunity to deliver on business requirements or the opportunity to use automation to save money in infrastructure. Framing DevOps as a risk management play, helps explain why there’s a need to invest in making the company better able to change.
- He actively fights the urge to make “IT as a Business”. Arguing that it needs to be part of the company like finance or marketing. He, rightly, points out that in most companies IT is expected to operate like a sort of sub-contractor but not given the ability to hire freely and set salaries optimally, IT can’t choose to avoid business customers that become untenable, it can’t charge more for higher demand items instead of passing on costs (at least in most chargeback models I’ve seen). Additionally, making IT a sub-contractor means adding red tape to the change process. IT is inscentivized to offer standard products, to require the business “pay” for changing requirements, etc…
- He uses one of my favorite business people analogies about agile software development vs project based development. That it is like buying options. Business people understand the risk of buying assets vs buying options… most even remember that moment of surprise in business school when you realized just how different the price is between an option and an asset. Agile software development is like that. You can build an MVP for the smallest slice of the market you can think of and then wait and see if they like it before agreeing to pay for the rest of the project.