Team topologies

As explained in Effective Platform Engineering

A team topology is an organizational model that defines distinct team types and their interaction boundaries for effective software delivery.

A team topology defines distinct team types and interaction boundaries so teams can access capabilities without unnecessary intrateam communication. It aligns ownership with business value, platform users, specialized subsystems, or temporary capability-building relationships. section 3.1.1

The framework distinguishes four team types:

• Stream-aligned teams own an end-to-end flow of work for a specific business or customer value stream and maintain the resulting service. section 3.1.1
• Platform teams serve internal stream-aligned teams through capabilities such as self-service infrastructure, tooling, and shared services. section 3.1.1 section 10.3.2
• Complicated subsystem teams own technically complex areas requiring specialized expertise that is difficult to distribute across other teams. section 3.1.1
• Enabling teams temporarily provide expertise and guidance while helping stream-aligned teams build capability and share knowledge. section 3.1.1

Epetech’s team restructuring

Epetech formed e-commerce, mobile app, and inventory management stream-aligned teams with development-to-production ownership. A dedicated platform team provided self-service resource provisioning, CI/CD pipelines, logging, monitoring, authentication, and authorization, reducing cognitive load for the stream-aligned teams. section 10.3.2

Figure 3.1 The stream-aligned teams are domain-bounded, but so are the platform team and subsystem team. (Image taken from [1]. Used with permission.)

Use the figure to compare the domain boundaries around stream-aligned, platform, and complicated subsystem teams. section 3.1.1

How Effective Platform Engineering covers it

How deep it goes

Defines four team types and illustrates their responsibilities through platform-engineering and organizational-restructuring scenarios.

Examples

Uses e-commerce, mobile app, inventory management, platform services, CI/CD pipelines, and shared observability and identity services.

What it assumes

Assumes familiarity with software delivery and platform engineering while defining team roles, boundaries, and internal platform relationships.

What you can do after

Apply team topologies to reduce silos, lower cognitive load, clarify ownership, and improve delivery speed, quality, and team morale.

How it connects

Connects team boundaries with platform engineering, self-service, cognitive load, DevOps, developer experience, and SRE practices.

liveBookmanning.com

Read Effective Platform Engineering on liveBook Get the book at manning.com

Also explained in

• 

  liveBookmanning.com
  Architecture Modernization: Socio-technical alignment of software, strategy, and structureA team topology is an arrangement of teams and their interactions within an organization.

Compare how 2 books explain team topologies →

Related concepts

• stream-aligned teamincludes · A stream-aligned team is a long-lived team organized around a continuous flow of customer or business value, with responsibility for delivering and maintaining its product or service.
• engineering platform teamincludes · An engineering platform team is an organizational team that builds, operates, and evolves internal platforms providing shared capabilities for software development and delivery.
• enabling teamincludes · An enabling team is a specialist team that helps other teams acquire capabilities and overcome technical or organizational obstacles without permanently owning their work.
• independent service heuristicsused by · Independent service heuristics are a set of heuristics for assessing the independence of a value stream and identifying concerns that may limit its effectiveness.
• Conway's lawused by · Conway’s law is the observation that a system’s structure tends to reflect the communication structure of the organization that designs it.
• durable teamuses · A durable team is a team that remains responsible for a product or value stream over an extended period rather than disbanding after a project ends.

This explainer was generated by Manning's knowledge graph from the text of Effective Platform Engineering. The section links point to the parts of the book it draws on.