When it comes to delivering value, you can never be too fast or too efficient. Today’s companies can call on powerful resources to help them react quickly—and profitably—in ever-changing environments. Embracing enterprise agility is one way, but another path is to embrace digital platform-based models. This enabler, however, is often overlooked. Of those companies that pursue digital-based platform models, many fall into a costly trap: they manage their digital platforms like a shared service.
Our experience helping clients pursue their digital ambitions highlights that trying to execute platform-based digital delivery within a shared service model will not work. Speed and innovation are lost in this traditional, IT model. A fundamental reason that traps emerge is that organizations equate digital platforms to shared service models optimized for cost and standardization. These shared teams are optimizing for the wrong thing.
Instead, success requires a more digitally savvy operating model. Companies that choose this path set up their digital operating model for faster performance that competes with even the most sophisticated digital businesses. To truly operate like successful digital platforms, they should optimize for the speed to outcome of the teams that consume their services.
In this article, we explore what a digital platform-based operating model needs to look like—and how to avoid the many traps that hinder a company’s platform development. We lay out how constituent delivery units—teams of teams and their underlying squads—need to be defined at setup. (See the sidebar, “Glossary.”) And we identify three key steps to implementing an effective digital platform. Companies that avoid traps and focus on how to set up their digital operating model for success stand the best chance of competing with digital natives.
Squads—a persistent, dedicated, and cross-functional delivery team made up of 6–12 people from both the business and technology sides of the organization. Squads are the underlying unit of delivery in modern digital development.
Teams of teams—multiple squads that collaborate together in one delivery unit to create value. Typically, each delivery units is no larger than ~120–130 people. Also referred to as “tribes,” “labs,” or “fleets” in some implementations.
The Unique Benefits of Digital Platforms
Digital platforms can be transformative resources that support an ecosystem of end users, clients, suppliers, and digital product developers who collaborate and create value. Platforms are the foundational operating model of successful digital companies. Successful examples show up in a wide range of industries, from wealth platforms to rideshare start-ups. The iconic early digital platforms were the generation of phones that created app stores, which today have millions of developers creating new phone features for users. Technical cloud and data platforms transform the underlying infrastructure and data to make such resources easily accessible.
Digital platforms have a set of unique benefits. They allow multiple developer teams to create, develop, test, and deploy product features on the platform independently of the central platform development team. Speed of feature development and re-use levels of data and features are exponentially higher than the levels that a traditional shared service-based technology team can achieve. Digital platforms create a consistent and integrated user experience for end users and clients, regardless of the technology of the channel in use. And they create highly effective journeys for users, clients, and suppliers alike by leveraging automation, data, and AI to generate insights and value.
Why the Shared Service Trap Is Such a Problem
Traditional technology operating model discussions tend to revolve around the centralization versus decentralization axis. In a decentralized model, teams supporting local business units often deliver faster outcomes, but at the expense of higher overall costs and sometimes fragmented technology stacks and long-term technical debt. In a centralized, shared services model, shared teams are optimized to drive efficiency and standardization. Invariably, local agility suffers.
In such models, work is often planned around a project-based funding model, which limits regular benefits delivery, tracking, and investments in continuous improvement. In addition, shared teams’ demand for feature scope almost always outstrips centrally available resources, further limiting investments in continuous improvement or creating services for self-consumption.
The critical trap for many organizations is to equate digital platforms with centralized shared services, leading to several consequences. (See the sidebar, “The Challenges of Moving to Digital-Enabled Business Platforms.”) Adjusting the organization charts to align resources to shared platforms does not change what is happening under the covers. Typically, work is still queued to a central team to add features to the platform. As more teams increasingly demand more services from the platform, development becomes even slower and more remote. Furthermore, if the platform is funded by business case-prioritized projects, the project scope includes disincentives to invest in the platform capabilities that ultimately increase speed to outcome.
Longstanding organizations often ask how they can compete with the digital natives that show up in every industry. A digital platform is part of the answer for these organizations. But a company must avoid the many pitfalls of a shared services approach if they want to transform their platform into a value-generating part of the business.Changing reporting lines alone are only part of the answer—and a shared service model is likely not the answer.
In a shared service model, reporting lines often change as technology resources are moved from project
When competing business units expect a centralized platform development team to prioritize their projects, bottlenecks inevitably form. Furthermore, no unit likes to be the developer’s fourth or fifth customer. Dissatisfaction and delays leave stakeholders wary of the shared services model.
Sometimes shared services models are broken down along functional lines into central, factory teams, including development, test, operations, and design teams. This setup is damaging to platform development as it disaggregates the value chain even further and creates handoffs, dependencies, and a lack of accountability for business outcomes.
A hybrid, cross-functional model is essential to avoid these divisions.The prevailing project-oriented funding models and governance inhibit innovation and outcome-based value or improvement.
Project-based investment governance models often fail to fund improvements to the platform’s speed-to-market, automation, and efficiency. These models also encourage unrealistic business cases and large scale, big-bang implementations. They rarely promote the sort of change that delivers incremental value and appropriate use cases.
A project-oriented model creates more problems. Resources rarely stay in one place long enough to become fully optimized in a way that platforms need. Even worse, ways of working, organizational structures, or even weight of regulatory compliance can stifle digital innovation. The best ideas are starved of funding and innovation suffers. Additionally, the balance between innovation/experimentation and cost/work exploitation is sometimes tipped too heavily in one direction. Even some enterprise agility models suffer this imbalance as work governance outweighs digital experimentation.
To avoid this trap, rethink the governance funding model and focus on persistent dedication of resources against platforms to create incremental value.Teams ignore the importance of outcome measurement and data.
Decisions in platform teams are often based on poor information. Organizations lack the data that shows how investments and change drive better business outcomes. Data around change velocity, predictability, cycle time, and development waste are also scarce.
Individual incentives can often be misaligned to the most important business outcomes and inhibit cross-functional working. It is essential that platform teams set up, as soon as possible, the metrics that demonstrate platform progress and improvement.
The best platform teams will typically be very clear of the outcomes they are pursuing, typically framed as objectives and key results. They should leverage artifacts such as business-value-driver trees to define and align what work drives value and identify key metrics.Leaders
should guide the teams to think of what they need to achieve and how they will achieve it. They should continuously ask to review these aspects with platform teams to discuss value levels that are possible.Changing skills, roles, and individual incentives is seen as too difficult.
Traditional businesses often fail to grasp that they need very different skills and roles throughout the organization to get the most out of platforms and technology engagement. Key roles include product owners, quality and reliability engineers, people who can configure and code digital solutions, digital customer journey designers, and data scientists.
Leaders also often overlook important technical aspects when specifying roles, or they fail to validate critical competencies when hiring. Jobs go to the candidates who speak all the right buzzwords but have no real practical experience.
A common pitfall is to not remove traditional coordination roles or manual activities in the delivery organization, such as project management, manual test, and quality.
Modern software engineering skills and product ownership skills need to be attracted, grown, and retained. For this, the context for growth needs to be created and maintained. Consistency of delivery model, relentless focus on outcomes, and continuous investments in delivery productivity go a long way. Not focusing on creating the conditions for this to be successful is a common error that leads to attrition and retention problems.Culture and leadership are not well aligned—and no one notices.
Digital-native companies often have a distinctive digital culture and ways of working that show up in several characteristics:
- There is a relentless focus on what is valuable for customers and business outcomes.
- Continuous feedback loops are the norm, capturing what they are doing (impact to business outcomes) and how are they going about it (impact on delivery productivity).
- Small increments are the mantra for what and how they deliver; most of digital natives started with limited funding and a need to quickly test hypothesis in the market.
- Business executives are accountable for change—rather than change being handed over to tech teams to deliver.
- Fast collaboration is the norm, fostered by shared incentives to outcomes.
A business that lacks these qualities—and doesn’t pay attention to changing the culture—will struggle to implement a platform properly.
Business leaders can lack the technology understanding to promote a platform-based vision. Maybe they are too hands-off to steer their organizations to compete against their digital savvy competitors. Maybe they are reluctant to “own” the needed change.
Many organizations will need a program of executive coaching and education to prepare managers to better support the platform teams they lead.Technology is “too difficult” to change.
Digital natives often base their businesses on modern, cloud-based software technology stacks, API-based data interchange, and advanced AI and tooling automation. They seldom have technology legacy, complexity, or data locked up in traditional systems.
Traditional organizations can feel like changing a single line of code is like creating, testing, and launching a whole new mobile app. Accessing their own data can feel difficult.
A pragmatic roadmap of improvement must be in place to incrementally deliver improvements linked to value aligned business use cases. This roadmap needs to free data from core systems, develop a shareable layer of modern digital components, and promote communication between systems using modern digital APIs.
When companies fall into service traps, growth is likely linear at best, contrasted to the exponential growth in value, capabilities, and services typically shown by digital natives. The usual management reaction is to add more resources to scale up output and value. At worst, the resulting inefficiency drives up cost, introduces architecture complexity, hinders resilience, and deters teams from engaging the platform. This, in turn, slows down speed to value and increases technical debt. Value from software stalls and even erodes.
Creating a Digital Platform-Based Operating Model
The ideal digital platform is built on a hybrid product-based delivery model that is both centralized and decentralized. The key unit of delivery is the squad. This delivery unit—persistent, dedicated, and cross-functional—is made up of 6–12 people from both the business and technology sides of the organization.
There are two kinds of squads in a platform-based operating model—product based and platform based.
- Product squads are responsible for building and running the platform’s digital products and assets that create value to end users, customers, and the business, leveraging the capabilities of the platforms. These squads should be measured on value-based outcomes.
Platform squads are responsible for creating and managing the platform and should be incentivized on the overall cost of the platform and the speed to outcome achieved by users (as well as product squads or teams outside the entity that consume platform services). They focus on creating self-service capabilities—access to data, functionality, common features, tools—that are typically exposed through APIs “as a service.” These allow users to develop, test, and deploy their features in a controlled way with a clear expectation of functionality and performance.
These squads should measure themselves on how easy or difficult it can be for users to generate value from leveraging platform services, which can be characterized as a sort of “NPS Score” of the platform.
How these squads are set up to function is vital to an effective, platform-based digital operating model.
Delivery units should have enough scale to drive impact. The digital platform model’s success relies on leaders organizing squads to ensure that the right resources and capabilities are in place to optimize impact. Squads in and of themselves typically can’t deliver enough impact, so they need to be part of a broader delivery unit. Squads should therefore be oriented under teams of teams or autonomous digital delivery units (sometimes called tribes, fleets, or labs), ideally sized around 80–100 FTEs.
These delivery units usually align to “value streams,” like client or user journeys (such as onboarding), end to end products lifecycles (such as equities trading), or business processes (order to cash). They have clear purpose, and their scope typically extends beyond software development, therefore achieving sufficient, self-contained autonomy to shape how to best drive value. This autonomy is bounded with a clear definition of the outcomes the unit is pursuing and how they pursue these outcomes. The definition includes architectural and procedural guardrails.
These organizational choices keep the business from a serious misstep. Just creating a myriad of small, independent product and platform squads makes it almost impossible to align the work of delivery units with value-generating offerings. Moreover, it makes it close to impossible to plan effectively, given the myriad of interdependencies that unscaled models yield. Organizing squads in team-of-teams structures allows the scope to be more end-to-end, pushes complexity and decision making more locally, and enables the creation and management of self-contained services.
Team members should report into their discipline—not the product owner. A second key point is that cross-functional squad members shouldn’t report to the product owners. They should report to chapter managers embedded in the squads. These managers focus on their discipline, such as data analytics, software engineering, owning a specific software asset, or test engineering. They set standards and guardrails for how their squads members operate. They are responsible for recruiting new talent into the discipline, as well as their ongoing development.
Some squad members will spend the majority of their time either outside the squad (as revenue generators, support to function members, or subject matter experts), or they are a scarce resource in the organization (such as DevOps engineers or UX developers). Such members can report into Centers of Expertise (CoEs). Squad-level coordination is critical to ensure these CoE resources engage with the squads at the right time in the right way. Most of the same management principles should apply—such as setting guardrails and ongoing development—which provide rare skills and resources for careful deployment across multiple digital delivery units.
Scaling the model requires consistent ways of working across delivery units. A third piece that is critical to scale this model and its productivity is to anchor on consistent ways of working across the digital delivery units, from methods and practices to governance. Like a franchise model or a fractal organization, each digital delivery unit is a local version of a standard operating model with centrally provided playbooks, training, and coaching. Working within the guardrails of a consistent operating model and with the sufficient operational maturity, teams are free to innovate, bringing speed and responsiveness to whatever problem the business faces.
When implemented at scale, digital platform-based models can deliver exponential acceleration in time to market and new product delivery.
There are huge benefits to operating in this way instead of a shared service-based model. When implemented at scale, digital platform-based models can deliver exponential acceleration in time to market and new product delivery (2x to 8x improvements can be typical). They can reduce development costs by 15% to 25%, spark a 10% to 20% increase in customer satisfaction, and generate a higher return on digital investment.
Prioritize Three Unlocks to Succeed
Setting up and yielding performance from a digital platform-based model is no immediate feat. It can take time if the starting point is legacy organization structures, delivery models, and architecture landscapes.
In our experience, there are three unlocks that need to be prioritized concurrently to make this work.
Building a foundation of architecture modernization where DevSecOps is not a bolt-on or a nice-to-have. Leaders must understand and take advantage of the fact that digital-platform delivery performance is enabled through technologies, often new, that present product teams with a self-service consumption pattern.
It is not enough to set up digital delivery units executing good agile development practices; the battle for speed is ultimately won in the architecture and DevSecOps arena. The right platform and DevSecOps technologies can transform the way teams work, just as incentives can encourage a platform-based way of working. To enable the transition to this digital platform based operating model, it is vital to prioritize three actions:
- Provide technical uplift strategies and roadmaps that decouple product development dependencies.
- Make an ongoing investment in accelerating product and service builds.
- Continuously optimize the route to live deployment and, more importantly, time to business impact.
Strong technical architecture leadership and practical engineering skills make this all possible. The role of leaders in this model is to both encourage and measure product delivery performance. Businesses can accomplish this by charting and investing in the transition to DevSecOps and platform technologies. They should ringfence some of the investment envelope and product team capacity to improve product and platform performance. (See the sidebar, ”Legacy Technologies in a Digital Platform-Based Organization.”)
Many established platform-based businesses are enabled by technologies from a previous generation. From direct to customer financial institutions of the 1990s still active today to cross-company airline reservation systems, these platforms use technologies that are ill-suited to modern digital development. At best, these technical platforms operate with a level of operational risk that remains manageable only if business volumes or change levels don’t rise quickly. At worst, these platforms are slow and vulnerable and are an executive’s living nightmare.
Dealing efficiently with these legacy technologies is vital. The underlying technology can rarely be converted to enable product teams to independently develop, test, and deploy safely. Without this ability, system release will always stall. Moreover, the technologies are often so old that employees don’t have the skills to manage them—further raising risk.
The simple and basic agile, cross-functional squad model isn’t useful here and can be counterproductive. Instead, the first step is to isolate digital teams from the underlying legacy platform technologies using a stable set of modern system APIs. When these APIs are made available as part of a digital development platform, digital product teams can access the data and functions of the legacy technology. They can create new digital assets independently and reduce the dependency on the legacy development team to enable new digital features. For example, digital teams can create new digital client and colleague journeys independently of the legacy technologies.
If the platform’s development and speed and quantity of business value is still lagging, a technical renovation roadmap can gradually remove and replace the legacy technologies with modern replacements. The emphasis is on gradually where possible—rather than a ”big bang,” because long, multiyear, one-shot system replacement projects can also be a sponsoring executive’s worst nightmare.
A ”build it and they will come” mentality for platforms never works. Nor does a “head in the sand” reaction, which results in wasted efforts in trying to turn the handle faster on the old model while still trying to compete with more digital-savvy players. The consequence is not just that value does not come fast enough. Talent gets pushed to the limit in old delivery models, leading to burnout and high attrition rates.
The key is to modernize while delivering value at speed and at scale. The platform capabilities need to be developed in collaboration with product teams. Platform roadmaps need to be anchored on an initial small set of valuable use cases.
We’ve found that a successful digital platform gets several dimensions right. (See the exhibit.) In addition to leadership empowerment and alignment and ringfenced delivery units following good agile development practices, it is essential to have a deliberate focus in establishing DevSecOps practices to maximize speed to outcome and a path to ongoing architecture modernization.