Organization-wide business agility in telecoms with Team Topologies at Telenet
How the Belgian telecom provider Telenet applied Team Topologies at enterprise level to increase business agility
Authors
Barbara Arnst (Transformation Tribe Lead)
João Rosa (Independent Consultant and Team Topologies Valued Practitioner)
Telenet, a Belgian telecom provider, began implementing agile at scale in 2019, when the company implemented an agile way of working based on the Spotify model.
By 2022, three years into that journey, the company had embraced agile and the benefits it brought in terms of transparency, collaboration, and customer focus. The agile way of working had become part of the company’s DNA. However, structural friction in the way the company was organized inhibited true business agility.
To overcome this, inspired by Team Topologies thinking, the firm revamped and reinvigorated its entire operating model empowering teams and optimizing for fast flow, thereby enabling business agility at all layers of the organization — not just within software development.
In this case study we take a detailed look first at how the new model was arrived at, and then how it is able to both eliminate friction and adapt as necessary to changing business and market conditions.
Telenet: a full-suite, multi-brand telecom player
Telenet offers a full range of products and services for consumers and businesses through a multi-brand strategy. The company employs around 3,300 people and — in common with all telcos — operates in a regulated environment.
The company recently underwent a strategic split between its NetCo (physical assets) and ServCo (services) organizations.
This case study focuses on ServCo. The ServCo is responsible for the development and commercialization of products in a dynamic market driven by intense competition, it particularly benefits from an operating model based on the principles of fast flow.
The Spotify model increased transparency but limited business agility
Telenet’s 2019 agile model had already brought clear benefits to the company. These include increased levels of transparency across former silos and a shift to developing products in smaller increments, using design thinking and Minimal Viable Products (MVPs).
However, the new model also brought to the surface some structural frictions that hampered business agility. For example, the many dependencies that existed between “autonomous” squads and tribes created bottlenecks when multiple teams needed to synchronize in order to release a feature (Figure 1). Over time, the cost of coordination across tribes and squads increased exponentially, resulting in ever higher cognitive load for teams.
By 2021, Telenet was doubling down on its ambitions to become a truly digital and data-first company, embracing technology powered by software and AI. From a consumer’s perspective, Telenet began to shift from a traditional model towards an always-on way of doing business, offering consumers personalized touch points across all steps of the customer journey, and seamlessly connecting the physical and digital worlds.
Given these ambitions, business agility mattered more than ever. But at times, the company felt the operating model was hindering rather than helping achieve the desired business outcomes.
Moving beyond agile to address fast flow and team cognitive load
Business agility demands an operating model that is designed to enable fast flow across all steps of the customer journey. The lack of flow in Telenet’s existing operating model was largely caused by business capabilities being spread across organizational boundaries. When differences in terms of priorities, approaches, or solutions arose, they almost always required a resolution at the C-level. This long decision chain inevitably resulted in slow decision making, and decisions were also being taken too far from where they were executed.
Recognising this, the executive group of Telenet envisioned a shift to a network-based organization, guided by a series of common principles.
In October 2021, the firm engaged with the authors of Team Topologies, who ran a series of group workshops around fast flow and team boundaries based on Team Topologies and Domain-Driven Design. These sessions laid the foundation for the future model by providing a fresh perspective on challenges such as dependencies, cognitive load, team responsibilities, and organizational capabilities.
Using Wardley Maps, Domain-Driven Design, and Team Topologies to devise a new fast-flow operating model
To start the journey, Telenet set up a small task force (consisting of a handful of senior Telenet executives and one external consultant) to investigate how the principles of Team Topologies and Domain-Driven Design could be applied holistically.
The idea was to make use of existing internal knowledge rather than adopting a pre-baked model from an external party — as Telenet had already learned, each organization is unique and an operational model cannot be copied wholesale from one to another!
This task force set up several workshops with different parts of the organization to understand in depth the company’s unique challenges as well as potential solutions.
They validated initial observations using a concrete use case in the eCommerce space, an area of the organization where the aforementioned friction was especially prominent.
The team used EventStorming and other visual collaboration techniques to map the current software architecture across the different value streams. Through these visualizations, the core team developed a series of Wardley Maps and started to extract the key business capabilities and understand how these were implemented across the organization.
Figure 1 - Representation of the major blocks of the organization structure illustrating the many dependencies across teams
It became clear that the domain boundaries (in a Domain-Driven Design sense) were not set around the business capabilities but rather around tasks and functional specializations. The eCommerce area alone involved nine teams, each with responsibility for a part of the flow of value. Any feature — however small — reaching production would entail multiple handoffs between the different teams.
These high coordination costs had a dramatic impact on both the speed and quality of the delivery. Furthermore, these teams were scattered across the business, digital and IT domains (Figure 1), meaning priorities were not always aligned. Furthermore, in an attempt to reduce the coordination costs, delivery teams would try and squeeze as many changes as possible into a single software release. This further impeded agility, and even though the business stakeholders wanted to move faster, the organization structure and resulting team behavior started to work against them.
As the task force looked towards solutions, they developed a series of organization building blocks designed around the principles of fast flow, team cognitive load and continuous learning.
These building blocks were initially conceptualized at the enterprise level. The belief was that these networks of teams would remove the structural organizational frictions that had started to impede business agility. In Telenet terminology, these teams-of-team domains were called “tribe archetypes” and typically consisted of 10-15 teams:
A customer tribe archetype is a team-of-teams organized to work towards a single customer mission, with clearly defined accountabilities and customer outputs. Such a tribe is enabled and empowered with all the means (people and capabilities) necessary to achieve its mission. The tribe takes ownership of the full lifecycle of all the products within its scope, ultimately spanning the full DevOps cycle and embodying the principle “You break it, you fix it”. In that sense, each customer tribe operates as a micro-enterprise, taking full accountability for all assets and outputs within its scope.
Platform tribes archetype is a team-of-teams organized to design, build, and manage a common platform, primarily used by internal customers — each a business within a business. The platform could be technical (e.g. data, cloud) or operational/service (e.g. retail) oriented. The platform tribes’ mission is to allow customer tribes to be autonomous and productive, as they provide and care for any external dependencies. Customer tribes pull the services on offer (rather than pushing requirements), allowing smarter amortization and reuse of common assets across different business lines.
Lastly, a set of enterprise tribes archetypes would drive horizontal collaboration and alignment across the loosely coupled business and platform tribes. These enterprise tribes help orchestrate the funding and alignment of the strategic backlog of the company across both the tribes and different time horizons.
Figure 2 - Conceptualization of the generic enterprise-level building blocks
Following the theoretical application of the eCommerce use case within these tribe building blocks, the task force realized that to be fully effective, the enterprise at large would need to adopt them. So the question emerged: “How could the model be scaled to the whole organization, rather than just one area?”
Modular organization architecture with empowered, autonomous tribes
Armed with their previous experience, the task force explored what building blocks would be needed for the operating model of the organization as a whole. They identified around five customer domains (think of these roughly as different business areas), around 15 supporting (technology) platforms (including things like: data, cloud infra but also finance and customer communication), and around five enterprise tribes (Human Resources, Transformation, Enterprise Architecture etc.). These generic tribe archetypes accounted for all the customer journey outputs the organization had to take into account, but were still agnostic in terms of customer segments, brands, and platforms.
Once Telenet’s leadership endorsed the generic building blocks, the task force approached the next phase: designing the high-level enterprise blueprint. This blueprint would take into account the different brands, segments, and platform realities.
As noted already, a core design principle was to empower the new tribes with all the capabilities to execute their mission — including business, IT development and operations. To embrace this, the task force used Domain-Driven Design techniques to draw both the system and business boundaries between the tribes, thereby creating a loosely coupled architecture at the enterprise level.
Having a modular architecture based on tribe patterns would allow Telenet to split, add, or merge tribes, depending on the evolving strategic goals. And all this without having to redesign the entire enterprise architecture!
Figure 3 - Representation of the generic tribe archetypes at scale. Each circle represents the C-level responsibilities, where each person is responsible for a mix of different tribes archetypes
Making it real: fast flow of value, team cognitive load, and Dunbar’s number
After the task force defined the enterprise-level blueprint, the tribe leaders could start the detailed design of their team-of-teams structures. To enable meaningful change, it is key to involve and engage the broader community that is actually doing the work rather than having design take place in an ivory tower.
At this point therefore, the role of the task force shifted from operating-model architects to operating-model guides, facilitating the design process for the tribe leaders and their communities. The operating-model principles laid out to define the tribe archetypes provided the necessary guidance to keep everyone aligned on the ultimate goal during this detailed design phase.
The three principal tenets of the Team Topologies book also remained core: fast flow of value, team cognitive load, and Dunbar’s number (which postulates that each person can only maintain about 150 stable social relationships).
Finally, the team-level pattern thinking that is central to Team Topologies was also adopted. The patterns empowered the tribe leads and their teams to design each tribe’s team-of-team structure in a bottom-up way, suited to its unique context.
Figure 4 - Customer tribes typically have a mix of internal platform teams and stream-aligned teams who deliver the Tribe’s customer outputs
The key difference from the earlier Spotify-inspired approach was that the tribes were now designed to encapsulate core business capabilities, rather than having these dispersed across the organization. This meant tribe leaders could actually design a team-of-teams structure that enabled a meaningful flow of value.
The Billing Experience Tribe, for example, owns all the systems and applications necessary to perform all billing activities. The tribe doesn’t just run the billing systems, the teams within it also define and optimize the billing experience, and identify (and build) game-changing innovations in the broader billing space. To execute this broad mission, the Billing Experience Tribe comprises around 150 employees across 15 different teams.
Within the tribe, all four Team Topologies team patterns are applied. There are billing-platform teams whose platform is consumed by various stream aligned, billing-product teams. The stream-aligned teams deliver customer outputs but also continuously share learning insights to the platform teams within the tribe. With this closed-loop cycle, the tribe can act much faster on improvements.
Of course, the Billing Experience Tribe is not an island and it does not operate in full isolation. In a complex telecom environment; there are still interdependencies with other tribes, such as with the tribe responsible for the website that hosts the billing self-service features. These platform tribes are organized as independent service providers. But whereas previously such interdependencies caused high cognitive load, they now follow Team Topology logic and are managed as an interface defined by clearly articulated Team APIs. Finally, the pattern approach lends itself well to Dynamic Reteaming. The Billing Experience Tribe knew its initial tribe design was just a first cut to be finetuned and optimized, but they could now refine it without painful reorganizations spanning C-level boundaries.
Figure 5: Example of a Customer tribe collaborating with other Customer tribes on overarching missions and consuming the services offered by the Platform tribes
In a model where software ownership is widely federated across the organization, setting up these teams with the right transversal accountability is key. Team Topologies, and in particular the enabling and complicated system-team types, provided the right mental model to design for this.
The multitude of service tribes were designed using the same Team Topologies patterns and principles we just looked at. Many Platform tribes are responsible for providing support to tribes with business capabilities — either from an IT or business perspective. Examples include the marketing communication platform used by the commercial teams within a brand or market segment; also the common IT capabilities, such as the testing guardrails, CI/CD tooling and runtime factory (either datacenter or cloud).
Whereas most customer tribes had significant development capabilities within their scope, a lot of Platform tribes or enterprise tribes did not. The Team Topologies patterns also proved useful: a design with logic based on X-as-a-service, flow of work, or flow of resources allowed these teams to draft meaningful team charters. Clear Team APIs and work approaches allowed these teams to better manage cognitive load and reduce coordination costs.
Think holistically for whole-organization change with Team Topologies
Telenet’s new operating model covered the whole organization, not just the parts of the business related to software development. Right from the start, the task force explored how the same team archetypes and concepts as well as the deliberate approaches to designing tribes for flow could apply in non-software contexts, such as Human Resources or Finance. This was important, as the objective of the operating-model revamp was to create a new mental model that the whole organization could rally behind.
A second important lesson is that the redesign was only the start. With the new operating model, Telenet has created a better context for teams to work in, but also made it easier to continually adapt to a changing context.
The key to true business agility at Telenet was the careful combination of several practices and principles:
using the team types and team interaction modes from Team Topologies together with the core principles of fast flow, limiting team cognitive load, and explicitly considering group trust boundaries;
aligning teams and tribes to business domains using Domain-Driven-Design principles and practices;
using an internal and well-informed task force to establish operating principles for empowering teams and tribes who could use the Team Topologies patterns to sense and adjust boundaries for flow; and
extending and scaling all these principles and practices outside of IT/engineering so that the model can act as an objective for all of Telenet’s employees and its partners.
As with any large-scale organizational transformation, executive buy-in and ongoing support was also key. The new operating model is already working well for the company, and, as Telenet CEO John Porter emphasizes, is able to adapt rapidly as the market and requirements change. “Our tribes and teams are equipped to keep sensing the health of their team boundaries, and to fluidly adapt where their context requires it,” he told us. “Empowering the entire organization to do just that, in a safe way, is a key principle of the transformation approach. It is what we believe will lead to sustained success of the model.”
Note: At the time of the Telenet engagement, João was employed by Xebia, a Dutch consultancy firm.
