Skip to content

· 13 min read

Team Topologies in practice: how we designed our payments team

Why I believe the shape of the teams defines the shape of the software, what Team Topologies proposes, and how we organized a payments team into a core line, a customer line and platforms.

The org chart is architecture too

In 1968, the programmer Melvin Conway wrote a sentence that became a law: any organization that designs a system ends up producing a design that copies its own communication structure.

In practice, it's easy to see. If three teams build a product, it tends to be born with three parts. The boundaries of the software sit where the teams talk the least, and the most confusing parts sit where nobody is quite sure who is responsible.

Conway's Law HOW THE TEAMS TALKHOW THE SOFTWARE TURNS OUT Team ATeam BTeam C B and C barely talk MIRRORS Module AModule BModule C the integration between B and C is the most fragile
Conway's Law: software inherits the boundaries, and the communication gaps, of the people who built it.

It's not just intuition

Conway's sentence started as an observation, but it was later tested. Two studies convinced me it describes something real.

The first is by Harvard researchers Alan MacCormack, Carliss Baldwin and John Rusnak. They compared pairs of software products that did the same thing, one built by a tightly integrated organization and the other by a distributed, loosely coupled community. In every pair, the product from the loosely coupled organization was much more modular. They called this the mirroring hypothesis.

The second is from Microsoft Research. Nachiappan Nagappan, Brendan Murphy and Victor Basili analyzed Windows Vista and measured the structure of the organization behind each part of the system: how many people touched it, from how many areas, how many had left. Those measures predicted which parts would fail better than the traditional technical metrics, such as code complexity and test coverage.

What the research says: The shape of the organization doesn't just influence the architecture: it can predict software quality better than the code itself.

For a long time I treated this as a curiosity. Today I treat it as a tool. If the design of the teams shapes the software, the logic can be inverted: first decide which architecture we want, then organize the teams so that it happens. The idea has a name, the inverse Conway maneuver, a term used by Jonny LeRoy and Matt Simons in 2010.

The book that organized all of this for me was Team Topologies, by Matthew Skelton and Manuel Pais. I believe strongly in the concept, and it was one of the foundations of the structure we have today.

The team comes first

The book's starting point is to treat the team, not the individual, as the unit of delivery. A stable team that works together for a long time learns how to understand each other, builds trust and gets faster. Assembling and dismantling groups for every project throws that learning away.

A few practical choices follow: small teams, of five to nine people; long-lived teams; and work going to the team, instead of people chasing the work.

None of this is new. In 1975, Fred Brooks showed in The Mythical Man-Month that adding people to a late project makes it later. The reason is mathematical: the number of possible conversations grows much faster than the number of people.

Brooks's math: possible conversations by group size 5 people10 possible conversations 9 people36 possible conversations 15 people105 possible conversations
Brooks's math: each extra person adds to the conversations a group needs to stay aligned.

The book also draws on the work of anthropologist Robin Dunbar on the size of the groups in which we can maintain real trust: around five people for the closest trust and fifteen for deep trust. It's the same logic as Amazon's "two-pizza teams": if two pizzas can't feed the team, it's too big.

Cognitive load: the limit nobody sees

The concept that most changed the way I think was cognitive load. A team can only take good care of a limited number of things. Past that limit, quality drops, deliveries slip and people wear out.

The concept comes from educational psychology. John Sweller proposed it in 1988 to explain why students get stuck on certain problems: working memory has a limit, and what doesn't fit in it isn't learned. Skelton and Pais took the idea from the student to the team, and split the load into three types:

  • Intrinsic: the effort of the work itself. Knowing how to program, knowing the language, understanding the tool.
  • Extraneous: the effort the environment imposes without creating value. A manual deploy full of steps, an environment that's hard to set up, an approval nobody knows whom to ask for.
  • Germane: the effort of understanding the business. In payments, it's knowing how a settlement works or what the regulator requires.

The goal is to reduce the intrinsic load with training and good technical choices, eliminate the extraneous load with automation and platforms, and leave room for the germane load, which is where the team really makes a difference.

Cognitive load of two teams OVERLOADED TEAMTEAM WITH A HEALTHY LOAD TEAM LIMITTEAM LIMIT four domains, two of them complexqueues, errors and tired peopleone complex domain and one simpleroom left to think and improve
Designing teams is distributing load. The book's rule of thumb: one complex domain per team, or two to three simple ones.

The four team types

Instead of inventing a kind of team for every need, the book proposes only four. Fewer types means less doubt about each one's role.

  • Stream-aligned: takes care of a slice of the business end to end and delivers straight to the customer. It's the main type, and most teams should be like this. The other three exist to help it.
  • Platform: offers internal services that are ready to use, so that other teams don't have to solve the same problem several times.
  • Enabling: specialists who help other teams learn something new, and then step away. Their success is no longer being needed.
  • Complicated subsystem: takes care of a part that requires very specific knowledge, which wouldn't make sense to spread across all teams.
The four team types VALUE STREAM → CUSTOMER Stream-aligned teamStream-aligned team Complicatedsubsystem EnablingteamPlatform team Most teams are stream-aligned. The others exist to reduce their load.
The four team types. Stream-aligned teams deliver value; enabling, complicated-subsystem and platform teams take weight off their shoulders.

Why is the stream-aligned team at the center of everything? Because it's the one that shortens the distance between an idea and the customer. The best evidence for this is in Accelerate, by Nicole Forsgren, Jez Humble and Gene Kim, which brings together years of research with thousands of organizations.

The book measures software delivery with four indicators: deployment frequency, lead time from code to production, time to recover from a failure and the rate of changes that go wrong. And it shows that one of the factors that best explain good performance is having loosely coupled architecture and teams: teams that can test and release their own work without depending on coordination with others.

What the research says: The teams that deliver well aren't the largest or the ones with the biggest budget. They're the ones that can change their own system without asking half the world for permission.

The three ways of interacting

Defining the teams is only half the work. The other half is defining how they talk to each other, and the book is economical here too: there are only three modes.

  • Collaboration: two teams work together for a period to discover something new. It's the richest mode and the most expensive, because the boundaries get blurred. It should have an end date.
  • X-as-a-Service: one team consumes what the other provides, with minimal conversation. It works when the interface is clear and the service is reliable.
  • Facilitating: one team helps the other learn or unblock something, without doing the work for it.
The three interaction modes COLLABORATIONX-AS-A-SERVICEFACILITATING work together, for a settime, to discoverclear interface,little talkone team helps the otherevolve, then leaves consumesprovideslearns
The three interaction modes. Knowing which one applies to each relationship avoids too many meetings on one side and isolation on the other.

What I like most here is the clarity. When two teams clash, it's almost always because each one expected a different mode: one wanted to be served as a service and the other thought they were collaborating.

Where to cut: fracture planes

The hard question is where to make the cut. The book calls these natural dividing points fracture planes and suggests a few: the business domain, regulatory compliance, change cadence, risk, technology and the type of user.

The first one comes from Eric Evans's Domain-Driven Design: splitting the system into bounded contexts, areas of the business with their own language and rules. A well-bounded context is a good candidate to be a team's home.

In payments, two of these planes show up very strongly: regulatory compliance and change cadence. The main division of our team runs along them.

How our team design turned out

I lead a technology team in payments. Before showing the structure, an important note: it wasn't designed by one person. It was built by many hands, with product leadership and the technology leaders.

My role was to bring what I believed in, and Team Topologies was the main reference. But influence always came after listening. The people who know the customer journey and where the business wants to go are the product team, and a team design that ignores that organizes the technology well and the product badly.

Without going into company details, the structure has three parts.

The core line takes care of the payment itself: acquiring, Pix, boleto, banking and regulatory matters. It's where the money actually moves and where the industry's rules weigh the most. A mistake here is expensive, so these teams need depth and stability.

The customer line takes care of how the customer gets to the payment: app and channels, devices (the card machines, POS and SmartPOS) and the payment link, which is digital, card-not-present payment. What matters here is the experience and the speed to test, learn and adjust.

The platform teams support both lines: infrastructure, DevEx (developer experience) and data.

The team structure: customer line, core line and platforms Customer lineCore linePlatforms stream-aligned · fast pace, focus on the experiencethe payment itself · careful pace, regulatory weightwhat makes autonomy possible App and channelsDevices (POS and SmartPOS)Payment link AcquiringPixBoletoBankingRegulatory InfrastructureDevExData CONSUMES AS A SERVICESUPPORT BOTH LINES
The team structure: two product lines, with different paces, on top of a base of platforms.

Reading it through the book's lens:

  • The customer-line teams are stream-aligned. Each one owns a clear piece of the customer journey and can take an idea all the way to production.
  • The core line is also aligned to streams, only they're payment product streams. For the customer line, it works as a platform: whoever builds the app or the card machine doesn't need to know settlement rules to offer Pix.
  • Infrastructure, DevEx and data are platforms in the classic sense. DevEx also has a foot in the enabling role: part of the job is teaching teams to make good use of what exists.

Why separate core from customer

The split resolves a conflict every payments team knows. The core asks for care: small changes, lots of testing, respect for the regulator. The customer edge asks for speed: experiment, measure, change again.

Two paces of change Customer lineCore line many small deliveries: test, measure, adjustfewer deliveries, each with more validation
Two paces of change. When they live in the same team, one gets in the other's way.

When the two paces live in the same team, one gets in the other's way. Either the experience gets slow because it inherits the rigor of the core, or the core gets fragile because it inherits the rush of the edge.

With the two lines, each team carries only what it needs to carry. Whoever looks after the app doesn't need to hold acquiring rules in their head. Whoever looks after Pix doesn't need to follow every screen test. It's cognitive load distributed on purpose.

How the teams talk

The design only works if the way of interacting is as clear as the boxes.

Between the customer line and the core line, the mode we aim for is service: clear contracts, stable APIs and a minimum of meetings to get the basics done. If a customer team needs to book time with core for every feature, the boundary is in the wrong place or the interface is poor.

When something truly new comes up, a product or a regulatory requirement that changes the journey, the mode becomes collaboration: the teams work together for a set time, until the interface is clear. Then they go back to service mode.

The interaction mode changes over time CollaborationX-as-a-Service something new: discover togetherstable interface: each team at its own pace THE INTERFACE BECAME CLEAR TIME →
The interaction mode changes over time. Collaboration that never ends is a sign the two teams should be one.

And platforms need to be treated as a product. The other teams are their customers. The definition the book adopts is Evan Bottcher's: a platform is a foundation of self-service APIs, tools, services, knowledge and support, arranged as a compelling internal product.

The important word is "compelling". The book argues for the thinnest viable platform: the minimum that solves the teams' problem, well documented and easy to use. A platform nobody wants to use isn't a platform, it's an obligation.

What I learned along the way

  • It's not an org chart. What matters isn't the boxes, but how much each team carries and how they talk. You can have the right design on paper and overloaded teams in practice.
  • The design isn't final. The business changes, products mature and the boundaries need to keep up. We revisit the structure as naturally as one revisits an architecture.
  • Autonomy depends on platform. Asking a team for autonomy without giving it ready infrastructure, tools and data just moves the weight around. That's why infrastructure, DevEx and data aren't support: they're what makes autonomy possible.
  • Team design is done with product. The boundary between teams is also the boundary between products. Deciding it from the technology side alone is half a decision.
  • Structure doesn't replace culture. The design helps, but people make it work. Ownership and collaboration, which I wrote about in another article, are what bring the boxes to life.

Where to start

For anyone who wants to apply the idea to their own team, the path I suggest is short:

  1. Draw the teams as they are today, not as the org chart says. Who depends on whom to deliver?
  2. Ask each team how much it carries. Systems, domains, on-call, demands from other teams. Overload usually shows up fast.
  3. Mark the dependencies that block. Where does one team wait for another to finish its own work?
  4. Pick one boundary to change, the one that hurts the most, and define its interaction mode.
  5. Review after a few months. A topology is something that evolves, not a project with a delivery date.

Closing

Team Topologies gave me vocabulary for something I already felt: most delivery problems aren't technical, they're boundary problems. Teams that carry too much, that depend too much on each other or that don't know how they're supposed to talk.

Designing the core line, the customer line and the platforms was our way of treating those boundaries as part of the architecture, and it only worked because product and technology designed it together. It isn't finished, and it isn't meant to be. But today, when something gets stuck, the first question I ask is no longer "what's the problem in the code?" but "what's the problem in the design?".

Sources