Tomasz Staniak

Four Fundamental Team Types
The book defines four essential team types that form the building blocks of technology organizations:

1. Stream-aligned teams

   • Cross-functional teams aligned to a specific value stream or customer journey
   • Empowered to build and deliver customer value independently
   • Typically include development, testing, UX, and product skills
   • Examples: Mobile app team, Customer onboarding team, Trading platform team
   • Should be able to make local decisions and changes without external dependencies
   • Primary team type - most teams in an organization should be stream-aligned

2. Platform teams

   • Provide internal services to reduce cognitive load for stream-aligned teams
   • Treat their services as products with clear interfaces and documentation
   • Focus on developer experience and self-service capabilities
   • Examples: Developer infrastructure, CI/CD platforms, Data platforms
   • Should have strong product management to understand internal customer needs
   • Measure success through platform adoption and stream-aligned team effectiveness

3. Enabling teams

   • Temporary nature - help other teams adopt new technologies or practices
   • Act as technical consultants rather than doing the work themselves
   • Focus on knowledge transfer and capability building
   • Examples: Cloud migration experts, Security specialists, Agile coaches
   • Should avoid creating dependencies or becoming permanent supports
   • Success means making themselves unnecessary for that particular capability

4. Complicated Subsystem teams

   • Handle complex technical components requiring specialized expertise
   • Reduce cognitive load by encapsulating complex domains
   • Should be used sparingly - only when complexity truly warrants isolation
   • Examples: Trading algorithms, Machine learning engines, Video codecs
   • Must maintain clear interfaces and documentation
   • Should resist expanding scope beyond their core complexity

Team Interaction Modes
Three primary ways teams should interact:

1. Collaboration

   • Close working relationship for discovery and learning
   • High-bandwidth communication with frequent interaction
   • Best for uncertain or exploratory work
   • Time-boxed to prevent permanent dependencies
   • Examples: New product development, Major architectural changes
   • Requires clear exit criteria to avoid prolonged collaboration

2. X-as-a-Service

   • Teams consume services from other teams with minimal collaboration
   • Clear interfaces and service level agreements
   • Documented APIs and self-service capabilities
   • Examples: Platform teams providing infrastructure services
   • Focuses on reducing cognitive load through abstraction
   • Requires strong documentation and reliable service delivery

3. Facilitating

   • One team helps another learn or adopt new capabilities
   • Knowledge transfer focused
   • Temporary by nature
   • Examples: Security team helping implement best practices
   • Success means the receiving team becomes self-sufficient
   • Requires clear learning objectives and timeline

Cognitive Load Management
Teams must be sized and structured based on cognitive load:

• Team Size and Structure

  • Aim for 5-9 engineers per team
  • Smaller teams can’t effectively abstract individual contributions
  • Larger teams increase communication overhead exponentially
  • Consider team maturity and domain complexity when sizing

• Types of Cognitive Load

  • Intrinsic: Fundamental complexity of the work itself

    • Example: Understanding complex business rules or algorithms
    • Cannot be reduced, must be managed through team boundaries

  • Extraneous: Unnecessary complexity from tools or processes

    • Example: Complex deployment procedures, poor documentation
    • Should be minimized through better tools and practices

  • Germane: Cognitive load related to learning and improving

    • Example: Learning new technologies or domains
    • Should be explicitly planned for and managed

• Practical Applications

  • Assign ownership based on team capacity to handle cognitive load
  • Monitor signs of cognitive overload (delays, errors, stress)
  • Use platform teams to reduce extraneous load
  • Explicitly manage cognitive load when planning work
  • Consider cognitive load when defining team boundaries
  • Regular assessment of team cognitive load to prevent overburden

This structured approach to team organization helps create sustainable, high-performing technology organizations by explicitly managing team cognitive load and interaction patterns. The key is to maintain clear boundaries while ensuring necessary collaboration, always with an eye toward optimizing for flow and reducing unnecessary complexity.

Conway’s Law Applications
Conway’s Law states that organizations design systems that mirror their own communication structure - “Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.” Understanding this principle is crucial for effective team and system design.
Organizations should use Conway’s Law intentionally:

• Design team boundaries to match desired software architecture: Create team structures that reflect the modular, decoupled architecture you want to achieve
• Use the “Reverse Conway Maneuver” to influence system architecture: Deliberately structure teams to encourage the desired software architecture to emerge
• Align team structures with desired software boundaries: Ensure team communication patterns support rather than hinder the intended system design

This means that instead of letting organizational structures accidentally dictate system architecture, teams should be consciously designed to promote the desired technical outcomes. For example, if you want a modular, microservices-based architecture, organize small, independent teams aligned with service boundaries.

Q: How do you determine the right team topology for your organization?
A: Start by identifying your value streams and assessing team cognitive load. Consider your organization’s technical maturity, scale, and business goals. The book recommends beginning with stream-aligned teams and adding other team types as needed to support them.

Q: What’s the difference between platform teams and enabling teams?
A: Platform teams provide internal products or services that other teams consume (X-as-a-Service model). Enabling teams temporarily collaborate with other teams to help them learn new capabilities or adopt new technologies. Platform teams focus on providing services, while enabling teams focus on knowledge transfer.

Q: How should teams evolve as the organization grows?
A: Teams should adapt based on changing needs and cognitive load. Start with stream-aligned teams, then add platform teams to handle common capabilities. Add enabling teams when teams need help adopting new practices. Use complicated subsystem teams only when specialized expertise is truly needed.

Q: How do you manage dependencies between teams?
A: Define clear team interaction modes (Collaboration, X-as-a-Service, Facilitating) and establish team boundaries based on software architecture. Use platform teams to reduce dependencies, and ensure teams have the right capabilities to minimize handoffs.

Q: What are signs that your team topology needs to change?
A: Watch for symptoms like increasing delivery delays, rising cognitive load, frequent miscommunication, or teams becoming bottlenecks. Also consider changes in business context, technical complexity, or organizational scale that might require topology adjustments.

• When restructuring technology organizations: You need frameworks for organizing teams to optimize delivery flow and reduce dependencies
• During rapid growth: Your organization is scaling and needs clear patterns for team structure and interaction
• When facing delivery bottlenecks: Teams are struggling with dependencies and coordination issues
• When adopting platform strategies: You’re building internal platforms and need to understand team patterns for platform development