Team Topologies: the book that helps FDE teams find their place between product and platform

Docker has written about reorganising its engineering teams using Team Topologies, and the post contains a sentence rarely seen on a corporate blog: the first attempt did not reduce cognitive load. They had to do it again.

That detail carries more weight than any endorsement. The book by Matthew Skelton and Manuel Pais is not a recipe that works as soon as you apply it. It is a vocabulary for describing where each team stands and how teams touch one another.

For FDEs, that vocabulary is exactly what is needed. You sit between the customer, sales and the product team, so every time a request from the field gets stuck between the three, you need to say clearly who does what, for how long, and when it stops.

Which edition to read, and in what order?

The first edition, Team Topologies: Organizing Business and Technology Teams for Fast Flow, was published by IT Revolution Press on 7 September 2019 and runs to 240 pages. The whole approach revolves around four fundamental team types and three modes of interaction between teams.

The second edition came out on 23 September 2025 at 304 pages, with a new subtitle: Organizing Business and Technology for Fast Flow of Value. The publisher treats the team as the fundamental unit for delivering value, and still describes the book as a major step forward in organisational design for IT and knowledge work.

Read in this order: first the Key Concepts page on teamtopologies.com, because it is short and contains all the definitions. Then the second edition. Finally, set the book alongside PostHog’s public FDE handbook to see where a real company places its FDE team.

Idea one: overloaded teams make bad decisions

The main reason to split teams, according to the book, is cognitive load. The Key Concepts page puts it neatly: an overloaded CPU slows a computer down; an overloaded team makes poor decisions and moves slowly.

Picture a four-person FDE team serving six customers, each with its own stack. Every quick fix in the field becomes something the team has to keep in its head from then on. By the seventh customer, the team is not short of skills. It has simply run out of headroom.

The first thing to do at a customer: list everything the team is maintaining on its own, such as connectors, scripts and custom configuration. That list shows what needs to be pushed to another team.

Idea two: name the team types correctly

Of the book’s four team types, three bear directly on everyday FDE work; you will meet the fourth when you read the Key Concepts page.

A stream-aligned team follows one stream of work, usually tied to a business domain, and the product team typically sits here. A platform team builds services that help stream-aligned teams move faster by absorbing some of the complexity.

The type most relevant to FDEs is the enabling team: a team that helps stream-aligned teams overcome obstacles while spotting the capabilities they lack. That role is very close to how PostHog describes its FDE team.

That team sits between customers, sales, CS and product engineering, does not own product direction, and carries real lessons from customers back to product through the product engineering teams.

Rocketlane describes a different model: placing the FDE function within product and R&D rather than within go-to-market. No single placement is right for every company. Your job is to work out which model your team follows, because only then do you know where customer requests will end up and who decides.

Idea three: choose the right interaction mode, and set an end date

The book sets out three interaction modes: collaboration, X-as-a-Service and facilitation. Collaboration is defined as two teams working together for a defined period of time to discover something new, such as an API, a practice or a technology. X-as-a-Service is when one team provides something and the other consumes it as a service.

For FDEs, facilitation is when you help the product team understand a problem from the field so they can build the solution themselves, rather than writing the feature for them.

Picture a banking customer that needs SSO through an unfamiliar identity provider. For the first three weeks, the FDE and platform teams collaborate to find the right API. After that, platform offers it as a service and the FDE simply consumes it.

If that collaboration has no end date, platform gets pulled into every customer, and cognitive load spills over into both teams.

To decide when a piece of work should become a service, use the test Rocketlane proposes. A solution that helps only one customer is customization. A solution that helps every future customer is product development.

Applied to the example above, a connector written specifically for the bank’s identity provider is still customization; it becomes product development only when it is turned into something every future customer can use.

What does Docker teach about redrawing the team map?

A diagram that is correct on paper does not necessarily reduce load in practice, and Docker is the clearest example. They used the Reverse Conway Maneuver to align teams with architecture, aiming to reduce cognitive load, cut dependencies and match the product’s direction.

Their first attempt failed. It is a reminder that placing a new team, such as an FDE team, alongside existing ones means checking whether cognitive load has actually fallen; redrawing the diagram is not enough.

Who should read it, and how to use it in your career?

If you are an engineer with two to eight years of experience, working as an FDE or looking to move into the role, this is one of the rare books on organisations you can put to use the following week. Anyone leading a newly formed FDE team should read it all the more.

In interviews, ask directly: does the FDE team report to product or to sales, and by what route do customer requests reach the platform team? A vague answer signals plenty of friction ahead. On your CV, instead of writing “customer integrations”, describe how you turned a piece of customization into a feature shared by many customers.

Every org chart has an FDE box. The book helps you draw the arrows connecting that box to the other teams, and write an expiry date on each one.