Brief

Fast and Faster: Why a Two-Speed IT Model Is Off Track

Technology functions need to become quicker and more nimble, but splitting the organization in two misses opportunities and creates new problems.

By Will Poindexter, Vishy Padmanabhan and Steve Berez

First published on junio 07, 2016
min read


Technology organizations need to become more nimble and move faster to keep up with business change. Customer expectations are growing, cycle times are shorter, and innovative products and services have become more important than ever. So how can technology executives become more responsive to these demands? Some organizations are trying a two-speed approach, with part of the organization becoming more nimble and responsive for customer-facing initiatives while the rest manages legacy systems at the old pace. It’s a temptingly simple way to solve the issue, with just one real ﬂaw: It doesn’t work. Companies are ﬁnding that the two-speed IT model is fraught with practical issues that make it unsustainable. In our conversations with technology executives in ﬁnancial services, retail, media and entertainment, most tell us the concept raises costs, complexity and false expectations without delivering results. Companies that have considered or attempted two-speed models describe three main reasons why it ultimately fails. Architectural disconnect. Two-speed IT could have a chance of working if modular, service-oriented architecture were more pervasive throughout the technology stack. However, choke points develop when fast-moving Agile initiatives run up against core backend systems that move at slower test-and-release cycles. One US consumer credit organization found this when it created fast-moving teams for the customer-facing part of the company, only to learn that there were very few things those teams could do without relying on the rest of the organization and the technology architecture stack, which was not designed for speed. Tools are available to support continuous integration, testing and deployment. And these can help ease the pain, but they are not widely adopted. Business complexity. Two speeds can complicate life for IT’s business partners, who have to ﬁgure out how and when to work with each part of the organization, and have to coordinate efforts that depend on both. Once they see how quick and responsive part of the organization is, it’s only natural for them to ask why they can’t get that more consistently across all of technology. Unfairness. Splitting the IT organization limits new capability building to the faster team, with limited opportunities for knowledge sharing and transfer of skills. This can create barriers in collaboration and career development, and raise tensions between the two groups. To keep up with growing consumer demands for innovative products and services, digital leaders are looking beyond two-track IT to more scalable solutions. Vishy Padmanabhan, a partner in Bain's Information Technology practice, discusses how committing to a full transformation can bring an entire organization up to speed and create enduring benefits. Same destination, different pace A better approach is for everyone in the technology organization to speed up and learn new ways of working such as Agile and DevOps—and two-speed only delays that process. Some groups will get there faster, including those that have to deliver cutting-edge products and services frequently. They typically operate further from the core operations, so they can take risks and tolerate trade-offs between quality and speed. These groups can experiment and become a test bed of new practices, which they can then transfer to the rest of the organization. As the rest of the organization embraces Agile and DevOps at scale, the entire company should see signiﬁcant productivity gains from faster development cycles and closer alignment with the business. One retail bank uses DevOps tools and techniques in its mainframe environment. The pace of change may differ between the groups working on systems of engagement and those working on systems of record, but core principles and the operating model should be consistent throughout the company. Everyone is headed in the same direction, and if you must think in terms of two speeds to get there, let’s call them fast and faster. All together now The rationale for maintaining a slower, more traditional operating model for core operations is that established processes ensure more stability and higher quality for the mission-critical data and operations at the center of the organization. But it is possible to become more nimble while maintaining quality and stability. We know of many large organizations that are making fundamental changes to become or remain leaders in digital, and they are bringing everyone along on the journey. For example, at one large US retailer that was struggling with an indebted IT organization and slow delivery model, the chief information ofﬁcer rallied support for and led an effort to create a more uniﬁed and responsive IT function. The CIO’s feeling was that the entire organization had to become more responsive, so there was no point in leaving some people or departments behind. The retailer shifted to a product model that ties funding and governance more directly to business outcomes while rapidly moving the entire organization toward Agile development. The company tested the new model in multiple scenarios that included different technology platforms and parts of the IT organization to identify and remove barriers and then rolled it out across the IT function. The new model helped keep pace with the company’s digital transformation and reduced overall IT spending by about 20%. The parts of the organization that moved faster to the new model saw a 300% productivity gain while quality increased by about 15%. In another example, an insurance company has moved all development to Agile and is aggressively embracing cloud services, such as IaaS (infrastructure as a service) and PaaS (platform as a service), to increase performance, reduce delivery cycle times and become more ﬂexible. Different groups deliver at different speeds, but the company does not set up different operating models or organization structures based on delivery speed. This approach can improve productivity, boost morale and make IT more nimble and fast. Technology leaders that blaze the way forward set a clear direction and send a strong signal that the leadership supports this move and, just as importantly, understands the risks and pressures involved. Starting out right Moving the entire organization isn’t easy. Some IT staffers follow practices that have been well established for decades, and many will counter that newer and more nimble methodologies may work well in areas such as user interface design but are less suitable for mission-critical core operations. Every company will move forward based on its own priorities and capabilities. However, the technology leaders who demonstrate successful progress share a few traits in common. They develop a clear-eyed assessment of their starting point. Many companies say that they use Agile methods, but they overlook the most critical elements and instead use a hybrid of waterfall and Agile: “Agilefall.” An accurate assessment of the adoption of best practices—including Agile and DevOps principles, product rather than project development, cloud delivery models, iterative funding, colocated business and IT teams, and aligned business and technology incentives—can help organizations understand where they are and how far they have to go. They have a clearly deﬁned vision and end state that describes technologies and processes that they will adopt to move the entire organization forward toward the common goals of speed, agility and collaboration. They know what good looks like in the new model, but they are also pragmatic and agree on acceptable interim states on the path to full maturity. They commit to making the transformation but take a test-and-learn approach to achieve the vision. For example, if you want to move to a product model based on Agile, then set up use cases to test the new model and identify and solve roadblocks. These use cases should cover a swath of the technology landscape and organization. For example, one may use all modern technology, one may be on a custom mainframe application, and another may be a combination of several variables. The goal is to see where the model doesn’t work and ﬁx it—and the results can be surprising. Management has their back. Company leadership has to be committed not only to the change program but also on the scope of change and willing to support the transition, even if the program stumbles. Prioritization will be important, since not everything can change at once. What’s more, although some new talent may come in, most organizations are not prepared or inclined to turn over the majority of their technology talent. Successful leaders understand that the entire organization is moving toward a faster pace, and leadership has the responsibility to try to bring along the entire organization. And while it may be true that some traditional roles will decrease and some may opt out of the journey, endeavoring to lead everyone forward is more pragmatic than attempting to hire all new talent to ﬁll new roles. As companies race toward a digital future that relies on data, analytics, and rapidly emerging hardware and software technologies, the path to success cannot be to build two loosely connected IT operating models—one that is quick and responsive and another that is not. Doing so would introduce more complexity and confusion while failing to prepare the organization’s technology people and processes for the greater demands to come. Even so, companies must ﬁnd ways to reduce long development times that result from long and onerous governance, approval and funding processes; overly wrought efforts to perfect the scope; and clumsy handoffs between development, test and production teams and operations. A two-speed model may appear to free up the faster portions of the business, but it is ultimately an unsustainable and inequitable model. The right way forward is to move the IT organization toward a common goal, as many companies are demonstrating by committing to Agile, DevOps, cloud-based services, modular architecture and a mix of product and project work that aligns closely with business needs. Everyone in the organization may not arrive at the same time, but as long as the common destination is clear, the entire organization will share the same journey and reap the beneﬁts. Will Poindexter is a partner with Bain & Company in Chicago, Vishy Padmanabhan is a Bain partner in New York, and Steve Berez is a partner in Bain’s Boston office. All three work with Bain’s Global IT practice, which Steve leads in the Americas.

Technology organizations need to become more nimble and move faster to keep up with business change. Customer expectations are growing, cycle times are shorter, and innovative products and services have become more important than ever. So how can technology executives become more responsive to these demands?

Some organizations are trying a two-speed approach, with part of the organization becoming more nimble and responsive for customer-facing initiatives while the rest manages legacy systems at the old pace.

It’s a temptingly simple way to solve the issue, with just one real ﬂaw: It doesn’t work.

Companies are ﬁnding that the two-speed IT model is fraught with practical issues that make it unsustainable. In our conversations with technology executives in ﬁnancial services, retail, media and entertainment, most tell us the concept raises costs, complexity and false expectations without delivering results.

Companies that have considered or attempted two-speed models describe three main reasons why it ultimately fails.

Architectural disconnect. Two-speed IT could have a chance of working if modular, service-oriented architecture were more pervasive throughout the technology stack. However, choke points develop when fast-moving Agile initiatives run up against core backend systems that move at slower test-and-release cycles. One US consumer credit organization found this when it created fast-moving teams for the customer-facing part of the company, only to learn that there were very few things those teams could do without relying on the rest of the organization and the technology architecture stack, which was not designed for speed. Tools are available to support continuous integration, testing and deployment. And these can help ease the pain, but they are not widely adopted.

Business complexity. Two speeds can complicate life for IT’s business partners, who have to ﬁgure out how and when to work with each part of the organization, and have to coordinate efforts that depend on both. Once they see how quick and responsive part of the organization is, it’s only natural for them to ask why they can’t get that more consistently across all of technology.

Unfairness. Splitting the IT organization limits new capability building to the faster team, with limited opportunities for knowledge sharing and transfer of skills. This can create barriers in collaboration and career development, and raise tensions between the two groups.

To keep up with growing consumer demands for innovative products and services, digital leaders are looking beyond two-track IT to more scalable solutions. Vishy Padmanabhan, a partner in Bain's Information Technology practice, discusses how committing to a full transformation can bring an entire organization up to speed and create enduring benefits.

Same destination, different pace

A better approach is for everyone in the technology organization to speed up and learn new ways of working such as Agile and DevOps—and two-speed only delays that process. Some groups will get there faster, including those that have to deliver cutting-edge products and services frequently. They typically operate further from the core operations, so they can take risks and tolerate trade-offs between quality and speed. These groups can experiment and become a test bed of new practices, which they can then transfer to the rest of the organization.

As the rest of the organization embraces Agile and DevOps at scale, the entire company should see signiﬁcant productivity gains from faster development cycles and closer alignment with the business. One retail bank uses DevOps tools and techniques in its mainframe environment. The pace of change may differ between the groups working on systems of engagement and those working on systems of record, but core principles and the operating model should be consistent throughout the company. Everyone is headed in the same direction, and if you must think in terms of two speeds to get there, let’s call them fast and faster.

All together now

The rationale for maintaining a slower, more traditional operating model for core operations is that established processes ensure more stability and higher quality for the mission-critical data and operations at the center of the organization. But it is possible to become more nimble while maintaining quality and stability. We know of many large organizations that are making fundamental changes to become or remain leaders in digital, and they are bringing everyone along on the journey.

For example, at one large US retailer that was struggling with an indebted IT organization and slow delivery model, the chief information ofﬁcer rallied support for and led an effort to create a more uniﬁed and responsive IT function. The CIO’s feeling was that the entire organization had to become more responsive, so there was no point in leaving some people or departments behind. The retailer shifted to a product model that ties funding and governance more directly to business outcomes while rapidly moving the entire organization toward Agile development. The company tested the new model in multiple scenarios that included different technology platforms and parts of the IT organization to identify and remove barriers and then rolled it out across the IT function. The new model helped keep pace with the company’s digital transformation and reduced overall IT spending by about 20%. The parts of the organization that moved faster to the new model saw a 300% productivity gain while quality increased by about 15%.

In another example, an insurance company has moved all development to Agile and is aggressively embracing cloud services, such as IaaS (infrastructure as a service) and PaaS (platform as a service), to increase performance, reduce delivery cycle times and become more ﬂexible. Different groups deliver at different speeds, but the company does not set up different operating models or organization structures based on delivery speed. This approach can improve productivity, boost morale and make IT more nimble and fast.

Technology leaders that blaze the way forward set a clear direction and send a strong signal that the leadership supports this move and, just as importantly, understands the risks and pressures involved.

Starting out right

Moving the entire organization isn’t easy. Some IT staffers follow practices that have been well established for decades, and many will counter that newer and more nimble methodologies may work well in areas such as user interface design but are less suitable for mission-critical core operations. Every company will move forward based on its own priorities and capabilities. However, the technology leaders who demonstrate successful progress share a few traits in common.

They develop a clear-eyed assessment of their starting point. Many companies say that they use Agile methods, but they overlook the most critical elements and instead use a hybrid of waterfall and Agile: “Agilefall.” An accurate assessment of the adoption of best practices—including Agile and DevOps principles, product rather than project development, cloud delivery models, iterative funding, colocated business and IT teams, and aligned business and technology incentives—can help organizations understand where they are and how far they have to go.
They have a clearly deﬁned vision and end state that describes technologies and processes that they will adopt to move the entire organization forward toward the common goals of speed, agility and collaboration. They know what good looks like in the new model, but they are also pragmatic and agree on acceptable interim states on the path to full maturity.
They commit to making the transformation but take a test-and-learn approach to achieve the vision. For example, if you want to move to a product model based on Agile, then set up use cases to test the new model and identify and solve roadblocks. These use cases should cover a swath of the technology landscape and organization. For example, one may use all modern technology, one may be on a custom mainframe application, and another may be a combination of several variables. The goal is to see where the model doesn’t work and ﬁx it—and the results can be surprising.
Management has their back. Company leadership has to be committed not only to the change program but also on the scope of change and willing to support the transition, even if the program stumbles. Prioritization will be important, since not everything can change at once. What’s more, although some new talent may come in, most organizations are not prepared or inclined to turn over the majority of their technology talent. Successful leaders understand that the entire organization is moving toward a faster pace, and leadership has the responsibility to try to bring along the entire organization. And while it may be true that some traditional roles will decrease and some may opt out of the journey, endeavoring to lead everyone forward is more pragmatic than attempting to hire all new talent to ﬁll new roles.

As companies race toward a digital future that relies on data, analytics, and rapidly emerging hardware and software technologies, the path to success cannot be to build two loosely connected IT operating models—one that is quick and responsive and another that is not. Doing so would introduce more complexity and confusion while failing to prepare the organization’s technology people and processes for the greater demands to come.

Even so, companies must ﬁnd ways to reduce long development times that result from long and onerous governance, approval and funding processes; overly wrought efforts to perfect the scope; and clumsy handoffs between development, test and production teams and operations. A two-speed model may appear to free up the faster portions of the business, but it is ultimately an unsustainable and inequitable model. The right way forward is to move the IT organization toward a common goal, as many companies are demonstrating by committing to Agile, DevOps, cloud-based services, modular architecture and a mix of product and project work that aligns closely with business needs. Everyone in the organization may not arrive at the same time, but as long as the common destination is clear, the entire organization will share the same journey and reap the beneﬁts.

Will Poindexter is a partner with Bain & Company in Chicago, Vishy Padmanabhan is a Bain partner in New York, and Steve Berez is a partner in Bain’s Boston office. All three work with Bain’s Global IT practice, which Steve leads in the Americas.