Redesigning teams, rethinking platforms, and reclaiming agility—how enterprises can turn friction into flow and fragmented IT Ops into scalable, service-oriented delivery.

In many large organisations, infrastructure teams are simply rebranded as ‘Platform Teams’, ‘Cloud Infra’, or ‘Cloud X’—but little changes in how they operate. Tickets still pile up, cognitive load remains unmanaged, and no team truly owns outcomes.

In this fictionalised use case, drawn from multiple real-world engagements, we show how applying Team Topologies principles helped reshape responsibilities and interactions, redefining what platform enablement can truly mean.

This is not the story of one organisation, but a composite narrative built from real patterns and challenges. It applies to large enterprises, public or private with hybrid tech stacks and dependencies on internal infrastructure.

For the sake of this article, we’ll call the fictional organisation: ACMON Systems.

Organization Operating Context

ACMON SYSTEMS is a multi-faceted organisation offering services to both the public and industry partners. Its business model blends B2C and B2B offerings, placing high demands on both its customer-facing systems and internal technology landscape. The organisation runs on a hybrid stack: legacy virtual infrastructure, public cloud, and a private cloud estate (added primarily due to security and sovereignty concerns)

Historically, technology teams have been organised into vertical silos: Security, Networking, and Compute. These reflect a legacy that predates the modern software and cloud-native era. While adaptations have been made and led to pockets of agility, much of the structure remains unchanged.

When it comes to teams and platforms, there are critical components such as Identity and Access Management, as well as numerous internally labelled "platforms"—some modern, others inherited. However, the term “platform” is inconsistently applied.

In some cases, these are true service providers within the organisation; in others, they are technical stacks without clear service boundaries. This inconsistency contributes to a muddled operating model, complicated by legacy practices and made complex by modern demands.

ACMON Systems Challenges

Behind every challenge lies a set of roles affected—and often frustrated.

The following visual outlines ACMON Systems’ core challenges, it becomes apparent that these weren’t just technical challenges—they were organisational blockers affecting everyone from developers to the C-suite.

The following findings at ACMON Systems, while fictional, reflect patterns commonly encountered in large, complex organisations undergoing infrastructure and platform evolution.

1. Slow Time to Value - Provisioning infrastructure often takes far too long. This delay stems from a combination of internal dependencies, sequential handovers between siloed teams, and multiple layers of approvals. While these blockers may appear operational in nature, their impact extends well beyond individual teams. Delays in infrastructure provisioning create cascading effects across the organisation, slowing development cycles, increasing time-to-market, and undermining the ability to respond to business needs with agility. Ultimately, this bottleneck compromises the organisation’s capacity to deliver value at pace and scale.

2. Value flow & contribution - Internal teams often lack visibility into how their work contributes to value delivery, particularly in platform or support roles. This results in misalignment, unclear priorities, and reduced motivation across the organisation.

3. One-Size-Fits-All Processes - While infrastructure is a foundational enabler—especially in today’s context of Infrastructure as Code (IaC)—the surrounding processes at ACMON Systems have often been standardised without consideration for diverse user needs.

Whether it’s a developer building internal tools or a team deploying analytics pipelines, all must navigate the same rigid, inflexible path. This uniformity ignores context and intent, leading to frustration, delays, and wasted effort. It adds to cognitive load, as teams must interpret and work around processes that don’t align with their goals. The result is a degraded internal customer experience, reduced autonomy, and friction that ultimately weakens the value infrastructure is meant to support.

4. Organisational Silos and Inertia
ACMON Systems acknowledges the presence of silos—but recognises that dismantling them is far from straightforward. Shifting team responsibilities or rethinking how teams interact involves more than process redesign; it often requires unpicking deeply embedded structures and redistributing work across departments, time zones, and cultural boundaries.

This type of change is both complex and complicated: difficult to plan, highly interdependent, and inevitably impactful to people. It introduces uncertainty, triggers resistance, and demands careful change management. Without intentional support, these efforts stall—reinforcing inertia and making meaningful transformation even harder to achieve.

5. Shadow Infrastructure and Fragmentation
When internal infrastructure fails to meet delivery needs, some teams at ACMON Systems have taken matters into their own hands. In certain locations, public cloud services or third-party managed infrastructure have been procured using local departmental budgets.

The problem isn’t the use of local funds itself, but that these budgets were not designed or approved by Finance for ongoing operational spend—leading to blurred lines between CAPEX and OPEX. As a result, these shadow platforms operate outside formal organisational governance, frequently bypassing security, compliance, and cost management controls.

6. Broken Path from Dev to Prod - At ACMON Systems, shadow environments often begin as non-production sandboxes—and that, in itself, isn’t problematic. But when these environments evolve into business-critical applications, transitioning them into production becomes highly complex. The lack of integration with internal platforms turns what could have been a routine progression into a risky and time-consuming migration effort—one that could have been avoided with a more intentional starting point.

7. Security Risks and Misalignment - As ACMON’s infrastructure evolves—particularly with the shift toward hybrid environments and Infrastructure as Code—security practices don’t always keep pace. This isn’t necessarily due to outdated frameworks, but rather to gaps in integration, enforcement, and shared ownership. While security policies may exist, they’re not always consistently applied across different environments, especially during transitions from traditional infrastructure to cloud-native approaches. These inconsistencies create blind spots and expose the organisation to risk—not because security is disengaged, but because coordination across functions hasn’t evolved to match the speed and complexity of infrastructure change.

8. Stalled Innovation - Developers at ACMON Systems operate under various models: some are full-time employees, others are contracted through third parties and embedded in teams, while additional suppliers develop externally on ACMON’s infrastructure. Across these models, a common barrier to innovation emerges—not purely technical, but structural.

Infrastructure offerings remain rigid, often lacking modularity, self-service capabilities, or clear escalation paths. More critically, innovation is frequently constrained by how supplier and contractor relationships are defined. When flexibility, co-creation, or experimentation are not built into contracts from the outset, they rarely appear in practice.

ACMON risks locking itself into delivery models that stifle the very innovation it aims to foster.

9. Poor Operational Response - At ACMON Systems, infrastructure forms the foundation of many critical services, yet operational ownership remains fragmented. First-line responders—often the face of the service for users—are routinely expected to diagnose and triage issues that span multiple infrastructure domains. The organisation lacks clearly defined, service-aligned boundaries. In a service-oriented context, users interact with outcomes, not components, but internally, responders are left to navigate unclear delineations between infrastructure layers such as compute, network, storage, and platform tooling. This mismatch adds cognitive load, delays recovery, and erodes service reliability.

When boundaries are defined around technical silos rather than coherent services, operational response suffers—and the customer experience along with it.

10. Declining Service Competitiveness - The cumulative impact of the issues above is noticeably affecting service performance and market responsiveness. Despite significant investments—in areas like AI tooling, cloud credits, and private cloud infrastructure—ACMON Systems is struggling to realise meaningful returns (ROI). The technologies exist, but fragmented processes, unclear ownership, and organisational friction prevent them from being fully leveraged. As a result, costs continue to rise while value remains elusive.

Developer retention is also being affected, as talented staff face daily constraints that limit their ability to deliver, innovate, and grow—leading them to look at other organizations that enable them to contribute, learn and innovate.

Viewing Challenges Through a Team Topologies Lens

All the challenges described above point to deeper structural inefficiencies that, left unaddressed, put long-term services and their provision at risk.

To better understand and address the core challenges, a series of workshops were conducted with relevant stakeholders. These sessions had a dual purpose: first, to build a shared foundational understanding of Team Topologies concepts and principles; and second, to enable and empower participants to collaborate in surfacing pain points and examining them together through a Team Topologies lens.

This co-designed approach ensured that insights were grounded in real experience, and that solutions were shaped collectively—not imposed.

This approach revealed a much clearer picture of the impact on platform customers at ACMON Systems—specifically, the delays, friction, and inefficiencies experienced in how their needs are met, which teams are involved, and the overall time it takes to deliver value.

While deeper analysis is still underway, it quickly became evident that Team Topologies concepts—when applied alongside other complementary practices—enabled a structured and actionable way to design a more effective path forward.

The visual below illustrates some of the core needs identified during the workshops, the teams currently involved, and the pain points and constraints contributing to time-to-value delays.

Mapping Challenges to Solutions: How Team Topologies Shifts the Operating Model

Vision & Evolution for Platform Operation

Before anything could evolve, there needed to be clarity on what to evolve towards. Applying Team Topologies principles—alongside other complementary practices—helped crystallise a long-term vision which included not one but two platforms teams, one for infrastructure and one for Governance, Risk and compliance. (GRC)

The intent was for both to be treated as internal products, offering consistent yet adaptable services tailored to their consumers. The decision to elevate Governance, Risk, and Compliance into a platform in its own right was bold, demonstrating ambition, as well as an acknowledgment of the value such a platform could deliver if structured intentionally.

However, given the scale and complexity of ACMON Systems, it became clear that we needed to scale back, define scope, and prioritise deliberately. This required an intentional approach, one that would focus on what was truly needed now, enable effective prioritisation, and support iterative delivery. At the same time, it would begin laying the right foundations across technology, value propositions, people, team structures, and organisational alignment.

This led to the adoption of an Evolutionary Platform Operations (Platform Ops) approach and plan: a foundational shift toward “DevOps at the platform level”—designed to overcome the chronic pitfalls of traditional IT operations and enable continuous, adaptable service delivery.

The model emerged from a series of workshops with key stakeholders, where we co-created a realistic and context-aware roadmap. This roadmap addressed immediate needs while balancing technical implementation with the necessary cultural and structural shifts. Its focus extended far beyond tooling, emphasising team structure, ways of working, and purposeful team interactions as key levers for transformation.

Unlike project-based or ad hoc efforts, the envisioned platform teams are intentionally structured to evolve, scale, and adapt over time. Our infrastructure platform team will be first, designed to support both platform and non-platform development and operations teams, progressively enabling shared responsibilities and fostering more collaborative ways of working. The goal is to enable ongoing growth in key areas such as Infrastructure as Code (IaC), agility, and product thinking.

The first visual below outlines our immediate focus: the specific challenges and needs we are addressing now as part of our initial iteration. These are foundational steps—, measured and intentional— that lay the groundwork for future evolution without overreaching.

The second visual provides a forward-looking perspective. It illustrates what may come next: how additional platform teams might be introduced to further improve flow and capability. It reflects the ongoing, evolutionary nature of our approach, where each step builds upon the last to increase value, maturity, and alignment. We fully expect to revisit and potentially revise this plan over time—adapting it as new insights emerge and readiness grows.

Looking Ahead, as per our Evolutionary approach

As the platform continues to mature, the next phase focuses on revisiting and refining as the platform, its customers, and context evolve.

A key area of focus will be Governance, Risks and Compliance and its potential treatment ‘as a platform’ .

The Result of our work

The result: a platform team that doesn’t just support immediate needs, but one that grows in step with the organisation—adapting as the landscape evolves. It’s not about reaching a fixed endpoint but about building the capabilities and mindset to continuously respond, refine, and realign.

What is shared here is not a transformation that happened overnight but the deliberate act of strategising, crafting, and taking purposeful steps in the right direction.

This is the essence of Evolutionary Platform(s) Ops: acknowledging complexity, designing with intent, and progressing with clarity.

Each improvement unlocks new potential, not just for the platform team at hand but for the entire organisation they serve.

The next visual maps real challenges to actionable responses, showing how applying Team Topologies and complementary practices can lead to meaningful change. It’s a reminder that the path forward is built one step at a time, but only if those steps are taken with purpose.