How is the CIO role changing?

In today’s world, many CEOs forget they the must be CEOs (Chief Enabling Officers!) and act like CEOs (Chief Execution Officers!).  But that is not part of our topic now. We will save it for a rainy day.

We also see two important developments happening in the realm of CIO:

1. Technology and business boundaries are getting blurred. Either of them cannot be stand alone!
2. Business strategy is not decided independent of technology rather the latter is a critical component in formulating a plan.

In other words, the era of business-led / technology-enabled CIOs has ended; a new one technology-led / business enabled has begun!

What kind of battle is waged by the CIO? A three-pronged battle:

1. Drive / Enable business strategy harnessing the power of technology in a secure way
2. Battle with monolithic systems of records and data and inflexible, technical-debt ridden architecture
3. Maximize value

Where does that leave the CIO? Here is how I see the role changing:

There will be a huge metamorphosis of the role possibly eliminating a dedicated CIO. Parts of the role may manifest in other areas. For example, the resources (including technology, required infrastructure, cloud, network, end user computing, devices) might be controlled by the COO. The enabling aspects of this would be owned by the line function leaders who are responsible to customers or business stakeholders.

The first view point is that the CIO role would disappear. Whilst this may take a while, things will become difficult for the CIO in the coming few years. Certain steep changes will be the order of the day.

#1. CIOs who are experts in technology – legacy or digital can expect to be pigeon-holed. Those who use to to bamboozle the rest of the organization with fancy architecture and buzz words will recede into the background. They need to invest in soft skills. They need to seamlessly align with the organization business strategy and business line function. Every project that originates from the CIO office will be relentlessly subject to CBA (Cost Benefit Analysis). Can the CIO stand up and articulate what, when and how he plans to stay relevant and important to business? Even this won’t do; they should be skilled at spotting new business opportunities and be able to influence their ideas. They have to become more human and partner with others in order to maximize their value to business. This partnership can be internal or external. Nurturing and harnessing a good eco-system will help.

#2. Continuous realignment of the organization, teams, skills and outlook will be required even to stay afloat. What do I mean by this? IT world is ransacked by new trends and terms like agile, DevOps, DevSecOps, Continuous integration/deployment. More trends and methodologies will start coming in. We are already talking about a low or no code IT that can be bought, scaled up or down and customized / enriched. The CIOs should reflect on how and what this means for the team? We used to have specialists in IT like SQLServer expert, Oracle DBAs and Network engineers. Whilst some roles will continue, they need recalibration as the IT world changes. Does it pay for a separate testing category to be developed? Perhaps an automation tester is required. A developer should also be a capable tester. To what extent soft skills and business skills are to be embedded within IT? 

A recalibration of the IT team that is not compartmentalized but can be assembled to deliver digital transformation of the business is the need of the hour. And the IT team members should be prepared to don different roles in different teams! Towards this, the CIOs should be prepared to and implement redefinition and rebaselining of skills, recalibration, training and enablement etc. And the team identification, deployment and delivery should, subsequently, follow these new ways.

#3. A CIO should transform into being a change agent of the organization. They will have to become value creators and for that they should transform into change instigators. Status quo is no longer an option. Even if a CIO continuously maintains the estate well and runs a tight-knit disciplined shop, that won’t be enough. Most of the normal health parameters have been pushed into the very bottom so much so that they don’t require special oversight nor reporting. Today’s tools / products come with self-healing and self-reporting properties. In order to transform a business operations and drive value, they have to remain restless (in a positive way!). I would go to the extent of saying a controlled panic will do a world of good now and then!

To conclude:

• Tomorrow's CIOs will have to drive, innovate and execute with the first two as the dominating functions

• They need to enable a high-performing environment, business-oriented and flexible teams with multiple skills.

• The operational responsibilities will not go away but take up less and less time allowing them to act more as leaders, communicators and innovators.

• Quite a few organizations are taken aback by the lack of clear definition of “Digital.” A few CIOs and their direct reports, I met, are constantly worried by the lack of uniform definition of "Digital." Why worry? Instead, the CIO (whether it is a digitally-born or digitally-aspiring organization) can take this to his/her advantage. This is because any digital transformation is less about a digital technology or strategy but more about a successful business in the digital world.

Why does the business love Agile development?

Agile continues to be the preferred way of delivering business outcomes. Still organizations use waterfall techniques especially to the system of records. But it is agile that is becoming de rigeur for system of innovation and differentiation. Agile’s willingness to fail is the primary reason that endears it to the business.

I have been involved with more and more teams, especially in Europe. There are some very clear observations that are quite evident.

1. The mentality and emotion quotient surrounding a waterfall project team is still based on avoidance of risk. Of course, they do fill up the RAID log as it is commonly known. Documentation trumps up all other requirements.

   

   Agile Model in action

2. A pre-mature optimization happens in the delivery of such waterfall projects. Many factors contribute to it. One is the time lag behind the business requirements and delivery when everything changes around you in a faster manner. Second, the freezing of architecture and design without understanding some of the future-changes start pushing the projects into a tight corner.
3. Integration happens at the last and that’s where new but significant risks start to emerge as the project deals with other adjacencies.
4. Agile embraces risks and that’s what makes it adopt a different approach. The team starts in a humble manner and learn as they progress. Early and constant feedback changes the games.
5. With each sprint / release, integration happens. The product may be incomplete but it is brutally subjected to feedback and criticism. In general, the right behaviour, in agile teams, doesn’t make them nice and avoid negative feedback. The old adage “Silence is golden” doesn’t work.
6. As the teams, in waterfall, are split into smaller units for tighter control and delivery, the risks due to dependencies (known or unknown) rise faster. Michael Nygard says in Architecture without an end state “The problem with dependencies is that you can’t depend on them.”
7. Waterfall assumes the leader is quite capable and prone to enforcing a herd mentality. This works well to avoid a difficult terrain but not when the business is waiting to expand. In agile, the management trusts the teams to find their own way. This is not to was off one’s hands completely. After spending time to help the teams understand the big picture, trust the team to negotiate further. Equipping and empowering culture are important.
8. Recognizing that change is quite frequent, it is better to work on what we know latest instead of applying an artificial freeze. Agile teams remain flexible.
9. Team happiness becomes critical in agile teams. Continue to measure it.
10.  Agile teams indulge in such planning where more minds are put to work. Instead of waiting for someone to solve their problems, they are encouraged to find their own. The team, typically, rises to the challenges and comes with measures.

Not all parts of IT need to become fully agile for the sake of it.  But, the entire IT, as a coherent entity, needs to be agile o rnimble enough to the changing business. Where it makes sense and where IT remains a blocker to realizing business outcomes are those areas that should embrace this culture. 

Finally, a word of caution. Do not brand agile with no-process or free-for-all approach. It is where you lay the stress that becomes different. Projects in agile mode are also supported by quality and rigorous document and associated metrics. Informality should not be confused with indiscipline.

Is your CIO funding projects or business capabilities?

Context

Earlier, the CIOs tended to organize their teams and functions around specific projects. Wherever possible, consolidation was touted as the panacea! The seemingly good candidate is RTB (Run The Business) function that typically “Keep the lights on.” Support, both application and infrastructure, falls into this category.

As the rest of the units start aligning themselves to operate nimbly in an agile and digital world, what happened to the IT organization? Many CIOs have simply reorganized them using fancy terms but essentially retaining the same flavour. Ask them about the IT budget. They will talk about RUN and CHANGE. Drill them into more detail, for example the cost of introducing a new product and see their reaction!

In this blog, I share the experiences of working with CIOs and IT organizations around two important aspects.

• How to look at the IT budget and get answers quickly?
• How to align and develop an operating model?

Let’s understand the changing paradigms to the meaning of IT as organizations go digital and embrace new technologies:

Diagram #1: Emerging interpretation of IT in the digital context

In short, business strategy automatically becomes IT strategy. It is no longer possible for CIOs to emerge victorious when the entire business is going southwards! The CIOs are in the thick of things.

Funding Model

Diagram #2: IT Funding by Portfolio

Typically, the CIOs look at the funding by any of the three categories:

1. Type of focus - RTB (Run the Business), CTB (Change the Business) and Grow (Linked to Business Growth)
2. Budget (Cost of personnel, license, hardware, storage etc.)



Diagram #3: IT Funding by Budget

3. Financial accounting sense (Capex / Opex)

Diagram #4: IT Funding by Accounting

These types of funding keep the technological interdependencies and the business led IT aspects deeply hidden. The real cost drivers become virtually impossible to find quickly. In a way, this explains all the IT costs but presents an incomplete view. This may lead to investment silos and/or duplicates. The flexibility needed to understand digital investment is not the hallmark of these methods. Moreover, justifying the legacy refresh takes inordinate time.

Diagram #5: Allocation of IT Budget

Instead, allocate the IT budget by product line. For this, work with business to understand the strategic / relative importance of the product lines annually. Empower the PLMs (Product Line Managers) with the discretion to allocate funds to maintenance, technology refresh, innovation etc. They should have the wherewithal to reallocate the funding as priorities change.

In the diagram #6 below, an illustration is given. The key focus area is to build new business capabilities and ensure the business strategy is not impeded by IT. 

• New business capabilities (BC) are financed by respective business area budgets. Examples can be subscription based services like SaaS or getting third party services.
• New business capabilities are funded by IT to the extent of technology implementation or major changes/enhancements.
• Then comes the "Maintain to Operate" layer that focuses on licenses, upgrades, hardware/software maintenance, staffing etc.



Diagram #6: Shifting Budget Patterns



• Finally the digital foundation layer that addresses cloud / building new platforms etc. This directly mitigates operational risk.

As can be seen, the key differences to this type of approach are:

• Part of erstwhile IT budget for funding new products or building new capabilities is shifted to the respective business unit or area.
• Business area is the owner of the budget for introducing new capabilities.
• The funding that is required for digital foundation is separate from maintenance.
• The linkage of technology to the business capability is clear.

What comes out clearly is that enterprise wide view of technology spending covering business-led IT. This view complements the traditional views to gain quick insight into cost of transforming the landscape, cost of sustenance of new capabilities as well as introduction of newer ones. As the technology funding is clearly aligned to business, the ability of IT to influence and respond increases.

Operating Model

Let's start with what we aspects we should expect from the IT operating model.

• Faster time to market
• Greater business integration
• Flexible ways of working
• Improved customer experience

For this, we need to shift the mindset from projects to products. What are the differences?

Diagram #7: Redesigned Target Operating Model

How do we factor them in the operating model?

• Diagrams 7 and 8 give an overview of how to visualize these changes in the model and consequently the organization of the teams.
• Choose products or business capabilities over projects.
• Each capability is a vertical tower that comprises all IT operations pertaining to it. RTB and CTB work will come under this.
• The product line manager is empowered to organize his teams, allocate budget and change funding.
• These operations are done on the product lines in an agile / DevOps / CI manner.
• Everything cannot operate in a vertical stack. IT has to spot scaling / efficiency opportunities wherever possible. What is not common to each capability but to the entire organization is (1) the building blocks of application and (2) Cloud based scalable infrastructure. These may include shared applications, shared ERP, shared platforms, shared BI and shared data centre etc.

Diagram #8: Team Organization

Conclusion

It makes immense sense to appreciate the paradigm changes in the way IT is viewed and linked to the business. This should logically flow into the way the IT teams are structured and funded. 

What are the advantages of reorganizing the IT along these lines?

• Business knows easily the respective IT to discuss/contact.
• As the IT services each business capability, the skill sets / knowledge of understanding of the business grows within that unit. This means informed resources that have the ability to respond to changes.
• IT supports the business more efficiently in terms of understanding the cost components and come up with answers to question like – what will be the time taken / savings in IT if a product line is killed? what will be the incremental cost of introducing a new product in a particular market? Etc.
• The IT landscape becomes less complex and easier to understand/operate.
• The portfolio metrics, at each capability level, make direct sense to the business head as well as the CIO.

On a lighter note: If a CIO's lingo becomes as close to the business and everyone understands the CIO's response in the first instance itself without seeking further clarifications, latch on to that CIO for God's sake!