The Accidental CIO: A lean and agile playbook for IT leaders

Many of the challenges CIOs, CTOs and IT leaders face derive from the deeply embedded operating and mental models of organizations that were formed within contexts that are no longer relevant today. The problem is that the purpose of the system (the IT operating model) was designed for has changed. The old system is based on archetypes of CIOs that are mutually exclusive, in that either they specialize in running efficient operations (the service provider — order taking, stable, secure, process-oriented) or they are focused on innovation (the disruptor - adaptable, innovative, lightweight governance, fast). CIOs don’t need to be innovators or operational; they need to focus on innovation and operational stability. They need to manage digital transformation, digital optimization, and operation efficiency.

In The Accidental CIO: A lean and agile playbook for IT leaders, Scott Millett delivers an essential playbook, composed of a combination of big picture strategic thinking and hands-on pragmatic advice, to help CIOs, CTOs and IT leaders create a strategy that contributes to business success and design an adaptable operating model to execute it.

Here, we present an excerpt on how to design an adaptive operating model.

What is an adaptable operating model?

If the strategy is what we will do, the operating model describes how we will organize to do it. The operating model defines “how we work around here.” In its simplest terms, the operating model describes the choices on how people, process, and technology will be used to deliver the strategic business objectives. The operating model communicates where accountability lies; how decisions are made; the ways of working; and how we will invest, govern, and measure performance. The operating model is our system’s structure, the purpose of which is to deliver business benefits by producing customer value. Changes made at the operating model level will have an influence on the patterns of behavior within IT.

As illustrated in Figure 1, the operating model is the link between a company’s strategy and the IT organization’s ability to execute it. An effective operating model will ensure the successful execution of strategy.

 
Figure 1: The operating model is the link between strategy and execution.

The anatomy of an operating model

The operating model is made up of five components:

•    How we are organized. The organizational component defines the teams, reporting lines, and boundaries of responsibilities and accountability. The structure of an organization or a department is the most visual and perhaps often what people think of when they hear the term operating model. We will explore this in depth in Chapter 5, “How we are organized”.
•    How we work. The how we work component defines the set of processes that dictate how IT will approach work in terms of both discovery and delivery. These are the methodologies and frameworks influenced by the philosophies covered in Chapter 2 “Philosophies for A New System.” We will explore this in depth in Chapter 6, “How we work”.
•    How we govern. Governance refers to how we manage and prioritize demand, how we fund, how we measure, how we review performance, and where decisions rights lay. We will explore this in depth in Chapter 7, “How we govern”.
•    How we source and manage talent. The talent component defines how we will source, retain, and develop people that are required to deliver the IT strategy. We will explore this in depth in Chapter 8, “How we source and manage talent”.
•    How we lead. The leadership component defines the role leaders and managers will play in the IT department. We will explore this in depth in Chapter 9, “How we lead”.

As Dr. Russell Ackoff said, “A system is never the sum of its parts. It is the product of the interactions of its parts.” As shown in Figure 2, the five components that form the operating model are interconnected; they act as a system. Therefore, if there is a change in one component, there needs to be a change in the others to align all parts of the operating model to ensure the system effectively fulfils its purpose. If we change how we work, then we need to ensure we change how we govern and how we lead; this will also have an impact on the talent we need. Each component of the IT operating model will need to be optimized to support a holistic agile and adaptable method of operation.

Figure 2: The interrelated five components of the operating model.

A focus on being agile, not just doing agile

There isn’t one way to do IT; there are multiple ways of working, leading, and governing. There are even different types of people that are suited to one way of operating over another. Each combination has its own strengths and is appropriate within a given context. An agile operating model will not rigidly follow one way of operating, but it will adapt to the nature of a problem. As illustrated on the Wardley Map in Figure 3, there are multiple operating models for teams within the overall operating model depending on the nature of the problems you are facing. The talent attributes and attitudes are characteristics of what Simon Wardley refers to as Explorers, Villagers, and Town Planners, which we will look at in detail in Chapter 8, “How We Source And Manage Talent”.

Examples of different sub operating models:

Teams Dealing with Unique and Uncharted Problems:
•    Ways of working: Design thinking and Agile practices work well here.
•    Governance: In areas of exploration the value is in reducing uncertainty rather than measuring ROI, where rapid learning and fast decision cycles are important to discovering opportunities.
•    Leadership: Task teams with discovering market opportunities. Here we have good failure. As we experiment, we understand what doesn’t work and that helps us evolve how we tackle a problem and our understanding of it.
•    Talent: Entrepreneur and innovative creative types, happy to experiment and fail often in the quest to learn what works and what makes customers happy.

Teams Dealing with Reducing Waste in Known Problems:
•    Ways of working: Lean and agile practices work well here, where we need to remove waste and focus on operational efficiency.
•    Governance: Teams focus on producing outcomes that improve operational metrics such as revenue growth and profitability.
•    Leadership: Direct teams on the desired business outcomes.
•    Talent: People that like improving well understood but still complicated problems, with a focus on scale and efficiency.

Teams Dealing with Problems That Are Highly Evolved:
•    Ways of working: Waterfall and upfront planning work well here.
•    Governance: Business cases with a clear return on investment; project governance is conforming to a plan or budget. Focus is on reducing deviation from well-defined processes.
•    Leadership: Be more prescriptive and direct teams on output required. Have less tolerance for operational, aka bad, failure through poor execution of a solution in a well-understood problem area.
•    Talent: People that comfortable with a focus on operational efficiency and standardization.

Figure 3: Multiple operating models are required to manage the spectrum of work.

How do you design one?

As Alfred Chandler said, “Structure follows strategy.” The operating model, covered in Part 2, “Designing an Adaptive Operating Model,” is intrinsically linked to and exists only to deliver the strategy. Changing the operating model must be made in conjunction with the vision of the target architecture; without doing so, change will lead to an operating model inconsistent with the technology needs required to deliver strategy and therefore render any changes as ineffective. As illustrated in Figure 4, the target architecture, influenced by the current landscape and strategic actions, has the biggest influence on the target operating model. Behaviors, ways of working, and the organizational structure, when misaligned with the strategic intent, will impact IT’s ability to deliver the desired business outcomes. Like the strategy, the operating model design should not be viewed as something that is fixed or static once deployed. It will need to evolve to meet the changing needs of a digital business, to exploit technology advances, and to respond to other changes in the business context.

Figure 4: The operating model is influenced by the strategy and the target architecture choices.

As highlighted in Chapter 4, “The Anatomy of an Operating Model,” the structure and organizational design of IT may be highly visible, but it is only a single component of an operating model. Simply imitating the organizational design of another company, such as Spotify, without making the necessary changes to the other integrated components will have little behavioral or cultural impact.

The Process

The design of an adaptable operating model is part of the tactical planning process. We will explore the process of creating a strategy and designing an operating model in depth in Part 3, “Strategy to execution”, but in this section I will give a high level overall of the process. As illustrated in Figure 5, the IT strategy defines the intent of what actions IT will take to contribute to business success. From this point the process is to identify how the IT landscape needs to change to address capability gaps, what changes are required in the operating model to execute those changes and lastly what are the initiatives to make those changes to the technical architect and operating model.

Figure 5: The relationship or strategy and technical architecture to the operating model choices.

As shown in Figure 6, an initiative is the link between the strategic intent and operational execution. It’s a way to take the abstract vision of the strategy and turn it into portfolio of initiatives that we can build an operational plan around. An initiative proposal focuses on a specific goal, typically framed as a business outcome with a high-level solution, effort, and cost along with an accompanying business case. Initiatives can include operating model changes like the creation of new product teams or changes in the ways of working. Some will be cross-cutting, some focused on transformation, and some focused on brand-new business endeavors. Others will be focused on improving constraints of existing capabilities. Some will be driven by the product strategy, others by marketing or finance business needs. Some initiatives will be delivered in an agile way by small internal product teams, while others will need to integrate off-the-shelf software and may use a partner. Initiatives can vary in size from transformational, consisting of multiple projects and programs spanning many years, to a solidarity project with a much shorter time frame.

Here are some examples of initiatives:
•    Reduce customer contacts post order + measure: Fund a team to reduce the need for customers to contact us either by contact deflection or self service.
•    Retain subscribers + measure: Fund a team to reduce customers cancelling subscriptions.
•    Automate and improve the accuracy of stock forecasting + measure: Provide a system to automate the stock forecasting that currently takes days and is inaccurate.
•    Standardize Warehouse Supply Chain + measure: Integrate a new warehouse management solution to replace the many bespoke systems and legacy system we have in the different sub businesses.

Figure 6: IT initiatives address gaps in the technology architecture.

Define Strategic Intent

The first step is to define how we will invest in technology to contribute to business success. The business strategy requires changes to or the creation of value streams, customer journeys, and or business capabilities to achieve the strategic goals. Where these high level business needs require technical contribution these will form our IT strategic actions. This high levels of intent will guide investment in technology, and inform the IT tactical plan along with any operational essential needs. As shown in Figure 7, this information can be captured in the form of a heat-mapped business capability model to build consensus and alignment on the areas the business deems critical to success.

Figure 7: Creating a heat-mapped business capability model to highlight areas in need of investment.

Define the Technical Vision

In order to realize the strategic actions we will need to make changes to the IT architecture to address the business capabilities in need of improvement. Each action will require target architecture suggestions as illustrated in Figure 8. The goal of the target state suggestions is to show how we intend to use technology to address business needs and how the landscape can be consolidated to reduce complexity. The aim is not to create a highly detailed and executable diagram of the future state of the IT landscape. The intent is to establish a vision and standards, the purpose of which is to help guide the planning effort at the solution architecture level.

Figure 8: Define the target architecture to address business capability gaps.

Define the Operating Vision

Once the target architecture is defined, we can then understand the high-level impact to the operating model, as illustrated in Figure 9. Do we need to change our ways of working? Do we need to partner with a third party? Do we need to hire for new roles or train our existing teams? Do we need to create new product teams? How does the architecture choices affect the team structure? How does it affect funding and measurement? Just as there is a need to understand the end state for the technical architecture, we also need to understand it for the operating model and how we will do the work to create it.

Figure 9: Define the target operating model to execute the technical changes.

Capture the Technology Landscape and current IT capability

As shown in Figure 10, it is important to review the current IT landscape before we dive straight into solutions to address any technical gaps. Without due care and attention, the constant development and evolution of the IT landscape can become an intangible mess, complicating the technical estate, slowing down delivery, and increasing both risk and costs. The same applies to the operating model. We need to understand where we have gaps and where we need to improve.

Figure 10: Understand the current landscape, both the architecture and operating model.

Identify the IT initiatives Needed to Address Business Needs

With clarity on the business needs, along with the vision of the high-level architecture changes require to meet them, we can begin to explore IT initiatives as illustrated in Figure 11. The IT initiatives will define a high-level solution architecture and rough estimates on the relative effort, cost, and benefit in order to help with prioritizing and funding. The IT initiatives will address the gaps and shortcoming of the technical contribution of business capabilities as well as the operating model. They can be small projects such as evolutions to existing systems, or they can be large programs of work consisting of multiple projects introducing new products and services or transforming large parts of the business. At this stage, we are explicitly talking about high-level tactical initiatives rather than low-level operational projects. The tactical initiatives bridge the gap between the abstract strategic actions and the low-level operational projects and programs, ensuring there is a link between operation action and strategic intent.

The initiatives will define:
•    Technical Architecture Change: The high level solution outline required to address the business need.
•    Operating Model Change: The operating model component changes and investments required to execute it — talent, structure, governance, leadership and ways of working.

Figure 11: Initiatives the are large solution outlines that closed the gap between the target and current architectures for both technical and operating models.

This is the key bit. We are designing the operating model to deliver the strategy. Therefore we must apply the appropriate method based on the context of each initiative. Larger initiatives may themselves have multiple sub models within them. This is the essence of the adaptable and agile operating model. Understanding context of the problem you are trying to solve and apply the appropriate technical and operating model solution.

Visualizing operating model design using a Wardley Map

Wardley maps, which we will cover in detail in Chapters 3 and 12, can help visualize both target architecture suggestions and operation model changes. Creating Wardley maps turns the process of creating a target architecture and operating model into a map by providing movement through the plotting of capability evolution, which helps to provide context and guidance on the appropriate method of both technology and team organization to use to bridge capability gaps.

The Wardley map in Figure 12 communicates four things:
•    Strategy: We can see what is important, what is core, and what is competitive. We can see what is supportive and what is generic, thus we are able to understand what is key to supporting business success.
•    Architecture: We can start to understand dependencies and therefore components that logically belong together.
•    Team topology: We can use the knowledge of the business architecture as well as chosen methods to inform our organization design.
•    Way of Working: based on the evolution of the component we can determine the most appropriate way of working.

We will look at how to use a Wardley Map in detail in Chapter 12 “Tactical Planning: Deploying Strategy”.

Figure 12: Organizing teams based on capability dependencies and evolution.

An adaptable structure must follow strategy

There is no single way of working or magic organizational structure you can copy from another business. Your operating model is unique to your context. It defines how you are set up to do the work required to execute the strategy. Therefore the operating model is shaped directly from the strategic actions that IT will take to contribute to business success.

The new reality is that businesses are having to be ambidextrous, needing to constantly innovate on exploiting the current operation at the same time they are exploring new business models. As technology is core to both endeavors, there is a demand to change how IT operates.

Ultimately, we need to have an adaptable and balanced operating model that supports the need to explore as well as exploit. We need an operating model that is agile rather than simply one that does agile, in that we need to structure the ways of working to the context we find ourselves operating in, whether that be exploring or exploiting, tackling obvious or complicated problem contexts versus complex ones. We need an operating model that can adapt to work depending on the nature of the work. We need to be able to support both operation and innovation. To do this, we need balance — a balance of autonomy and accountability, control and alignment, innovation and stability, fluid team and hierarchical leadership structures, customer value and shareholder value. We need balance in the system to create an intrinsically motivated, engaged, and inspired workforce. That is what is required to win.