What if an investor managed your IT? One thing it would likely hit on quickly is an important detail: for many companies, a larger proportion of the IT organization is focused on support and administrative work that’s often manual and inefficient—testing, deployment, maintenance, code fixes, and so on. At two financial services organizations we analyzed, a stunning 90 percent of the IT organization was focused on these kinds of tasks. That left just 10 percent of technologists’ capacity for business priorities and market-differentiating work (Exhibit 1).
This state of affairs partly explains why IT is often viewed as a cost center and a bottleneck by the business. It also highlights one of the reasons that incumbents are struggling to keep up with tech companies. With just 10 percent of IT allocated to generating new business value, incumbents are not battle ready when it comes to contending with nimble tech players.
Stay current on your favorite topics
As any investor would tell you, place your resource bets where you believe there is value. For IT, that means flipping the ratio, so that the great majority of IT resources are working on products that build value for the business. As simple as that may sound, few IT organizations have been able to do it. Some companies have managed to pull it off, however, by following a specific recipe that allows them to work better and smarter. Typical payback in making this shift—freeing as much as 30 to 40 percent of IT labor costs—occurs within 18 to 24 months. Flipping the ratio can improve time to market and quality. The framework also allows organizations to quickly evaluate the business value of new technologies (cloud, microservices, automation, AI) and then rapidly scale adoption.
Would you like to learn more about McKinsey Digital?
How to escape the trap
IT leaders have been trying to increase the productivity of their teams, and many have made good progress. But too often, cloud and other solutions languish in proof-of-concept stages with little funding and, in many situations, no business case. Meanwhile, the day-to-day pressure of running an IT shop—improving service levels while lowering costs for existing systems—continues.
To flip the ratio, four things need to happen.
1. Extend agile to back-end IT
One of the main reasons back-end systems demand so many resources is that they do not take advantage of agile ways of working that have become second nature to most software developers. Either back-end teams confuse “doing” agile rather than actually “being” agile, running waterfall projects using the scrum method but not working in small teams rapidly iterating on small chunks of code, or agile doesn’t even make it to the back-end teams. Even application maintenance and IT infrastructure can benefit from agile principles, which is significant, since these areas often make up 40 to 60 percent of the IT organization. By introducing true agile methods—small, cross-functional teams or squads working in rapid iterations—to relevant enterprise IT work, companies can radically reduce the resources needed to support those systems while substantially improving service quality and the potential for automation.
One midsize US-based financial services company discovered just how much value using agile for back-end IT functions could be realized. At first, application-maintenance and IT-infrastructure functions—about 40 percent of the organization—did not use agile. Making matters worse, most of the demand on this group was reactive, handling incidents—data fixes and batch updates, for example—that required handoffs across multiple product teams and caused frequent interruptions, significantly reducing productivity.
The company decided to move to an agile operating model. It started by rigorously quantifying demand to improve transparency and looking at products based on how they fit into the end-to-end value chain, which allowed the company to better understand the dependencies across multiple products.
With better insight into demand, the company created small, self-sufficient teams to not just meet demand but figure out how to reduce it. By better understanding business needs, teams eliminated some demand by providing self-service options. Cross-functional teams had the people needed to not only identify the root cause of incidents but correct them immediately. They also focused on preventive maintenance and predictive monitoring to address issues before they became significant problems (Exhibit 2).
Within six months, the company had reduced application operations spend by more than 30 percent and improved system stability (reduced incident volume and elimination of false alerts) by more than 20 percent. Further, the company was on track to reduce capacity dedicated to administrative IT by another 20 to 30 percent and improve system stability by 30 to 50 percent over the following six months.
2. Measure the things that create value
You are what you measure. That old adage still applies, and it is one of the keys to improving how IT works. IT collects an overwhelming volume of data and metrics but often struggles to use them to drive business value. For example, the common metrics of product-delivery time and budget incentivize teams to release products quickly and under budget. There’s nothing wrong with that, of course, except that it can mask a very real issue: a product could perform well against these metrics but still be a bad product that demands lots of time to fix its defects or maintain it.
IT leaders need instead to measure the performance and health of the organization based on the desired outcomes. In the case of the financial services company’s application-operations team, elimination of reactive demand was the desired outcome, and percentage of false alerts was a key metric. The best metrics not only show progress but also are specific and useful enough to be tracked every day, easy to measure, and highlight what changes are needed. YouTube, for example, realized that the amount of time people viewed a video (viewed hours) was the most important determinant of increasing revenue, so it focused all activities on improving that metric.1 The right metrics can also be measured at the squad, tribe, and organizational level, which allows for higher levels of self-governance through objectives and key results (OKRs) while providing the transparency that leadership needs (Exhibit 3).2
The platform play: How to operate like a tech company
3. Harness market dynamics to develop ‘IT for IT’ solutions and drive their adoption
There are typically multiple improvement opportunities that cut across many teams or products in IT—for example, a platform for the creation of application programming interfaces (APIs). These “IT for IT” solutions can help teams work more efficiently and effectively by standardizing processes and making code easy to reuse, for example. However, one of the big issues contributing to IT administrative bloat is that these sorts of IT-for-IT solutions often end up languishing unused. Not only are resources tied up in developing them, but further work is often needed because they don’t work as expected.
At one insurance company, this became a glaring issue. The API enablement team had done what it was asked to do: establish an API platform to let developers build new APIs more efficiently. Yet after investing in the platform, fewer than 100 APIs had been created on it, and worse, fewer than ten of those had been referenced more than five times—and this was in an organization of 500 developers. Why weren’t they using the platform? It turned out that it was just too difficult to use. Developers had to submit a manual request, which took a week to fulfill, so they found it easier to just write new code.
A better solution relies more on market-demand mechanisms. Agile teams create demand for tools and solutions they need to help hit their OKRs. As developers spot these needs, they propose a solution (such as developing a platform for API development or a portal for developers to find existing code) to meet the demand, which is quickly reviewed and funded (or rejected) by an oversight team. If approved, an enablement team is formed, made up of people with the right skills. IT organizations provide incentives for enablement teams to form, such as bonuses and recognition. The key difference, however, is that enablement teams have specific OKRs for not just delivering the product but showing that it works and is adopted. Developed tools and solutions need to solve the problem, be easy to use, and easily deployed (Exhibit 4).
We have found that a venture-capital (VC) funding model, in which IT leadership acts as the venture capitalist, works well to fund IT-for-IT solutions. In this system, anyone in the IT organization can submit an idea for creating a new enablement team; if an idea is deemed attractive, IT leadership provides seed funding and sets OKRs. Quarterly assessments show progress, and leadership decides whether to allocate another round of funding to that enablement team and what OKRs to pursue next (Exhibit 5).
In this model, the company’s executive committee acts as investors in a VC fund, so IT leadership goes to them annually (or more often, depending on the need) to demonstrate impact from the enablement teams and request VC funds for the next year. The effect is to force the teams in the tribe to behave like start-ups, moving quickly to demonstrate the value of their work.
4. Stay focused on driving the program
As in any transformation, time is the enemy. After an initial set of wins, progress often bogs down because teams run into problems, issues become more complex, or leadership simply loses interest. Without firm leadership and guidance, the full value potential of the resource allocation isn’t met, or—worse—the organization slides back to the old way of working. But too much leadership control stifles enthusiasm and the sense of autonomy that’s necessary for teams to be successful.
We have found that a thoughtful and disciplined quarterly IT review (QIR) process can be helpful (Exhibit 6). Similar to the quarterly business review (QBR) at most highly mature, agile organizations, the QIR process allows IT leaders to take stock of the progress, resolve issues, reallocate budgets as needed, and provide guidance on the next quarter’s priorities for pushing forward to flip the ratio. For their part, each agile squad/tribe assesses its progress on its top-level metrics, sets aspirational OKRs for the next quarter, and submits them to their peers and leadership for review.
To be sure, flipping the ratio is not easy. But if IT organizations want to help build business value, they can only do so if their resources are allocated to value-creating activities.
