This article is part of a series on the concept of a Platform Organization. Check out the first installment on the evolution toward the platform org, and the second one on choosing pilots.

Introduction

Organizations are made of teams and units and how to structure them has been a focus of management theory for decades. Countless frameworks have focused on team structures and interactions, acknowledging W. Edwards Deming once expressed so clearly by saying:

“A company could put a top man at every position and be swallowed by a competitor with people only half as good, but who are working together.”

Deming’s point could be summarized more widely by saying that the performance of a system – such as an organization – largely depends on how well the parts fit together, not how well they perform individually.

---

Understanding the recurring team types an organization needs and how they should communicate has become a top business challenge. This is due to the need to adapt to fast market changes and build adaptive organizations, able to distribute autonomy and overcome bureaucratic top-down management practices.

Despite originating from agile software development, the Team Topologies metamodel has achieved tremendous success in recent years. It was introduced in the book “Team Topologies: Organizing Business and Technology Teams for Fast Flow,” by Matthew Skelton and Manuel Pais.

This approach lists four team types and elucidates their interaction modes. It’s a useful guide on structuring teams and interactions to build and deliver software products efficiently and adaptively.

These four team types are:

• Stream-aligned teams: aligned to a flow of work from (usually) a segment of the business domain, like a group of product features or a small product.
• Platform teams: a team (or grouping of teams) that provides a compelling internal product to accelerate delivery by Stream-aligned teams – for example, an authentication or identity service;
• Enabling teams: that help Stream-aligned teams to overcome obstacles, detect missing capabilities, and generally reduce cognitive load by providing coaching or domain-specific expertise;
• Complicated Subsystem teams: build and maintain systems requiring heavy specialist knowledge.

The interaction between SA teams (that build customer-facing elements), Platform Teams, and Complicated Subsystem teams delivers a product value proposition to the market and customers.

The Team Topologies metamodel also proposes to limit “interaction types” between teams to three major ones, aside from the team types:

• Collaboration: a temporary exchange with all teams equally contributing. This can account for co-creative innovation, knowledge, and skill sharing;
• X-as-a-Service (XaaS): An interaction pattern where one team provides something as a service to another – for example, through an API. Here, responsibilities and expectations are clearly defined;
• Facilitating: i.e. the typical interaction happening between enabling teams and Stream-Aligned – where one team assists another in advancing their capabilities to reach self-sufficiency. This removes long-term dependencies and allows for autonomy among teams.

Many software-centric organizations (a lot these days) that are grappling with rapid changes and need consistent performance end up with numerous teams and unclear roles and responsibilities. Consequently, many have adopted the Team Topologies metamodel – or derived approaches – to derive benefits.

 

 

According to Team Topologies, the main outcomes of adopting such a team discipline are:

• a reduced Cognitive Load on teams thanks to well-defined, manageable work scopes that reduce the stress of having to figure out your role in system-wide complexity;
• an optimized structure to achieve Fast Flow thanks to clear interaction models ensuring smoother, quicker workflow and faster feedback;
• enhanced collaboration because clear interaction modes and defined responsibilities give teams a better understanding of when and how to collaborate, creating a learning environment for ongoing improvement.

Unsurprisingly, the Team Topologies approach has inspired companies to adopt similar patterns beyond pure software development, in search of the promised benefits.

To what extent is the idea of adopting a number of recurring team types and predefined interaction models applicable beyond software? In principle, it seems plausible that any organization could benefit from the implementation of a similar framework. At the end of the day, certain teams will be focused on delivering specific elements of a value proposition (stream-aligned), while others can be focused on supporting with services or enabling with competencies.

We hinted in a previous article that explored evolutions towards product-centric organizations that the shape of the particular team topology that your company could adopt heavily depends on the product and business model you’re delivering to the market and on your strategic focus. The archetypes of Stream-aligned teams, platform teams, and enabling teams hold extraordinarily well in different contexts. For example, the Dutch healthcare company Buurtzorg is, to some extent, characterized by similar archetypes with stream-aligned teams of nurses, supported by coaches (enabling) and using a particular software platform.

While software companies have unique needs, like the need for long-term stream-aligned teams (which usually have ownership of a feature group or product) others may have different ones.

For example, you may want your teams to be assigned to a certain workspaces for shorter times in different contexts. For example, in a consulting company, you may want your stream-aligned consulting teams learn from many verticals. In such a case, you may want to push them to work on different projects and different industries.

Overall, we can conclude that adopting a team topology at your company may reduce cognitive load, enhance collaboration, and achieve better agility. The archetypes provided by the Team Topologies approach may be a good starting point.

As Martin Fowler said once:

“George Box neatly quipped: “all models are wrong, some are useful”. Thus Team Topologies is wrong: complex organizations cannot be simply broken down into just four kinds of teams and three kinds of interactions. But constraints like this are what makes a model useful. Team Topologies is a tool that impels people to evolve their organization into a more effective way of operating, one that allows stream-aligned teams to maximize their flow by lightening their cognitive load.”

---

From Team to Unit Topologies

In parallel to defining team types and interactions, in the last few years there has been a convergence towards thinking of organizations as platform-powered ecosystems of independent product units – a sort of “common protocol of organizing”.

In such models, the organization is often dubbed as “product-centric” or “platform-organization”. It is made of autonomous, swarming, and collaborating customer-facing units often called “Micro-Enterprises”, powered by shared services. This is what we call a 3EO (an Entrepreneurial and Ecosystem-Enabling Organization) at Boundaryless – a framework that we formalized through our partnership with Haier Group and inspired by their “Rendanheyi” model.

We argue that the evolution from functional to divisional, matrix, and then platform model is a natural consequence of organizational evolution. As we explained before:

“Adopting a platform organizational model right now offers compelling advantages, given the current nature and evolution of markets. Today’s market landscape demands agility, responsiveness, and the capacity to continuously innovate while leveraging digital capabilities to create new products and services.

The Platform organization model emphasizes the product/service as the most vital element: small units produce a particular product or service, while internal platforms specialize in enabling services for internal units and sometimes third parties.

By creating clear, actionable interfaces, the platform organization is structured to easily integrate with external – not just internal – contributors, something that is vital to align with the growing importance of business ecosystems: often, the birth of an internal enabling platform is subsequently externalized to cater for the birth of a third-party ecosystem of partners.”

Our framework provides something we could call a “unit topology” based on three fundamental unit types and three fundamental interaction modes between them.

These three unit types are defined as follows:

• Micro-Enterprises (ME): these are autonomous organizational units that are focused on producing a complete value proposition serving either an external customer (so-called “user MEs) or another unit (so-called “node-MEs”) in a B2B mode;
• Shared Services Platforms (SSP): these are organizational units missionized to provide enabling services of all kinds that have the characteristic of being appealing to all MEs (a good example could be F&A);
• Industry Platforms (IP): organizational elements focused on investing capital across the portfolio of options – continuously seeding new MEs – to increase diversity and support entrepreneurial employees.

In this platform organization, MEs and SSPs are evolutions of organizational “divisions”, and run their own Profit and Loss statements. They are mini-organizations within the larger system.

These unit types interact based on three patterns, either multi-party contracts or org-wide agreements:

• Service Provisioning Contracts/Agreements: the typical relationship between MEs and Shared Services Platforms, this type of collaboration can take different shapes depending on the context, some companies prefer to “tax” all their units’ revenues to pay for shared services – in a pattern that would be similar to that of citizens paying taxes to states to receive basic services – while others push for continuous point-to-point negotiations between the SSPs and the MEs;
• EMC or Ecosystem Micro Community Contract: i.e. multi-party contracts that often includes external partners and dictates how units collaborate to create a more complex market outcome or customer scenario that requires a multi-unit/product collaboration and all parties to do their best. In this case, the market outcomes can be connected to how the earnings and results of the collaboration are distributed to the various parties;
• VAM or Value Adjustment Mechanism Contracts: i.e. an investment contract through which capital allocation units (normally the IPs) invest in new or existing MEs and – more rarely – SSPs negotiate resource allocation that would lead to certain market objectives. Once unlocked – such outcomes impact how much the wealth of the ME is transferred to the ME owners and employees. This can take the form of salary enhancements, independence in managing the unit’s revenues, or assignment of the unit’s virtual or real equity (in case the ME is a separated legal entity).

 

 

 

As we explained in a piece titled “The Key Promises of Organizational Unbundling“, transitioning to a platform organization model can provide huge benefits. In this model, the organization is “unbundled” into the unit topology explained above (specifically the adoption of P&L bearing MEs and SSPs). These benefits include:

• reduced organizational brittleness as a consequence of a lighter integration across silos;
• reduced Time to Market and distance to the customer as a consequence of having all units focused on serving their customers more tightly;
• enhanced offering coherence especially if organizational unbundling is coupled with the creation of a portfolio strategy;
• an optimized cost structure due to the economies of scale that can be generated through the adoption of common Shared Services Platforms.

In a platform organization, one can also expect much higher employee engagement, attraction & retention due to the deeper responsibilities that operators at the edge of the organizations have to “run their own business”. This can catalyze stronger innovation capabilities.

---

The Platform Portfolio Deep Dive is a 1-Day Experience designed for executives and builders who want to learn how to manage an ecosystem of several products and services. Join us in Barcelona for the first Live Edition.

 

---

Mixing and integrating everything

In this article, we wanted to explain why adopting both a team topology and a unit topology may be useful for organizations seeking the benefits these approaches promise.

To understand why the two things work well in a mix, let’s quickly look at the organizational context. Let’s assume we are looking to adopt a platform-organization (3EO) model. Our organization will be interacting with a larger market and will be “made of” units. Such units will be mainly focused on providing a certain product/service (either internally or externally focused).

The context of the single units will be where we’ll possibly apply Profit & Loss responsibility, for entrepreneurial motivation, cost control, or both.

Such units may start small, especially if we’re incubating new ones instead of “unbundling” an existing large organization into smaller elements, but typically grow as they become more successful. As a consequence of growth, the number of teams inside a Micro-Enterprise will grow as the product grows its customer base and revenues.

We can identify at least four layers in the organizational context and scopes of interactions:

• inside a single team
• between teams inside a product unit (and potentially between units)
• between the Micro-Enterprises (nodes, units) in the organization (and potentially between organizations)
• among different organizations

 

 

These “layers” lead to a series of “interfaces,” like the one between teams (in a unit) and units (in an organization).

Teams within units could be interchanged or collaborate, and units between organizations can partner to achieve ambitious plans through partnerships. Organizations are also of course keen to partner and trade services and products.

Adopting a team topology inside our organizational units would create the benefits mentioned above (reduction of cognitive load, and flow…). So, an organizational developer should look to create a team topology, not limiting it to the team types that existing frameworks provide, but rather creating its own. This recognizes that each business model and product specificities call for a different team topology. In an interpretation of Conway’s Law, we could say that you ship your team topology and thus your team topology should be influenced by the product/service the unit is providing.

In an organization with different products, each product-focused Micro-Enterprise should probably have a slightly different team topology.

Most likely, product units (MEs) will have some sort of stream-aligned team type related to the type of business they’re running and a series of platform and enabling teams. As an example, while in a software development unit:

• the stream-aligned teams may be managing a particular feature group or macro-function of the software product;
• the platform teams may be providing cross-feature functions (authentication, data management…);
• and an enabling team may deal with adopting new tools and techniques.

In a consulting Micro-Entrepreneurial unit:

• the stream-aligned team may be set to be a team capable of delivering a certain part of the consulting offer;
• a platform team may provide some ultra-specialized consulting capability or training services;
• and an enabling team may be providing travel arrangements.

As micro-entrepreneurial units grow, Stream-Aligned teams will diversify and acquire certain recurring types that may be useful to track. Recognizing them can optimize hiring, skilling, and tooling for the teams.

 

 

All MEs should also likely have one team type specialized to be in charge of go-to-market. We advise organizations to empower their MEs to reach the market autonomously in order to respect the principles of letting autonomous units create their own success.

However, it’s also true – as we explained recently in Responding to Multiple Customer Needs with Products and Services – that creating shared, org-wide go-to-market processes can provide a potential coherence pattern for companies. These processes can complement, integrate, or in some cases substitute the embedded go-to-market capabilities in the units. This is important for companies concerned with exposing a coherent brand and sales motion, for example, to avoid proposing sub-optimal solutions to customers.

In this case, the shared GTM process can be powered by product taxonomies that can help compose bundles and upsell, by promoting the whole set of organizational capabilities. This process is a delicate and important element to design and ponder in a multi-product organization model.

 

 

Conclusions and Further Works

In this article, we’ve explained the differences between unit and team topology. We’ve also explained why modern platform organizations adopting the two can provide benefits in team experience – such as reduced cognitive load and flow – and organizational success – such as innovation, market success, reduced organizational brittleness, broader optionality, and more.

Despite past confusion and overlap, we provided a clear approach to applying both concepts, rooted in our first-hand experience with Fortune 500s, fast-growing companies, and scaleups. Given the pioneering nature of such frameworks, we believe this overview can help you navigate this complexity.

As organizations grow more complex, the need for coordination and strategy beyond operations emerges. The strategy process must consider the whole system and learn from the market environment.

In addition to team and unit structure, a modern organization will need to create a capability to strategically and collectively look at product-units development. It will also needs coordination capabilities that help avoid resource overbooking and planning capability to be able to commit to customers and partners.

In the coming weeks, we’ll release more articles in this series explaining how we use the approaches explained today in combination with:

• tools and processes such as Wardley Maps and Ecosystem Maps to develop a collective Portfolio strategy;
• frameworks such as the Viable System Model and Flight Levels to develop control, intelligence, and planning capabilities across the various levels of the organization.

Furthermore, we’re passionate about thinking beyond the organizational boundaries at Boundaryless. Soon, we’ll publish further updates about how our work with organizations is leading to ecosystemic partnerships and inter-organization collaborations, extending teams’ reach beyond the single organization.