Part 2: Infrastructure Platform Initiatives Likely Won't Improve Your Organization's Agility

In my previous post I discussed the challenges that Infrastructure & Operations leaders face when striving to support product teams through self-service, API driven platforms. In brief, the value of moving towards a platform approach won't be fully realized unless I&O undergoes a similar transformation that product teams have. I&O leaders need to transform their group to become both market driven and user centric, and to embrace an agile mindset to value delivery. Based on our experiences with clients living and breathing I&O transformations, the biggest risk facing I&O platform initiatives are more closely related to realizing value and fostering real behavioral change that leads to meaningful adoption.

If I&O is serious about enabling product teams, they need to accompany their move away from legacy infrastructure with a move away from a legacy mindset.

The new I&O mindset is typified by the following principles:

• Decentralize decision making to product teams
• I&O treats product teams as a market of voluntary consumers
• I&O takes a holistic product and services stance to provide the best possible Team Experience (TeamEx)
• I&O focuses on enabling behavior, not governing conformance

The Centralization Management Trap

When shifting to modern infrastructure platforms I&O teams will face an enormous increase in complexity, and not just from a proliferation of new tools and vendor solutions. Micro-services, PaaS, IaaS, containers, services mesh, polyglot development, chaos engineering, continuous delivery, limited blast radius deployments, etc. all lead to more resilient infrastructure. But they also leave us with a tech stack that is much more complicated under the hood. But the answer to managing complexity can only partially lie in architecture. True success means rethinking how you organize to manage this complexity.

Most platform teams struggle when they ignore the complexity management trap. Complexity in an enterprise is increasingly a function of uncertainty, un-anticipated change, increased diversity, and continuous turbulence. By its very nature, complexity can't be centrally managed. Central planning will not work either. It is impossible for I&O teams to deliver against all the unique requirements across your organization; whether it is responding to all the distinct market changes across the business or creating something that makes every user happy—winning the complexity game through centralized management is unrealistic.

The agile approach that customer facing parts of the organization take to dealing with complexity is to decentralize the organization into market facing product teams. Product teams that are empowered to interact directly with the markets they service and have the autonomy to make product decisions based on market feedback. Core to the agile operating model is letting the teams that have the market context be the ones to decide how to evolve and adapt based on how the market reacts to the products and services they provide.

In fact, Gartner’s infrastructure platform principles of adaptability, abstraction, and agnosticism are first and foremost the principles required to enable the necessary decoupling and encapsulation required for decentralization. When coming up with the right architecture, we need to do so with an eye towards increasing the operational autonomy of product teams. Without this autonomy, product teams will struggle to keep up with their markets. In contrast, when we try to centrally manage all the tools and platforms that a team wants to use, we end up with an unmanageable mess, a Frankenstein that pleases no one.

[Lockheed Martin F-35 – see Inside America’s Dysfunctional Trillion-Dollar Fighter-Jet Program - The New York Times (nytimes.com)]

Of course, taking decentralization to the extreme you end up with a diaspora of separate teams with nothing to tie them together. No concept of sharing, or alignment, or anything to make the teams a single organization. This is obviously an expensive and risky proposition. I&O needs a new approach. One that maximizes the product teams' ability to decide how to accomplish their work, including what I&O services to leverage, and make it easy for teams to take advantage of an amazing ecosystem of I&O platforms and tools.

From Monopoly to Market Orientation

The growth of digital businesses has shown us that market feedback is essential if we want product teams to deliver better market outcomes. Yet market feedback is not meaningful unless we give consumers the choice of whether or not to use our company's products and services. But inside the organizational firewall, leaders tend to ignore this reality. When setting up internal support services, product teams are forced to use every centralized service, including I&O, that the enterprise has on offer. These services are internal monopolies inside the organization and are almost always a poor fit for the teams' need's as a result. In the real world, we know that monopolies benefit nobody but the monopoly. Inevitably customers always end up being the ones that suffer when forced to deal with a monopoly.

If platform teams are to balance short-term and strategic needs of the product teams they serve, then they need to be subjected to the same market forces that product teams face.

Platform teams need to manage their own P&L and charge product teams for their services. Product teams need to be able to choose to not use specific I&O services and seek alternatives if their needs aren't being met. Choice acts as a forcing function for platform teams to improve their offering by providing the services that product delivery teams need and want, rather than platform teams guessing and imposing a poor service.

From Ad-Hoc Tasks to Product and Service Orientation

Market orientation puts an onus on platform teams to deeply understand the needs of product teams to create the value that those teams want to consume. This means that platform teams must arm themselves with product management and user engagement capabilities similar to what we see represented within modern product teams. The focus needs to go beyond merely building a solution, and towards operating and supporting the best possible experience for product teams. Creating the best possible experience for product represents a huge shift for many I&O groups. For I&O groups considering this change most will require significant investment across the entire value creation including:

1. How to understand the needs of product teams
2. How to validate that features are being adopted
3. How to collect and act upon feedback to improve the platform
4. How to improve the service experience for product teams

We have seen I&O clients make both the architecture switch and capabilities investment. As a result, they have been able to provide the best possible experience for product delivery teams. We refer to these organizational outcomes as TeamEx.

From Governor to Enabler

Gartner’s recommendations also include the need to balance both governance and providing a good service, but this is a false dichotomy. Platform teams can't provide a positive experience to a product team by telling them what to do. But platform teams can influence the behavior of product teams through enablement. An enabler is focused on increasing the capability of a team. The platform enabler is also focused on improving the skills of the team to own more of the I&O domain. Enablers bring the platform and tools required to assist teams. Here the enabler is focused on the problem that the tech is solving versus the technology. Better behavior is nurtured through coaching, mentorship, and education.

While the transformation of I&O towards an API powered services and other self-service platforms can't come soon enough, the value of moving towards a platform approach won't be fully realized unless I&O undergoes a similar transformation to become both market driven, and user centric, and take an agile approach to delivering value.