Why Your Teams Are Struggling to Deliver (and How to Fix It)
A Team Topologies Approach to Identifying and Solving Delivery Challenges
You’re leading a talented development team that is working on a critical product feature. However, what should be three weeks’ worth of work is taking months already. There is no clarity but chaos. The codebase is extremely complex, with no clear boundaries, and full of surprises. Autonomy to develop fast is a pipe dream.
Finally, your developers have just wrapped up their part of the work; it’s “dev done”, yeah! The next step? QA needs to test the feature. The handoff is not immediate, but it happens, and QA begins their work. But they quickly find a critical bug. The feature goes back to the developers, who scramble to fix it.
After resolving the bug, the QA team signs off the work and the feature is ready for deployment. But an additional problem has arisen. The infrastructure team, already swamped with requests, can’t provision a new environment in time.
Meanwhile, another team working on the same highly coupled codebase makes a change that accidentally breaks your feature. They changed a query that no team owns and that apparently nobody really knows how it fully works.
It feels like the team takes two steps backward for every step forward. Another missed deadline. And frustration mounts across the board. If that sounds familiar to you, you’re not alone.
Inefficient systems and team organization are still too common nowadays. But here’s the good news: it doesn’t have to be this way. You can break free from this pattern and achieve continuous, faster delivery by rethinking your team structures and interactions.
Enter Team Topologies.
Overview of Team Topologies
Team Topologies, by Matthew Skelton and Manuel Pais, offers a fresh approach to organizing teams to improve efficiency and achieve company objectives. Here are the key concepts of the book:
Four Key Team Types
Stream-aligned teams: Owning end-to-end delivery of specific value streams.
Enabling teams: Supporting stream-aligned teams by upskilling and resolving roadblocks.
Complicated subsystem teams: Handling highly specialized, complex areas of the system.
Platform teams: Providing self-service tools and APIs to reduce cognitive load on other teams.
Three Interaction Modes
Collaboration: Short-term, intensive work together to solve specific challenges.
X-as-a-Service: One team provides a consumable service to others.
Facilitation: One team supports another in solving a problem themselves.
Team Topologies simplifies team interactions by defining clear roles and responsibilities. By aligning team structures with goals and using distinct team types and interaction modes, organizations can reduce inefficiencies, lower cognitive load, and streamline communication. The result? More autonomy, faster delivery, and fewer bottlenecks, even in complex, fast-paced environments.
7 Causes of Slow Delivery and How to Overcome Them
Rapid delivery is crucial for businesses to survive and thrive in today’s fast-paced environment. Yet, many organizations unintentionally create obstacles that slow down delivery and stifle innovation. Drawing inspiration from Team Topologies, let’s explore the key causes of slow delivery, illustrated with examples and actionable solutions.
It’s important to note that while these simplified solutions offer valuable guidance, every organization operates within its own unique complexities. You should adapt these shared strategies to your specific context; they are simplified frameworks.
1. Misaligned Team Structures
Why it Happens
Teams frequently organize around outdated models (e.g., Conway’s Law violations), resulting in dependencies between multiple teams for single-feature delivery. This creates bottlenecks in communication and delivery.
Example
A frontend team needs API changes from the backend team for a new feature. Both teams have competing priorities and dependencies, delaying the release.
Solution
Adopt a team-first approach. Restructure teams into stream-aligned groups focused on end-to-end ownership of specific value streams. Introduce enabling teams to address knowledge gaps without disrupting flow.
“Conway’s law tells us that we need to understand what software architecture is needed before we organize our teams, otherwise the communication paths and incentives in the organization will end up dictating the software architecture.”
― Team Topologies: Organizing Business and Technology Teams for Fast Flow
2. Overloaded Cognitive Load
Why it Happens
Too many responsibilities burden teams: managing legacy systems, keeping up with platform updates, and delivering new features. This overload reduces the team’s ability to innovate.
Example
A team responsible for both feature delivery and managing cloud infrastructure spends so much time firefighting outages that new development stalls.
Solution
Create platform teams that provide reusable infrastructure and tools, allowing stream-aligned teams to focus on their core responsibilities. Regularly assess cognitive load and offload unnecessary tasks.
“When cognitive load isn’t considered, teams are spread thin trying to cover an excessive amount of responsibilities and domains. Such a team lacks bandwidth to pursue mastery of their trade and struggles with the costs of switching contexts.”
― Team Topologies: Organizing Business and Technology Teams for Fast Flow
3. Inefficient Interaction Models
Why it Happens
Ad hoc communication and unstructured collaboration between teams without clear interaction models leads to interruption-driven work, context switching, and repeated escalations between teams.
Example
A platform team supports multiple stream-aligned teams but lacks defined interfaces or service-level agreements (SLAs). Unresolved requests accumulate, and no one knows when their issue will receive attention.
Solution
Implement the Team API concept: define clear, documented interfaces for how teams interact. Use well-defined interaction modes (“collaboration,” “X-as-a-service,” “facilitating”) to clarify how teams should work together.
“Fast flow requires restricting communication between teams. Team collaboration is important for gray areas of development, where discovery and expertise is needed to make progress. But in areas where execution prevails—not discovery—communication becomes an unnecessary overhead.”
― Team Topologies: Organizing Business and Technology Teams for Fast Flow
4. Lack of Clear Boundaries and Ownership
Why it Happens
Ambiguous or overlapping team responsibilities create confusion, duplications of effort, and frequent conflicts about ownership.
Example
Two or more teams work on the same codebase or services without clear boundaries, leading to rework, difficult integrations, and undesired side effects when someone changes them.
Solution
Define well-scoped team responsibilities and boundaries. Stream-aligned teams own specific product or service areas, while platform, enabling, or complicated-subsystem teams handle specialized tasks.
“Teams are not just groups of people working together, but groups of people working together with clear roles, responsibilities, and interactions.”
― Team Topologies: Organizing Business and Technology Teams for Fast Flow
5. Excessive and Inefficient Handoffs
Why it Happens
Work passes through multiple teams, each waiting for input or approval. This waterfall-like process disrupts fast flow and slows delivery.
Example
A feature requires work and approval from UX, development, QA, and security teams, each of whom operates on separate timelines, causing bottlenecks. The process stretches delivery timelines to months.
Solution
Minimize handoffs by embedding cross-functional skills into stream-aligned teams that own the delivery process end-to-end. This reduces dependencies and handoffs, enabling quicker, more autonomous delivery.
“An organization that is arranged in functional silos (where teams specialize in a particular function, such as QA, DBA, or security) is unlikely to ever produce software systems that are well-architected for end-to-end flow.”
― Team Topologies: Organizing Business and Technology Teams for Fast Flow
6. Poor Developer Experience
Why it Happens
Internal platform teams often focus on delivering features without prioritizing user experience (UX) and developer experience (DevEx). This leads to tools and services that are difficult for developers to use, slowing delivery and causing frustration.
Example
A platform team builds a deployment pipeline, but it’s overly complex, requiring manual configuration and lacking clear documentation. Stream-aligned teams struggle to use it efficiently, resorting to workarounds or bypassing the platform entirely.
Solution
Ensure platform teams prioritize UX and DevEx by treating internal tools as products. Conduct regular feedback sessions with developers, simplify interfaces, and provide thorough documentation. Focus on creating self-service tools that empower teams rather than creating dependencies.
“To avoid the too-common trap of building a platform disconnected from the needs of teams, it is essential to ensure that the platform teams have a focus on user experience (UX) and particularly developer experience (DevEx).”
― Team Topologies: Organizing Business and Technology Teams for Fast Flow
7. Lack of Autonomy
Why it Happens
Tightly coupled systems and teams create dependencies that slow delivery. Teams must coordinate for even minor changes, increasing delays and reducing autonomy.
Example
In a monolithic e-commerce platform, updating the order-processing workflow requires input from billing, shipping, and inventory teams, delaying delivery for weeks.
Solution
Reduce dependencies by designing loosely coupled systems. Use event-driven architectures to decouple services, dependency boards to visualize bottlenecks, and align team boundaries with system boundaries for greater autonomy.
“The purpose of a platform team is to enable stream-aligned teams to deliver work with substantial autonomy. The stream-aligned team maintains full ownership of building, running, and fixing their application in production. The platform team provides internal services to reduce the cognitive load that would be required from stream-aligned teams to develop these underlying services.”
― Team Topologies: Organizing Business and Technology Teams for Fast Flow
How to Reorganize Your Teams
Now that we know the causes of slow delivery, it’s time to address them head-on—and that often means reorganizing your teams. Organizations need to evolve and adapt continuously to meet new challenges and opportunities. When done thoughtfully, reorganizations can unlock faster delivery, better alignment, and improved team satisfaction.
Reorganizations can drive positive change, but excluding technical teams often leads to misaligned structures that exacerbate problems. As Team Topologies highlights, poorly planned reorganizations can misalign team structures and system architecture, leading to increased dependencies, higher cognitive load, and slower delivery.
Here are three steps to reorganize effectively:
Engage Technical Teams Early: Involve technical leaders to ensure team boundaries reflect system architecture.
Follow Team Topologies Principles: Use tools like dependency maps and fracture planes to create logical team structures.
Communicate Clearly: Share the goals and benefits of the reorganization to align teams and reduce resistance.
Reorganizations are a chance to refine and optimize. Aligning technical and business needs empowers teams to deliver faster and with greater autonomy.
“Reorganizations that ignore Conway’s law, team cognitive load, and related dynamics risk acting like open heart surgery performed by a child: highly destructive.”
― Team Topologies: Organizing Business and Technology Teams for Fast Flow
Final Thoughts
Delivering software quickly and effectively starts with tackling the root causes of slow flow and building teams that can work seamlessly together. Common blockers like misaligned teams, high dependencies, and overwhelming cognitive load often stand in the way, dragging progress and frustrating everyone involved.
Reorganizations can help fix these issues, but only if approached with a team-first mindset. Rushed or top-down re-orgs often create more harm than good. As Allan Kelly in Project Myopia aptly puts it, “Disbanding high-performing teams is worse than vandalism: it is corporate psychopathy.” Teams take time to jell, moving through stages from forming to performing. Protecting and nurturing high-performing teams must be a priority, not a casualty of change.
By embracing Team Topologies principles—such as fostering stream-aligned teams, prioritizing developer experience, minimizing dependencies, and empowering teams with ownership—you can cultivate stronger, more cohesive teams and speed up workflows effectively.
The goal is simple: create an environment where teams can work independently, deliver quickly, and adapt to change. With the right focus, you can set your teams up for success and create a system that thrives on any challenge.
Enjoyed the article? Hit the ❤️ button and share it with others who might find it helpful. Subscribe to support my work and stay updated on future issues!
Nicely written with clear solutions. Some of these topologies embedded in our Scrum of Scrum and Safe practices.
Great advices! I love TT and used it often, although in a mostly eclectic way. One of my favorite part is the mode of interaction. What I found that most managers missed the most about it is that the solution is rarely having a single mode of communication, but rather limiting the high cognitive load modes to 1 or 2 clients and transitioning to low cognitive load modes before switching.
So, if you develop an API, you start doing collaboratively with one client, so that you learn and confirm the needs quickly, then do some facilitations with one or two clients integrating your API the first time, ironing out and automating the process, for finally ending up putting with the API being part of the X-as-a-service offering. The trick is the team is mostly focused on the first part, are available for facilitation on the second part and mostly ensure things are running smoothly on the last part. As a rule of thumb, I recommend something like 60-30-10 or even 80-15-5. The trick is, if the lower items take more than that, you must upgraded them to a higher mode until you can put them back in the background. A team that passed more than 10% of their time fixing bugs in a X-as-a-service mode is inefficient. You should admit the feature wasn't ready for XaaS, select a client which has problems, start working closely with them, and only bring back the previous development feature once the broken feature is in a better step. The first part here, admitting the feature isn't ready, is the most important. Elsewhere, the devs will try, justifiably, to bandaid the problem when clearly, you need more than just a bandaid.