Understanding Team Topologies for Product People
Introduction to Team Topologies
In many of my coaching sessions with product leadership teams, we often touch on the topic of team topologies. This often comes up when there's friction between teams—either they're too small, too large, or just not optimally structured. This friction can lead to inefficiencies and misalignment. Therefore, understanding and applying the principles of team topologies is crucial for any organization aiming to streamline its product development process.
Why Team Topologies Matter
One common scenario involves organizations wanting to split large teams into smaller ones to improve focus and efficiency. However, this practical necessity brings up important questions: How do you split teams without causing misalignment? How do you ensure that they remain focused on shared goals without stepping on each other's toes? These are critical considerations when thinking about team structures.
Core Concepts of Team Topologies
Matthew Skelton and Manuel Pais, in their book Team Topologies: Organizing Business and Technology Teams for Fast Flow, outline several team types that can help organizations achieve better flow and alignment:
Stream-aligned teams: Focus on a specific flow of work from a customer perspective.
Enabling teams: Assist stream-aligned teams in overcoming obstacles.
Complicated-subsystem teams: Tackle areas requiring specialized knowledge.
Platform teams: Provide foundational services that other teams use.
These team types help align organizational structure with business goals, ensuring seamless value delivery. However, while I admire both Matthew and Manuel, and enjoy their podcast, their concept of team topologies never fully resonated with me. Perhaps this is because I approach the topic more from a product management perspective rather than an engineering one.
Another expert in this field (and a friend of mine) is Susanne Kaiser, who approaches team topologies through the lens of domain-driven design and Wardley mapping, focusing on optimizing flow in the engineering world. Her approach adds valuable insights, particularly for teams aiming to balance technical flow with user value. Learning about her work has given me new perspectives on structuring teams for both efficiency and product success. If you’re looking to dive deeper into these concepts, I highly recommend checking out her work!
My Approach to Team Topology Challenges
Here are some general rules that guide my approach:
Keep teams small: Teams should be as small as possible, ideally not exceeding eight to ten people. If a team needs to be larger, it indicates excessive friction in the system, and it's worth reassessing the overall structure. Often, excuses like "we are highly regulated and need all these people to ensure compliance" arise, but these should be challenged for the sake of speed and team effectiveness.
Clear user focus: Every team needs a clear user group to focus on and a specific goal to drive. This clarity ensures that each team can tailor its efforts to the needs of its designated user group.
End-to-end responsibility: Teams should have end-to-end responsibility for a part of the user journey. This promotes accountability and helps avoid organizational silos. For example, a team might handle everything from user acquisition to registration and onboarding, ensuring a seamless user experience.
Minimize dependencies: Teams should not be overly dependent on each other. They should be able to drive their goals independently, without waiting for other teams. This independence applies to discovery initiatives, delivery of work, and releases. If teams frequently block each other, it's a sign that the structure needs reassessment.
Effective goal setting and alignment: Effective goal setting is crucial. Leaders must ensure that goals are clear, with no gaps or overlaps, to prevent friction. Tools like KPI trees can help visualize and align team goals with organizational objectives.
Pro tip on team naming: Naming teams based on the value they create for users is far more effective than using random names like those of Greek goddesses. Descriptive names help maintain focus on the team's purpose and goals.
Recommended Dimensions for Splitting Teams
When it comes to structuring teams within a product organization, consider these dimensions to ensure alignment and efficiency:
Product-market fit (PMF) or product: The first and most natural split is by product. If your company has multiple products, each catering to different markets, this becomes the initial division. Each product team focuses on delivering value specific to their product's market.
User group: As your company grows, you might need more teams working on a single product. The next logical split is by user group. For example, in a job marketplace, one team could focus on employers, while another focuses on job seekers. This ensures each team can tailor its efforts to the needs of their specific user group.
Moments of value creation (end-to-end pieces of the user journey): If further splitting is necessary, consider the user journey. Each team takes responsibility for a part of the journey, such as job searching, bookmarking, or applying. This ensures teams are user-focused and can manage their workflows independently.
Parts of the funnel: For even larger organizations, splitting by different stages of the product funnel can be effective. This might include teams focused on user acquisition, onboarding, or growth. Each team optimizes for their part of the funnel, aligning with high-level organizational goals.
A job board example of how you can split teams by the dimensions I suggest.
Anti-Patterns to Avoid
While structuring teams, it's equally important to recognize and avoid common anti-patterns that can hinder productivity and alignment:
Don't ship your org chart: Avoid designing your product teams to mirror your organizational structure. This often leads to inefficiencies and silos. Instead, structure teams based on product needs and user journeys.
Avoid tech teams: While there might be exceptions, splitting teams purely by technology (e.g., frontend/backend, mobile/web) often leads to communication barriers and misalignment. These splits should only occur if there's a strong, justified need, which is rare.
Avoid splits by technology: Similar to tech teams, creating teams around specific technology or platforms (e.g., an AI team or no-code team) can create unnecessary divides. Ensure that teams are focused on delivering user value across the entire product rather than being limited by the technical tools or frameworks they use.
Further Resources
For a deeper dive into team topologies and practical examples, check out these resources:
Team Topologies by Matthew Skelton and Manuel Pais.
Susanne Kaiser's approach to using domain-driven design and Wardley mapping.
Podcast with Manuel Pais discussing team topologies.
Originally published at Mind the Product on September 26, 2024.