CIOs know a thing or two about business disruption. Releasing semi-tested systems into the live environment, or failing to renew the software licences would be just two examples from back in the day.

Today we need CIOs to make disruption the objective rather than a by-product of our delivery. Any trends towards Bimodal IT are reflective of this. Though oddly the implication of this model is that Agile is disruptive and everything else is business as usual. Personally I see Agile as equally applicable to both modes.

So let me disrupt the Bimodal definition. One mode being those elements of IT that support the activities that give rise to current cash flows. The other mode being those activities that support the exploration of new cash flows, knowing that in time one or more of these experimental cash flows will likely become the principal one.

So perhaps we need to disrupt the name itself. Rather than Bimodal IT, we can talk about poly-modal business. With such a model, the business morphs from what was a distinct legal entity, into a hazy set of experiments. These experiments might be thought of as insurance policies, or plans A, B, C, and so on. They are in fact insurance policy protection against your current plan A business model being disrupted.

So how do we position the CIO in this poly-modal model? Well plan A, already has a CEO and a board. But plan B and its younger siblings are unlikely to have anything other than a project manager at their outset. So it makes sense to appoint someone to own these projects, a kind of portfolio project manager.

I think this is an opportunity for CIOs with an appetite for the excitement of a start-up culture, but who don't want to lose their footing on the corporate ladder. So the CIO role could morph into the Chief Information and Start-Up Officer, or CISO. Ah, but that's already taken. How about Chief Experiments Officer (CEO)? Taken. One last go. How about Chief Business Models Officer (CBMO)? It doesn't exactly run off the tongue, but at least it's available.

Straight away this would boost your strategic relevance. We do have to be a little careful, otherwise we will end up with our involvement being limited to that of project manager of these business experiments. So while the IT function can happily support these experiments, including the provision of data to support whether they are to be watered or weeded, it is important that your function is playing an active role in proposing the experiments to be included in the organisation's portfolio.

I explored this in an earlier column. You might recall 'T3': Toys, Threats and Table stakes. As we rush to become business leaders, we mustn't forget that our technology smarts can be applied to making strategic decisions, and not just IT management. I would expect many, if not all, of these experiments to be underpinned by one or more 'new' new technologies. The usual come to mind:

  • 3D printing.
  • AR / VR.
  • Robotics.
  • Machine learning.
  • Wearables.

The question then arises around how you structure your 'IT' department to become the business modelling function. 'Running the business' support is still required, but hopefully more and more of that can be pushed into the cloud/third parties. Similarly with 'grow the business'. My suggestion in this column is that we focus our attention, and resources, on 'change the business' support. Therefore, I believe you will need a team of project managers to set up and manage each experiment. They will require some degree of data science capability, in order to pick up on weak and not so weak signals emerging from the experiments' data.

Agile DevOps specialists who can respond quickly to the findings that emerge from a live experiment will be required. Such findings may be to accelerate forward, step backwards or in the Lean start-up parlance, 'pivot'. Ideally these technology specialists will be solution architects with the real-world equivalent of the knowledge that MBA programmes seek to confer.

Ideally the project managers and the technologists would be interchangeable.

What I am laying out is an extremely tall order in respect of the IT function’s aspiration, and the talent pool needed to deliver it.

So it appears that in order to remain strategically relevant, job number one is to disrupt the IT function.