A practical guide to Team Topologies for SMEs

Team Topologies is a modern and effective framework for organizing teams to deliver customer value quickly. At first glance, it can feel overwhelming or suitable only for large organizations. But what do you do when your team is small, and the same experts have to wear multiple hats?

First, I will explain what Team Topologies is and then show how we can adapt it to the agile reality of a Small to Medium-sized Enterprise (SME).

What is Team Topologies?

Team Topologies is a framework developed by Matthew Skelton and Manuel Pais to organize teams for maximum speed and efficiency in delivering value. It is based on two key principles:

Conway’s Law: An organization produces systems that mirror its communication structure. If you want a certain type of software architecture, you must first design the team structure to support it.
Cognitive Load: A single team can only handle a limited amount of complexity. The goal is to minimize the team’s cognitive load so it can focus entirely on its own, well-defined responsibilities.

The four team types

The model proposes four distinct team types, each with a clear purpose:

Stream-aligned team: The primary team type. Responsible for a single, clear stream of work that produces business/customer value, such as a product, service, or customer journey. They own their area of responsibility end-to-end.
Platform team: Provides internal services and tools that stream-aligned teams need to work independently. Their internal platform (e.g., CI/CD pipelines, infrastructure) is available to other teams as a self-service. Their goal is to reduce the cognitive load of other teams.
Enabling team: A team of experts that helps stream-aligned teams learn new capabilities. They act as coaches for a limited time, assisting with tasks like adopting test automation. They teach; they don’t do the work for others.
Complicated subsystem team: A specialized team responsible for parts of the system that require deep expertise (e.g., a complex algorithm or machine learning model). They hide this complexity from other teams.

The three interaction modes

To prevent chaos between teams, the model defines three clear ways to interact:

Collaboration: Two teams work closely together for a limited time, typically when exploring a new problem.
X-as-a-Service: One team offers something as a service (e.g., an API or tool) that another team consumes. This is the most common and scalable interaction.
Facilitating: One team helps another learn. This is the primary mode for an Enabling team.

Adapting Team Topologies for SMEs

How does this work when your team has five people instead of fifty?

In an SME, team types are not permanent, separate units. Instead, think in terms of roles or “hats” that the same people wear depending on the situation.

On Monday morning, Kate and Peter wear their Stream-Aligned hats and develop a new feature for the customer interface.
In the afternoon, Peter puts on his Platform hat and improves the CI/CD pipeline that everyone uses.
At the same time, Kate wears her Enabling hat and coaches another developer on adopting a new testing library.

Why the hat model works

Creates clarity and purpose: Switching hats signals your current goal: building customer value, improving common tools, or helping others succeed.
Makes interaction modes explicit: When Peter wears the Platform hat, he provides a service to others (X-as-a-Service). When Kate wears the Enabling hat, she teaches and guides (Facilitating). Switching hats makes the rules of interaction clear.
Manages cognitive load: Even though people do different tasks, hats help maintain focus. You only concentrate on the responsibilities of the current hat.
Scalable mindset: As the company grows, a part-time Platform hat can evolve into a full-time role and eventually a dedicated team. The structure and mindset are already in place.

Team Topologies is therefore not just for large organizations. It is primarily a way of thinking about structuring work, dependencies, and responsibilities. For SMEs, the Hat Model is a practical way to apply these lessons immediately.

Challenges and growing pains of the hat model

1. Senior expert bottleneck

Small teams often rely heavily on one or two senior experts. In practice, these seniors rarely stay fully in their intended roles. Unexpected work (bug fixes, urgent production issues, or ad-hoc requests) quickly accumulates. This unplanned work constantly interrupts their focus on strategic tasks or platform development.

Lesson from experience: Simply assigning a senior to a role is not enough. You must make all work visible, including the unplanned, reactive tasks. Tracking this work allows the team to understand the true workload, prioritize effectively, and protect the senior’s time for coaching and high-value tasks.

Solution: In my experience, one of the most effective ways to manage this is through a visual board of all work: planned features, platform tasks, and reactive issues. Even in a five-person team, seeing all the hats and types of work at a glance helps prevent burnout, ensures priorities are clear, and creates opportunities for others to help carry the load.

2. Cognitive load and context switching

Switching hats frequently is demanding and increases mental load. Solution: Establish discipline and priorities. For example: “This week, 80% focus on Stream-Aligned work. Platform hats are only worn on Fridays.” Clear focus is crucial in small teams.

3. When one hat takes all the time

If one responsibility grows too large (e.g., platform maintenance consumes a full workday), the Hat Model has reached its limit. Solution: Management must recognize this as a signal of growth. It may be time to create a dedicated role or team.

Example: BillWise Solutions, billing system development

The BillWise team structure with its hats

Financial Processes Team A (stream-aligned)

Responsibility: Core financial processes: e-invoicing, payment flows, accounting integrations, and legal compliance.
Members: Product Manager, 2 Backend Devs, QA, Integration Specialist.
Example: Ensures compliance with e-invoicing standards and accounting integrations.

Customer Experience Team B (stream-aligned)

Responsibility: End-to-end ownership of the entire customer experience: user accounts, invoice delivery, mobile features, and reporting.
Members: Product Manager, 2 Frontend Devs, 1 Backend Dev, UX Designer, and Saara (Enabling role).
Example: Develops automation for payment reminder invoices.

Minna (complicated subsystem role)

Role: Senior Backend Developer.
Responsibility: Develops and maintains the complex tax automation engine in collaboration with the Financial Processes Team, providing it as an API service for other teams.

Marko (platform role)

Role: Senior Infrastructure Developer (also a member of the Financial Processes Team).
Responsibility: Manages cloud infrastructure (AWS), CI/CD pipelines, and monitoring (“X-as-a-Service”).
Example: The Customer Experience Team deploys a new microservice via Marko’s CI/CD pipeline.
Growth: Junior developers may join Marko to form a dedicated Platform Team in the future.

Saara (enabling role)

Role: Senior Full-Stack Developer & Team Lead (part of Customer Experience Team).
Responsibility: Coaches and supports other teams in adopting new technologies and practices (e.g., test automation). She helps the teams do the work rather than doing it for them.

Team Topologies does not require a large organization. It is primarily a mindset that helps structure work, dependencies, and responsibilities. For SMEs, the Hat Model is a practical way to apply these lessons immediately while providing a clear path for growth.