In summary: IT leaders want to be regarded as real business leaders, to be invited to the top table, and they are told that they should act in a particular way to get that seat at the table. Mark Schwartz argues that that the traditional approach is completely the wrong way of going about it in a world that is changing rapidly.
I’ve read a number of book on the changing landscape of business and, in particular, the radically changing role of technology within businesses. You may call this change Digital Transformation (personally I think that we’ve passed the point of meaningless for that particular term). This is a book for the people who are being expected to lead through that change:
“I’ve read a number of books on IT leadership and how to be a good CIO. None of them mention the major change of the last two decades: the rise of Agile and Lean practices for IT delivery. I’ve read plenty of books on Agile and Lean practices for IT delivery. None of them explain the role of IT leadership in an Agile world. The two domains are evolving separately: the field of IT leadership continues to frame its problems in its same old ways, oblivious to the deep changes brought on by the Agile revolution, while the Agile world, ever suspicious of management, proceeds as if it can manage without the involvement of IT leaders.”
The most common thought I had while reading this book was: “Yes, that’s it! I’ve seen that.” This was particularly true throughout chapter 2 where Mark outlines the history that has resulted in the situation that many organisations find themselves in and the behaviours that continue to reinforce this situation. This is a situation in which IT is regarded as separate from the business and is handled by contractor-control methods that spawned the whole outsourcing market in which I have worked for many years:
Thus, a distinctive way of thinking about IT was born, and has determined the course of IT since. First of all, we came to speak about “IT and the business” as two separate things, as if IT were an outside contractor. It had to be so: the business was us and IT was them. The armslength contracting paradigm was amplified, in some companies, by the use of a chargeback model under which IT “charged” business units based on their consumption of IT services. Since it was essentially managing a contractor relationship, the business needed to specify its requirements perfectly and in detail so that it could hold IT to delivering on them, on schedule, completely, with high quality, and within budget. The contractor-control model led, inevitably, to the idea that IT should be delivering “customer service” to the enterprise—you’d certainly expect service with a smile if you were paying so much money to your contractors.
There are many challenges with this approach, not least the challenge that a contractor-control relationship requires a level of stability and certainty that IT is not and should not be in a position to predict. Don’t get me wrong here, there are facets of IT provision that should be contracted, that’s what the who cloud change has been about, but that’s not where the business value is and that’s where the IT leaders should be focusing. Rather than subscribing to the “IT and the business” contractor-control model, Mark Schwartz sets out a different approach based on Lean and Agile thinking. I’d be reproducing the book if I tried to summarise all of the different ways in which Mark sees this playing out and that’s not the point of a quick review.
Some key stand-out thoughts for me though:
Planned Approaches v Agile Approaches
Planned approaches may have given us a perception of control, but that control was just an illusion. There were always too many unknown factors to really have control. Using Agile approaches allows us to continuously correct the course as we discover things helping us to navigate the unknown.
Enterprise Architecture in an Agile World
There are many fascinating insights into the role of Enterprise Architecture in a world where Agile is the way to deliver.
I have said that we need to stop looking at IT delivery in terms of projects and products. With what, then, shall we replace them? I’d like to suggest that the enterprise architects have had it right all along. We manage an enterprise-wide asset with an “as-is” state and a “to-be” state. We groom this asset in perpetuity—as the company changes and develops—by adding, removing, and improving its capabilities. We try to build into it agility and options, risk mitigations, and usability. The totality of our IT capabilities is an economic asset that will be used to derive profits or accomplish mission, and we might as well just call this the Enterprise Architecture.
As architects we need to move quickly away from our roles as the occupiers of the “land of the template zombies” and step into our new role as members of the business community who manage the IT economic asset. I wonder whether the term “Enterprise Architecture” is already too closely aligned to the “template zombies” to be redeemed, but that’s just the title and it was never really about the title.
Risk
We need to think very differently about risk, risk logs have never worked. Our plans require us to accurately predict the future, and we’ve never managed to that either. The way that we control risk is to make changes as circumstances develop. Creating experiments to help us understand how to navigate the risks is going to be the new skill that we all need.
Build v Buy
Mark makes an argument that the cost of building used to be so high that at always made sense to buy. The problem with buying was that you never quite got what you needed; you either got more than you needed or you got something that was only an 80% fit for what you need. This has all changed as the cost of building has reduced because of capabilities like micro-services which allow us to build something that is a 100% fit for what we need by plugging together a number of preexisting elements from cloud capabilities.
My personal perception is that this change is already taking hold – I’m seeing a lot more building going on.
The Role of the Senior Leader
Within this framework of change Mark outlines a new role for the IT leader, a role that has changed from be an enforcer of the contractor-control model to one whose role is to create an environment where self-managing teams can thrive. Mark summarises this change in a number of new roles:
- Driver of Outcomes – taking responsibility for business outcomes.
- Manager of Uncertainty – dealing with uncertainty has always been a part of IT leadership.
- Steward of Assets – three critical ones the Enterprise Architecture asset, the IT people asset and the data asset.
- Contributor – by being technical.
- Influencer and Salesperson – stepping up to the “Chief” role.
- Orchestrator of Chaos – businesses are complex systems that require a level of orchestration to truly sing.
- Enabler – enabling activities rather than controlling them.
- Independent Remover – “The best thing that a manager can do is to help the team do what it knows how to do by removing impediments.”
- Manager of Managers – helping to manage other managers into an Agile mindset.
Conclusions
There’s a lot of focus on IT teams becoming Agile, but that’s only going to make a small change in most business. The real challenge is how a business becomes Agile, and that’s going to require a different kind of IT leadership.
This is a book I’m going to be coming back to.
Header Image: This is Lindisfarne Castle from Lindisfarne Harbour which is looking great after a number of years being surrounded in scaffolding for a renovation.
Graham Chastney 