As I mentioned in my previous post, when I attended the Fast Flow Conference 25 in Den Bosch (https://www.fastflowconf.com/), I got the know the concept Team Topologies. Afterwards, I bought the book Team Topologies written by Matthew Skelton (https://blog.matthewskelton.net/) and Manuel Pais (https://www.manuelpais.net/)/
The book introduces a point of view which is not so different what was explained in The Accelerate, DevOps Handbook etc. However, it is definitely a book worth reading because authors explain the modern software development challenges and potential solutions to them with quite amount of business cases.
The book contains three parts: Teams as the means of delivery, Team topologies that work for flow and Evolving team interactions for innovations and rapid delivery. Each part has several chapters focusing on different areas of sofware development teams.
It bases Conway’s law and evolves around it. Therefore it is good to understand what Conway’s law before reading the book.
Conway’s law
Let’s first understand what Conway’s law is;
“Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.”
— Melvin E. Conway, 1968
In simpler terms, the way your teams are structured and communicate will shape the architecture of the software they build.
When people collaborate, their communication paths influence how problems are broken down and solved. If teams are siloed or specialized, systems tend to reflect those divisions. For example:
- If you have four separate teams, you’ll likely end up with a system split into four main modules, even if a different structure might be more optimal.
- If your frontend and backend teams rarely talk, the integration between them may be clunky or inefficient.
The book Team Topologies takes this law as reference point and explains how modern software development teams are built against it and of course it gives some ideas and tips how to solve certain challenges.
The fast flow
One of the concepts mentioned is called fast flow.
Fast Flow refers to the ability of an organization to quickly and safely deliver changes to production, from idea to value, with minimal friction. It’s not just about speed — it’s about reliable, sustainable, and continuous delivery of improvements.
Certain obstacles to fast flow are; Pushing against Conway’s law, Software too big for teams, Confusing organizational design options, Team pulled in many directions, Painful re-organizations every few years, Flow is blocked, Too many surprises and Disengaged teams.
This ties directly back to Conway’s Law: to achieve Fast Flow, team structures must support the system architecture you want. That means:
- Teams should be organized around value streams or products, not layers or technologies.
- Use stream-aligned teams that own the full lifecycle of a part of the system.
- Keep dependencies between teams low, so teams can move independently and safely.
Team-First Design
Team-First Design is the idea that you should design your software architecture and systems around the needs and capabilities of your teams, not the other way around.
Instead of forcing teams to fit into a rigid technical design, you shape your system to fit how your teams work best — optimizing for clarity, autonomy, and fast flow. This is one of the main problems in modern organizations. When re-organization is planned, the team dynamics are not taken into account. Instead, teams are expected to adapt the new way of working. In theory this all works however in practice most of those plans are failing. Team topologies adresses this problem in efficient way so that team dynamics, capabilities must be taken into account during the design.
The 4 Fundamental Team Topologies
In Team Topologies, the authors define four fundamental types of teams, each with a clear purpose and mode of interaction. These team types help organizations design team structures that support Fast Flow, reduce friction, and improve autonomy.
Stream-Aligned Team
A stream-aligned team is aligned to a flow of work from a business domain, such as a product, service, customer segment, or user journey. It’s purpose to deliver end-to-end value independently and continuously.
Key characteristics:
- Owns the entire lifecycle (build, run, support)
- Cross-functional (e.g., includes dev, QA, UX, etc.)
- Can release to production without external dependencies
Example:
A team focused on the checkout process in an e-commerce app.
Enabling Team
An enabling team helps other teams adopt new tools, practices, or skills by coaching, sharing expertise, and removing blockers. This teams main purpose is to accelerate learning and adoption of modern practices across teams.
Key characteristics:
- Short-lived or long-lived based on need
- Works by collaborating, not delivering features directly
- Focused on uplifting capabilities (e.g., observability, test automation, security practices)
Example:
A team helping stream-aligned teams adopt Kubernetes or CI/CD pipelines.
Complicated Subsystem Team
A complicated subsystem team focuses on a part of the system that requires deep specialist knowledge, such as algorithms, math-heavy components, or real-time systems. This team develop and maintain high-complexity components so other teams don’t need to understand the deep internals.
Key characteristics:
- Small, focused, high expertise
- Interfaces clearly defined for others to consume
- Often works with stream-aligned teams who use their subsystem
Example:
A team maintaining a fraud detection engine using machine learning.
Platform Team
A platform team builds and maintains internal platforms that make it easier for stream-aligned teams to deliver value. Platform team provide self-service tools and APIs that reduce cognitive load on product teams.
Key characteristics:
- Treats platform as a product (serving internal users)
- Encourages self-service and autonomy
- Avoids becoming a blocker; aims to enable, not control
Example:
A team providing deployment pipelines, logging infrastructure, or a developer portal.
Conclusion
I definitely recommend this book to leaders in software development business. It gives a different point of view and helps today’s leaders to understand how other companies overcome similar software development challenges.