Team Topologies: Organizing Business and Technology Teams for Fast Flow

by Matthew Skelton

This balance is hard to achieve both in an open-plan layout (no dedicated work area for the team) and in an individual-workspaces layout (time together needs to be planned ahead of time and meeting rooms are often scarce).

When our new home, “The Codeworks,” was built, we thought long and hard about what the layout of the development areas should be.

We liked the team space our old building gave us, but we needed less isolation of teams, and we had the usual physical numbers and space constraints.

For example, the bank ING Netherlands explicitly redesigned its office space as part of a major organizational change around 2015 to align teams to value streams.33 At ING, several stream-aligned “squads” working on similar products and services within a stream form a “tribe.”

In their 2012 book Make Space, Scott Doorley and Scott Witthoft present many other creative ideas for arranging physical space in ways that ignite creativity and useful team interactions.35

Back in 2013, as we started to move from a print-based business with many different offices around the country to a 100% digital business, we began to look at ways we could improve collaboration and optimize for the flow of work. We reorganized from fifteen offices into three, with our main office in Manchester, UK, on only two floors. The working environment was created to be as open plan as possible, with all senior managers sitting with their teams and no private offices. This made it much easier for people to communicate with each other, and we finally started bridging the gap between “the business” and IT.

We have found that you start seeing things from other people’s viewpoints when you sit with them.

Successful organizations—from the US military to corporations large and small—treat the team as the fundamental means of getting work done.

Teams are generally small, stable, and long lived, allowing team members the time and space to develop their working patterns and team dynamics.

Today, the prevailing way to set up or reorganize teams is ad hoc, focused on immediate needs rather than the ability to adapt in the long run.

In order to be as effective as possible, we need to consciously design our teams rather than merely allow them to form accidentally or haphazardly.

The first anti-pattern is ad hoc team design.

Of course, all of these situations should trigger some action, but without considering the broader context of the interrelationships between teams, what seems like a natural solution might slow down delivery and eat away at the autonomy of teams.

A computer will perform the same whether it is placed in Room A or Room B, but an engineer placed on Team A may perform very differently than if placed on Team B.

Given our skills, constraints, cultural and engineering maturity, desired software architecture, and business goals, which team topology will help us deliver results faster and safer?

Line management also happens via chapters, but the line manager (the chapter lead) is also part of the day-to-day work of a squad, not an aloof manager.

It is essential that organizations take into account more than a static placement of people when looking at the design of team interactions.

In Accelerate, Nicole Forsgren, Jez Humble, and Gene Kim collected data on the software-development practices of hundreds of organizations around the world, which led them to conclude that “we must . . . ensure delivery teams are cross-functional, with all the skills necessary to design, develop, test, deploy, and operate the system on the same team.”5 Organizations that value information feedback from live (production) systems can not only improve their software more rapidly but also develop a heightened responsiveness to customers and users. This superior “sensing” ability

If the team does not have a high degree of engineering maturity, they might take shortcuts, such as not automating tests for new user workflows or not following the “boy-scout rule” (leaving the code better than they found it). Over

These can be consumed independently by the product teams when they need them.

The four fundamental team topologies—stream aligned, enabling, complicated subsystem, and platform—should act as “magnets” for all team types.

This is akin to the idea of “servant leadership” but applied to team interactions rather than individuals.

Case Study: Engineering Enablement Team within a Large Legal Organization

This approach has been successfully adopted in many internet-era organizations.

“Ease of use” is fundamental for platform adoption and reflects the fact that platform teams must treat the services they offer as products that are reliable, usable, and fit for purpose, regardless of if they are consumed by internal or external customers.

Dev was working to serve the “boss” of product management rather than users of the services.

“The most important part of the platform is that it is built for developers.”21

There should be a way to give feedback to platform developers and how the platform is doing in general.

Every software application and every software service is built on a platform.

retired. Therefore, in order to help the Dev team users to be as effective as possible, we need to: (1) treat the platform as a live/production system, with any downtime planned and managed, and (2) use software-product-management and service-management techniques.

define the hours of operation, define the response time for incidents and support, ensure we have an on-call rota to support the platform, manage incidents and unplanned downtime with suitable communication channels (such as service status pages),

and so on.

The user personas will help the platform team to empathize with the needs, frustrations, and goals of typical users of the platform.

Stream-aligned teams can expect to have cognitive load matched to their capabilities through the support and help they get from enabling teams, platform teams, and complicated-subsystem teams.

Converting an infrastructure team into a platform team enables rapid, safe flow of change both within the platform and—crucially—within stream-aligned teams.

The change from infrastructure team to platform team is not simple or straightforward, because a platform is managed as a product using proven software development techniques that may be quite unfamiliar to infrastructure people.

Component Teams to Platform or Other Team Types

Tooling teams are typically better run either as enabling teams—with a short-lived and highly focused remit—or as part of the platform (with a clear, well-informed roadmap).

In this model, if dedicated support teams are needed, they are aligned to the stream of change, alongside a team or squad building the software systems.

However, many organizations experience huge problems with the responsibility boundaries assigned to teams.

A Team-First Approach to Software Responsibilities and Boundaries

A joined-at-the-database monolith is composed of several applications or services, all coupled to the same database schema, making them difficult to change, test, and deploy separately.

Monolithic thinking is “one size fits all” thinking for teams that leads to unnecessary restrictions on technology and implementation approaches between teams.

In this way, an organization can leverage Conway’s law and align the system architecture with the communication constraints in real life.

For instance, a multi-tier SaaS product might have millions of users in its free tier and only a few hundred customers in the paying tiers.

We put DevOps and continuous delivery practices at the center of our design choices and started transitioning to a microservices-type architecture from our existing (successful) monolithic system.

by Conway’s law, so making sure that we had effective domain separation was crucial.

By adopting cross-functional product teams with what we call “aligned autonomy” we have seen good ownership of software services within teams, which in turn enables us to have a fast flow of change while minimizing downtime.

Figure 6.1: Mobile, Cloud, and IoT Technology Fracture Plane Scenario With three very disparate technologies (mobile, cloud, and IoT), an organization must decide on an approach to fracture planes that makes sense based on the cognitive load and the change cadence in each area.

The team topologies used should adapt and evolve to meet emerging challenges, while still retaining the key team-focused and architectural considerations encountered in Part I.