On this page
Team Topologies is a methodology that can be applied in software development organizations to improve software delivery. It provides a framework for understanding the interconnections between different teams, and how information flows between them. This can help in identifying bottlenecks, optimizing processes, and fostering better communication and collaboration.
How does it apply to you?
Team Topologies can be used to enhance the learning experience of developers in a software development organization. By understanding the structure and dynamics of the team, educators can design more effective learning strategies. This could include creating customized training programs based on the roles and responsibilities of different teams, or promoting peer learning by facilitating knowledge sharing between interconnected teams.
Applied Learning to Developer Education
Developer Education should be centered on empowering engineers. This involves understanding the informal structure within the company and identifying where value is created. This approach enables teams to adapt quickly to new conditions.
The Impact of Conway's Law on Developer Education
Conway's Law, which states that an organization's design will mirror its communication structure, can affect Developer Education. This can be particularly challenging if there are multiple learning teams within the organization. Effective management of the team's cognitive load is crucial.
Utilizing the Reverse Conway Maneuver in Developer Education
The Reverse Conway Maneuver can be used in Developer Education to overcome the constraints of Conway's Law. This involves restructuring the organization to mirror the desired communication patterns. It's also crucial to control the flow of communication to reduce noise and increase output.
The Importance of Team-First Thinking and Diversity in Developer Education
A team-first approach and fostering diversity are critical aspects of Developer Education. The cognitive load of developers should always be taken into account, and the focus should not be on teaching things that can be automated. Instead, the goal is to define the team's 'API' and facilitate interactions that build trust, awareness, and learning.
Designing Effective Teams for Developer Education
Teams in Developer Education should be designed deliberately for effectiveness. This includes working to automate and evangelize knowledge sharing. Developer Education is classified as an Enabling Team, which promotes learning not only within the team but across the organization, supporting a key learning function.
Engagement Models in Developer Education
Developer Education employs various engagement models such as collaboration, X-as-a-service, and facilitation. As an enablement team, Developer Education predominantly uses the facilitation model. It is crucial for the team to clearly outline what they do and offer consistent experiences.
Developer Education as Full-Time Developer Advocates
Members of the Developer Education team act as full-time developer advocates. Their role is to provide support and facilitate learning, thereby enabling developers to deliver working software in a sustainable, responsible way.
Empowering Engineers in Developer Education
Instead of focusing on tool and process tutorials, Developer Education should concentrate on empowering engineers to excel in their work. This involves a shift from viewing engineers as interchangeable and providing generic training to a focus on individual problem-solving and blocker reduction.
The Misconception of Organizational Charts
Organizational charts often fail to accurately depict how work is conducted and how teams interact. When training and communication are strictly confined within the org chart's boundaries, they can become outdated and irrelevant due to regular team reorganizations.
System Thinking Over Org Charts
System Thinking should be adopted instead of relying on org charts. This approach emphasizes optimizing the overall work process, identifying and eliminating bottlenecks, and repeating this process. It also promotes setting up dynamic team structures and interaction modes that help teams quickly adapt to new conditions and ensure safe software delivery.
Understanding the Informal Structure and Value Creation
The key to successful knowledge work organizations lies in the interactions between the informal and value-creation structures. Developer Education should recognize and leverage these interactions.
The Impact of Conway’s Law on Developer Education
Conway's Law suggests that an organization's system design is a reflection of its communication structures. Therefore, if a company has multiple learning teams, the resulting learning experience might be disjointed. To avoid this, all learning teams should collaborate to ensure a seamless end-to-end flow of a developer’s learning journey.
Developer Checklist
Team Topologies and Developer Education
Conway's Law and Developer Education
Communication and Team Dynamics
Cognitive Load Management
Team Design and Interaction
Team Topologies Implementation and Evolution
Summary
Team Topologies Introduction
Team Topologies is a methodology that helps organizations understand and adapt their team structures to improve software delivery. It provides a framework for visualizing the interconnections between different teams, and how information flows between them. This holistic perspective can aid in identifying bottlenecks, optimizing processes, and fostering better communication and collaboration.
Application to Developer Education
In the context of Developer Education, Team Topologies can be used to enhance the learning experience of developers. By understanding the structure and dynamics of the team, educators can design more effective learning strategies. For example, they can create customized training programs based on the roles and responsibilities of different teams, or promote peer learning by facilitating knowledge sharing between interconnected teams.
Empowering Engineers through Developer Education
Developer Education should be centered on empowering engineers, rather than being based on organizational charts. The aim is to enable teams to adapt quickly to new conditions. This requires understanding the informal structure within the company and identifying where value is created.
The Impact of Conway's Law on Developer Education
Developer Education can be affected by Conway's Law, which states that an organization's design will mirror its communication structure. This can be particularly challenging if there are multiple learning teams within the organization. Leaders in Developer Education need to consider the cognitive load of their team and work to manage this effectively.
Utilizing the Reverse Conway Maneuver in Developer Education
The Reverse Conway Maneuver can be used in Developer Education to overcome the constraints of Conway's Law. This involves restructuring the organization to mirror the desired communication patterns. It's also crucial to control the flow of communication to reduce noise and increase output.
The Importance of Team-First Thinking and Diversity in Developer Education
Emphasizing a team-first approach and fostering diversity are critical aspects of Developer Education. The cognitive load of developers should always be taken into account, and the focus should not be on teaching things that can be automated. Instead, the goal is to define the team's 'API' and facilitate interactions that build trust, awareness, and learning.
Designing Effective Teams for Developer Education
It's important for Developer Education to design teams deliberately for effectiveness. This includes working to automate and evangelize knowledge sharing. Four types of teams exist in this context: stream-aligned, complicated subsystem, enabling, and platform. Developer Education is classified as an Enabling Team, which promotes learning not only within the team but across the organization, supporting a key learning function.
Engagement Models in Developer Education
Developer Education employs various engagement models such as collaboration, X-as-a-service, and facilitation. As an enablement team, Developer Education predominantly uses the facilitation model. It is crucial for the team to clearly outline what they do and offer consistent experiences.
Developer Education as Full-Time Developer Advocates
Members of the Developer Education team act as full-time developer advocates. Their role is to provide support and facilitate learning, thereby enabling developers to deliver working software in a sustainable, responsible way.
Empowering Engineers in Developer Education
Developer Education often leans towards tool and process tutorials, focusing on the company's tech ecosystem rather than individual problem-solving or blocker reduction. There's an overemphasis on viewing engineers as interchangeable and providing generic training, which can be counterproductive. Instead, Developer Education should concentrate on empowering engineers to excel in their work.
The Misconception of Organizational Charts
Organizational charts often fail to accurately depict how work is conducted and how teams interact. Traditional org charts are incompatible with the dynamic nature of modern workplaces, characterized by frequent team reshuffling and collaborative knowledge work in uncertain environments. When training and communication are strictly confined within the org chart's boundaries, they can become outdated and irrelevant due to regular team reorganizations.
System Thinking Over Org Charts
System Thinking should be adopted instead of relying on org charts. This approach emphasizes optimizing the overall work process, identifying and eliminating bottlenecks, and repeating this process. It also promotes setting up dynamic team structures and interaction modes that help teams quickly adapt to new conditions and ensure safe software delivery.
Understanding the Informal Structure and Value Creation
Niels Pflaeging, in his book 'Organize for Complexity', identifies three organizational structures: formal structure chart (for compliance), informal structure (influence between individuals), and value creation structure (how work gets done based on reputation). The key to successful knowledge work organizations lies in the interactions between the informal and value creation structures. Developer Education should recognize and leverage these interactions.
The Impact of Conway’s Law on Developer Education
Conway's Law suggests that an organization's system design is a reflection of its communication structures. Therefore, if a company has multiple learning teams, the resulting learning experience might be disjointed. To avoid this, all learning teams should collaborate to ensure a seamless end-to-end flow of a developer’s learning journey.
The Importance of Considering Cognitive Load
Ignoring cognitive load can lead to teams being overstretched across multiple responsibilities and domains, hindering their ability to master their trade due to constant context switching. This can demotivate the team and disrupt intrinsic motivation aspects such as autonomy, mastery, and purpose, as described by Daniel Pink. Therefore, it is crucial to manage cognitive load when deciding on team size, assigning responsibility, and establishing boundaries with other teams.
Understanding Conway's Law and Its Application
Conway's Law suggests that the communication paths within an organization control the types of solutions that can be created. However, this law can be used advantageously. The organization's structure can be reshaped to discourage certain types of designs and encourage others. This is known as the Reverse Conway Maneuver, which involves reconfiguring team intercommunications to increase the chances of building effective software systems optimized for flow of value.
Implications of Conway's Law on Developer Education
In the context of Developer Education, a centralized DevEd team typically results in more generalized learning solutions. However, using the reverse Conway maneuver would require a DevEd person embedded into each team. Since this is usually not feasible, resources on the team need to be allocated to facilitate the creation of solution-specific training.
HR's Impact on Software Architecture
Conway's law implies that decisions about the shape and placement of engineering teams strongly influence the software systems architecture. Managers who decide which services will be built by which teams indirectly decide on the system architecture. Therefore, it is crucial for HR departments and leaders who allocate budgets across teams to understand the potential effects of their choices on the software architecture.
The Balance of Communication in Organizations
Increasing communication is not always beneficial. What's more important is focused communication that addresses the cause of unexpected communications. Organizations should aim for low or zero bandwidth communication between teams, especially in areas where execution prevails over discovery. Overcommunication can lead to monolithic, highly coupled, and interdependent systems that do not support fast flow, as suggested by Conway's Law.
Impact of Communication Tools on Enterprise Architecture
The choice and use of software communication tools can significantly influence communication patterns between teams. Shared tools are beneficial for teams that need to collaborate, while separate tools or instances of the same tool may be better for teams that require clear responsibility boundaries. The choice of tools must consider team interrelationships and encourage team-scoped flow.
Team-First Thinking in Developer Education Leadership
Leadership in developer education should prioritize team dynamics over individual performance. Research indicates that the dynamics within a team impact performance more significantly than the individual members. Work should be assigned to teams, not individuals. The size of the team should be limited to foster trust and innovation, with an ideal team size being between seven to nine members.
The Influence of Dunbar's Number on Team Size
Dunbar's number, a theoretical limit to the number of people one can maintain stable social relationships with, should influence the size of team groupings. This number suggests limits to close personal relationships (five people), deep trust relationships (15 people), mutual trust relationships (50 people), and the limit of people whose capabilities we can remember (150 people).
Best Practices Using Dunbar's Number
A single team should ideally consist of five to eight people, with no more than 15 people in high trust organizations. Larger groupings should not exceed 50 people in high trust organizations, and 150 people in total. Teams should be stable, but not static, changing only occasionally and when necessary.
Tuckerman Teal Performance Model and Its Limitations
The Tuckerman Teal Performance Model, which describes team performance in four stages (forming, storming, norming, and performing), has been found to be inaccurate in recent years. This is because 'storming' or working through differences, occurs continually throughout the life of a team, not just in the initial stages.
The Importance of Team-First Thinking in Developer Education Members
Members of Developer Education should prioritize team goals over individual goals. This includes arriving for meetings on time, helping unblock other team members before starting new work, and mentoring less experienced team members. Accomplishments should be attributed to the team as a whole, not to individual members.
The Value of Diversity in Developer Education Teams
Diverse teams tend to produce more creative solutions and are better at empathizing with other teams' needs. A diverse mix of people also fosters better results as team members make fewer assumptions about the software users' context and needs. Heterogeneity can aid in creating a cohesive team and discovering new possibilities.
Understanding and Managing Cognitive Load in Developer Education
Cognitive load refers to the total amount of mental effort being used in the working memory. It encompasses intrinsic cognitive load (task fundamentals), extraneous cognitive load (environment in which the task is done) and germane cognitive load (aspects of the task that need special attention). Developer Education should respect the finite cognitive capacity of developers and manage their cognitive load effectively.
The Importance of Automation in Developer Education
Intrinsic cognitive load should be minimized through training and extraneous cognitive load should be eliminated through automation. Tasks or commands that add little value to the working memory should be automated, leaving more space for germane cognitive load, where value-adding thinking lies.
Strategies for Reducing Cognitive Load
Cognitive load can be reduced by limiting the number and type of domains per team, breaking down a team into micro-teams with a clear mission, and prioritizing how the responsible team feels about the complexity of a domain. Domains can be classified into simple, complicated, or complex, and assigned to teams accordingly.
Maximizing Cognitive Capacity of a Team
Teams can maximize their cognitive capacity by providing a team-first working environment, minimizing distractions, changing the management style to focus on goals and outcomes, improving the quality of developer experience, and using a platform designed to reduce cognitive load.
Defining the 'Team API' in Developer Education
Developer Education teams should define their 'Team API', which includes how engineering teams can interact with your team, and the actual APIs of learning materials and knowledge repositories. This API should be continuously defined, advertised, tested, and evolved to ensure it is fit for purpose.
Facilitating Team Interactions for Trust, Awareness, and Learning
Developer Education should facilitate interactions between different teams to build trust, increase awareness, and promote learning. This can be achieved through a consciously designed physical and virtual environment, and time away from desks at guilds, communities of practice, internal tech conferences, and evening meetups.
Designing Physical and Virtual Environments to Facilitate Team Interactions
A well-designed physical and virtual environment can foster team interaction. Physical spaces should promote collaboration, while virtual environments should be easy to navigate and guide people to the right answer quickly. Ground rules for remote work should be established, including working hours, response times, and communication tone.
The Importance of Deliberate Team Design
To maximize effectiveness, teams should be consciously designed rather than formed accidentally or haphazardly. These intentionally formed teams are referred to as 'team topologies', which acknowledges the deliberate placement of teams within the organization and defines the boundary of responsibility for each team. The cost of forming new teams and the impact of switching context is often overlooked. It's important to note that the performance of an engineer can vary significantly depending on the team they are placed in.
Key Questions for Designing Teams
Organizations must consider several key questions when designing teams: What team topology will help deliver results faster and safer given our skills constraints, cultural and engineering maturity, desired software architecture, and business goals? How can we reduce or avoid handovers between teams in the main flow of change, and where should the boundaries be in the software system to preserve system viability and encourage rapid flow? How can our teams align to that design for flow of change organizations that build?
Spotify Model as an Example of Explicit Organizational Design
Spotify provides an example of explicit organizational design to improve the effectiveness of software delivery and operations. Technical staff at Spotify are arranged into small autonomous cross-functional squads, each with a long-term mission. These squads are grouped into tribes, which are affinity groupings of squads. Within a tribe, engineers with similar skills share practices through a chapter. Spotify also uses a more diffuse guild akin to a community of practice that can include people from across multiple tribes, chapters, and squads. Chapters and guilds are the glue that keeps the company together, providing economies of scale without sacrificing too much autonomy. They also use a spreadsheet to detect and track interdependencies between squads and tribes.
Shape Team Intercommunication for Flow and Sensing
Effective intercommunication within teams can enable flow and sensing. Delivery teams should be cross-functional with all the skills necessary to design, develop, test, deploy, and operate the system on the same team. Organizations that value information feedback from live production systems can improve their software more rapidly and develop a responsiveness to customers and users.
Automate and Evangelize Knowledge Sharing
Organizations should strive to automate and evangelize knowledge sharing. By doing so, they can embed best practices into the culture and make themselves obsolete along the way. For example, a DevOps team can evolve into a DevOps evangelist team pattern, working with the client to educate and enable individual project teams. They can automate development and operation steps, implement monitoring and alerting solutions, and execute automation themselves.
Four Fundamental Team Topologies
In an organization, there are four types of team topologies. Stream-aligned teams are oriented towards the main flow of business change and can deliver significant increments independently. Platform teams work on the underlying platform supporting stream-aligned teams in delivery, simplifying complex technology and reducing cognitive load. Enabling teams assist other teams in adopting and modifying software as part of a transition or learning. Complicated subsystem teams handle a subsystem that is too complicated to be dealt with by a normal stream-aligned team or platform team and is used only when necessary.
Stream-aligned Team
The stream-aligned team is the primary team type in an organization, responsible for a single valuable stream of work. This might be a single product, set of features, user journey or user. Such a team is funded in a long term and sustainable manner, and is empowered to build, deliver customer or user value quickly, safely and independently. A stream-aligned team works on the full spectrum of delivery, which makes them closer to the customer and able to quickly incorporate feedback from customers while monitoring their software in production.
Capabilities within a Stream-aligned Team
A stream-aligned team possesses a variety of capabilities, including application security, commercial and operational viability analysis, design and architecture, development and coding, infrastructure and operability, metrics and monitoring, product management and ownership, testing and quality assurance, and user experience (UX).
Behaviors and Outcomes of an Effective Stream-aligned Team
An effective stream-aligned team aims to produce a steady flow of feature delivery, is quick to course correct based on feedback, uses an experimental approach to product evolution, and has minimal handoffs of work to other teams. It is evaluated on the sustainable flow of change and produces, together with some supporting technical and team Health Metrics. A stream-aligned team must have time and space to address code quality changes, sometimes called Tech debt to ensure that changing the code remains safe and easy to do.
Amazon Case Study
In 2002, Jeff Bezos sent a mandate to the Amazon engineering division that set out very specific rules for team organization. Each team is solely responsible for developing and operating its own service, provided through an API. The teams are cross-functional and include all the required capabilities to manage, design, develop, test and operate their services. Amazon has been using this model for over 17 years, showing how effective it can be to align teams to independent streams of change.
Enabling teams
The mission of enabling teams is to help stream-aligned teams acquire missing capabilities, usually around a specific technical or product management. These teams are composed of specialists in a given technical or product domain, and they help a stream-aligned team with end-to-end ownership. The end goal of an enabling team is to increase the autonomy of stream-aligned teams by growing their capabilities with a focus on their problems first, not the solutions per se.
Enabling Team versus Communities of Practice (CoP)
Enabling teams and communities of practice can help to increase awareness and capabilities within other teams. The members of an enabling team work on enabling activities full time, whereas a CoP is a more diffused grouping of interested individuals from across several teams with an aim to share practices and improve working methods on a weekly or monthly basis.
Complicated Subsystem Teams
A complicated subsystem team is responsible for building and maintaining a part of the system that depends heavily on specialist knowledge. The goal of this team is to reduce the cognitive load of stream aligned teams working on systems that include or use the complicated subsystem. Examples of complicated subsystems might include a video processing codec, a mathematical model, a real-time trade reconciliation algorithm, a transaction reporting system for financial services, or a face recognition engine.
Platform Team
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. Ease of use is fundamental for platform adoption and reflects the fact that platform teams must treat the services they offer as products that are reliable, usable and fit for purpose, regardless of if they are consumed by internal or external customers.
Expected Behaviors for a Platform Team
A platform team uses strong collaboration with stream-aligned teams to understand their needs, relies on fast prototyping techniques and involves stream-aligned team members for fast feedback on what works and what does not. A platform team has a strong focus on usability and reliability for their services, treating the platform as a product and regularly assesses if the services are still fit for purpose and usable.
A Good Platform is 'Just Big Enough'
A good platform provides standards, templates, APIs, and well-proven best practices for Dev teams to use to innovate rapidly and effectively. A good platform should make it easy for the teams to do the right things in the right way for the organization.
The Thinnest Viable Platform
The simplest platform is purely a list on a wiki page of underlying components or services used by consuming software. If those underlying components and services always work reliably, then there is no need for a full-time platform team. In all cases, we should aim for a thinnest viable platform (TVP) and avoid letting the platform dominate the discourse.
Support Teams
To have a single support team handling everything is a monolithic setup and not sustainable. Support should consist of cross-functional collaboration across multiple teams that swarm when necessary. When an incident occurs with the live production systems, these support teams initially attempt to resolve the problem within stream areas alone. If necessary, other stream-aligned support teams are brought in to help diagnose the problem and if the incident affects many teams, a dynamic swarm or incident squad of support specialists is formed from the various support teams to triage the problem and restore service as rapidly as possible.
Optimizing Team-First Boundaries
Optimizing for flow involves aligning software boundaries with team cognitive load, which means stream-aligned teams should be responsible for a single domain. This is challenging when domains are concealed within monolithic systems. These systems encompass various responsibilities and are mostly driven by technology choices, providing functionalities across multiple business areas. The goal is to find natural ways to divide the system along fracture planes, allowing the resulting parts, and their respective teams, to evolve independently. This grants teams greater autonomy and ownership.
Aligning Subsystem Boundaries with Business Segments
Aligning subsystem boundaries with independent business segments is an effective approach, supported by the domain driven design methodology. However, it's crucial to also identify other fracture planes, such as change cadence risk, regulatory compliance, etc. Often, a combination of fracture planes will be needed. Awareness of different types of monoliths is also necessary as they can hinder flow and create unnecessary dependencies between teams. Coupling can creep in subtly, even in a modular system architecture, through shared databases, coupled builds and releases, and more.
Defining Software Fracture Planes
When defining subsystem boundaries, the primary goal should be to delineate the software fracture planes aligning to business domain bounded contexts. These bounded contexts usually map to streams of change natural for the organization, meaning business domain boundaries can align with stream-aligned teams, promoting flow across the organization. Fracture planes can be chosen around specific challenges, such as technology, regulation, performance, geographic location of staff, user personas, etc. to avoid handoffs between teams and promote flow. It's essential to make software segments team-sized for effective ownership and evolution of their software in a sustainable way.
Impact of Team Division and Boundaries on Engineering Organization
How teams are divided and the boundaries created significantly influence the success of an engineering organization. Research shows that tightly coupled architectures negatively affect the capacity for autonomous teams with clear responsibilities. Architectural approaches that decouple these architectures, such as the use of bounded contexts and APIs, support teams' full ownership from design through to deployment. When moving from a monolithic software system to loosely coupled services, the impact of the new architecture on the teams involved must also be considered.
Challenges of Distributed Monolith
Factors like team cognitive capacity, their location, and their interest in the new services should be considered when moving to a more loosely coupled system. Without considering these factors, there's a risk of splitting the monolith in the wrong places or creating a complex system of interdependent services. This situation, known as a distributed monolith, results in teams lacking autonomy over their services as almost all changes require updates to other services.
Monolithic Thinking and Standardization
Monolithic thinking imposes a one-size-fits-all approach on teams, leading to unnecessary restrictions on technology and implementation approaches. Standardizing everything to minimize variation simplifies management oversight but comes at a high cost. It limits teams' freedom to choose the right tool for the job and can demotivate them. Enforcing standardization upon teams actually reduces learning and experimentation, leading to poor solution choices. For example, it's advisable to standardize the platform or CMS in learning tools, but content creation tools should be open for personalization.
Introduction to Team Interaction Modes
It is crucial for organizations to anticipate the evolution of team patterns to meet various needs such as business, organizational, market, technology, and personal. An ingenious experiment by researchers showed that groups whose members interacted intermittently had a quality of solutions nearly identical to those groups that interacted constantly, yet they preserved enough variation to find some of the best solutions. Thus, intermittent collaboration often gives the best results.
Three Essential Team Interaction Modes
These modes include Collaboration, X-as-a-service, and Facilitating. In Collaboration, two teams work closely together to discover new patterns, approaches, and limitations. X-as-a-service involves one team consuming a service or an API from another team. In Facilitating, one team helps another team to learn or adopt new approaches for a defined period of time. Any team interactions outside these three core modes are wasteful and indicative of poorly chosen team responsibility boundaries and poorly understood team purposes.
Collaboration Mode
Collaboration encourages rapid innovation and discovery with fewer handoffs. However, it has a wide shared responsibility for each team, leading to a higher cognitive load and possible reduced output during collaboration. It should be used when there is high value gained from working together, due to the high cost of collaboration. The reward needs to be tangible with little or no friction between teams. Basic collaboration skills such as pair programming, mob programming, and whiteboard sketching can be useful for teams interacting using this mode.
X-as-a-service Mode
X-as-a-service mode is suited to situations where there is a need for one or more teams to use a component, API, or platform that just works without much effort. The team providing the service must have a strong sense of responsibility toward both the consumers and the viability of the thing they are providing. It offers clarity of ownership with clear responsibility boundaries and reduced cognitive load. However, it may lead to slower innovation of the boundary or API and danger of reduced flow if the boundary or API is not effective.
Facilitating Mode
The facilitating mode is suited to situations where one or more teams would benefit from the active help of another team facilitating or coaching some aspect of their work. The facilitating team focuses on the quality of interactions between other teams building and running the software. While it helps unblock teams to increase flow and detect gaps and misaligned capabilities, it requires experienced staff to not work on building or running things and the interaction may be unfamiliar or strange to one or both teams involved in facilitation.
Importance of Consistent Experiences in Team Interactions
Humans work best with others when they can predict their behavior. Clear roles and responsibility boundaries help provide consistent experiences for others in the organization, thereby building trust and avoiding invisible electric fences. This is crucial in team interactions.
Platform Experience in Team Interactions
When a platform team is providing a set of dynamic cloud testing environments for a stream-aligned team, both teams should emphasize the experience of interacting with the environments. A focus on the experience of using the platform is essential for driving the best and most fruitful interaction between teams.
Role of Developer Advocates in Team Interactions
Developer advocates, like the ones in IBM, gather successful patterns from various teams around the world to encourage and educate others, helping the ideas to diffuse through the organization. It's crucial that developer advocates ensure they are not the blockers and that the services they offer can be self-serve and autonomous.
Evolving Team Structures
The constant change in technology, markets, customer demands, and regulatory requirements necessitates regular adaptation and evolution of organizational structures. Organizations running software systems should ensure that their team interactions are optimized for flow, adhere to Conway's Law, and adopt a team-first approach. This includes considering team cognitive load and implementing the four fundamental team topologies along with the three core team interaction modes. This approach fosters a clear understanding of each team's purpose, how and when they should collaborate with other teams, and how to adapt to the provision or consumption of services, or facilitation with other teams. The combination of well-defined teams and interaction modes offers a flexible organizational capability for structural adaptation to changing conditions, enabling the organization to sense its environment and adjust its activities accordingly.
Local Optimization
Over time, understanding of the codebase within a product team can become specialized, leading to certain team members being routinely assigned to specific components or workflows. While this local optimization can expedite delivery, it can also create bottlenecks and affect the team's overall workflow if planning is dictated by expertise rather than priority. This level of specialization, as explained in the Phoenix Project and the DevOps handbook, can also negatively impact individual motivation. The question arises whether local optimization exists in the DevEd team.
Organizational Sensing
Organizational sensing uses teams and their communication as the organization's senses. Similar to living organisms, organizations need well-defined and stable communication pathways to effectively sense and make sense of things. Teams can detect signals from across the organization and outside it, making the organization akin to an organism. For example, Facebook's TPM includes sensing as part of their job requirement, which heavily ties into communication streams.
Organizational Sensing Questions
Organizational sensing involves asking questions such as: Have we misunderstood how users need/want to behave? Do we need to change team interaction modes to enhance how the organization is working? Should we still be building thing X in-house, or should we be renting it from an external provider? Is the close collaboration between Team A and Team B still effective? Should we move toward an 'x as a service' model? What hampers the flow of work for Team C? Does the platform for Teams D, E, F, and G provide everything those teams need? Is an enabling team needed for a period of time? Are the promises between these two teams still valid and achievable? What needs to change to make the promises more realistic?
Introduction to Team Topologies
Team topologies are a team-first approach to software delivery that address issues in software delivery. They are based on four fundamental team types, three team interaction patterns, and methods of using delivery difficulties to enable the organization to sense its environment.
Getting Started with Team Topologies
To start with team topologies, the initial step is to focus on the team. The organization should ask questions about what the team needs to function effectively, manage a portion of the software, meet user needs, reduce unnecessary cognitive load, and interact with other teams in terms of software and information exchange.
Identifying Streams of Change
The next step in implementing team topologies involves identifying suitable streams of change. These are areas where changes can be made to improve the overall functioning and efficiency of the team.
Defining a Thinnest Viable Platform
A critical part of implementing team topologies is identifying a thinnest viable platform (TVP). The TVP is the minimum set of services and tools that a team needs to operate effectively.
Addressing Capability Gaps
Part of implementing team topologies involves identifying and addressing capability gaps in areas such as team coaching, mentoring, service management, and documentation. These are areas where the team may need additional resources or training to function effectively.
Practicing Interaction Modes
The final step in implementing team topologies involves sharing and practicing different interaction modes. This involves explaining the principles behind new ways of working and ensuring that all team members are comfortable with these new methods.
FAQs
What is Team Topologies? Team Topologies is a methodology that helps organizations understand and adapt their team structures to improve software delivery. It provides a framework for visualizing the interconnections between different teams, and how information flows between them.
How can Team Topologies be applied in Developer Education? In Developer Education, Team Topologies can be used to enhance the learning experience of developers by understanding the structure and dynamics of the team, designing effective learning strategies, creating customized training programs, and promoting peer learning.
What is the impact of Conway's Law on Developer Education? Conway's Law, which states that an organization's design will mirror its communication structure, can affect Developer Education. This can be challenging if there are multiple learning teams within the organization. Leaders need to consider the cognitive load of their team and manage it effectively.
What is the Reverse Conway Maneuver in Developer Education? The Reverse Conway Maneuver in Developer Education involves restructuring the organization to mirror the desired communication patterns. It's also crucial to control the flow of communication to reduce noise and increase output.
Why is team-first thinking and diversity important in Developer Education? A team-first approach and diversity are critical in Developer Education as they take into account the cognitive load of developers and focus on defining the team's 'API' and facilitating interactions that build trust, awareness, and learning, rather than teaching things that can be automated.
How are effective teams designed for Developer Education? Effective teams for Developer Education are designed by automating and evangelizing knowledge sharing, and understanding the roles of different types of teams: stream-aligned, complicated subsystem, enabling, and platform. Developer Education is classified as an Enabling Team.
What are the engagement models in Developer Education? Developer Education employs various engagement models such as collaboration, X-as-a-service, and facilitation. As an enablement team, Developer Education predominantly uses the facilitation model.
What is the role of Developer Advocates in Developer Education? Members of the Developer Education team act as full-time developer advocates. Their role is to provide support and facilitate learning, thereby enabling developers to deliver working software in a sustainable, responsible way.
What is the misconception of organizational charts? Organizational charts often fail to accurately depict how work is conducted and how teams interact. They are incompatible with the dynamic nature of modern workplaces, characterized by frequent team reshuffling and collaborative knowledge work in uncertain environments.
Why should System Thinking be adopted over org charts? System Thinking emphasizes optimizing the overall work process, identifying and eliminating bottlenecks, and setting up dynamic team structures and interaction modes that help teams quickly adapt to new conditions and ensure safe software delivery.
What does Niels Pflaeging's book 'Organize for Complexity' suggest about organizational structures? Niels Pflaeging identifies three organizational structures: formal structure chart (for compliance), informal structure (influence between individuals), and value creation structure (how work gets done based on reputation). The key to successful knowledge work organizations lies in the interactions between the informal and value creation structures.
What is the importance of considering cognitive load in a team setting? Ignoring cognitive load can lead to teams being overstretched across multiple responsibilities and domains, hindering their ability to master their trade due to constant context switching. This can demotivate the team and disrupt intrinsic motivation aspects such as autonomy, mastery, and purpose.
What is Conway's Law and how can it be applied advantageously? Conway's Law suggests that the communication paths within an organization control the types of solutions that can be created. The Reverse Conway Maneuver involves reconfiguring team intercommunications to increase the chances of building effective software systems optimized for flow of value.
How does Conway's Law impact Developer Education? In Developer Education, using the reverse Conway maneuver would require a DevEd person embedded into each team. Since this is usually not feasible, resources on the team need to be allocated to facilitate the creation of solution-specific training.
What is the impact of HR decisions on software architecture? Decisions about the shape and placement of engineering teams strongly influence the software systems architecture. Managers who decide which services will be built by which teams indirectly decide on the system architecture.
What is the importance of communication balance in organizations? While increasing communication is not always beneficial, focused communication that addresses the cause of unexpected communications is important. Organizations should aim for low or zero bandwidth communication between teams, especially in areas where execution prevails over discovery.
How do communication tools impact enterprise architecture? The choice and use of software communication tools can significantly influence communication patterns between teams. The choice of tools must consider team interrelationships and encourage team-scoped flow.
What is the role of team-first thinking in developer education leadership? Leadership in developer education should prioritize team dynamics over individual performance. Work should be assigned to teams, not individuals. The size of the team should be limited to foster trust and innovation.
How does Dunbar's number influence team size? Dunbar's number, a theoretical limit to the number of people one can maintain stable social relationships with, should influence the size of team groupings.
What are the best practices using Dunbar's number? A single team should ideally consist of five to eight people, with no more than 15 people in high trust organizations. Larger groupings should not exceed 50 people in high trust organizations, and 150 people in total.
What is the Tuckerman Teal Performance Model and its limitations? The Tuckerman Teal Performance Model describes team performance in four stages (forming, storming, norming, and performing). However, it's found to be inaccurate as 'storming' or working through differences, occurs continually throughout the life of a team, not just in the initial stages.
What is the importance of team-first thinking in Developer Education members? Members of Developer Education should prioritize team goals over individual goals. This includes arriving for meetings on time, helping unblock other team members before starting new work, and mentoring less experienced team members.
Why is diversity valuable in Developer Education teams? Diverse teams tend to produce more creative solutions and are better at empathizing with other teams' needs. A diverse mix of people also fosters better results as team members make fewer assumptions about the software users' context and needs.
What is cognitive load and how should it be managed in Developer Education? Cognitive load refers to the total amount of mental effort being used in the working memory. Developer Education should respect the finite cognitive capacity of developers and manage their cognitive load effectively.
Why is automation important in developer education? Automation is important in developer education as it helps to minimize intrinsic cognitive load through training and eliminate extraneous cognitive load. This means tasks or commands that add little value to the working memory can be automated, leaving more space for germane cognitive load, where value-adding thinking lies.
How can cognitive load be reduced in a team? Cognitive load can be reduced by limiting the number and type of domains per team, breaking down a team into micro-teams with a clear mission, and prioritizing how the responsible team feels about the complexity of a domain. Domains can be classified into simple, complicated, or complex, and assigned to teams accordingly.
How can a team maximize their cognitive capacity? Teams can maximize their cognitive capacity by providing a team-first working environment, minimizing distractions, changing the management style to focus on goals and outcomes, improving the quality of developer experience, and using a platform designed to reduce cognitive load.
What is a 'Team API' in Developer Education? A 'Team API' in Developer Education includes how engineering teams can interact with your team, and the actual APIs of learning materials and knowledge repositories. This API should be continuously defined, advertised, tested, and evolved to ensure it is fit for purpose.
How can Developer Education facilitate interactions between different teams? Developer Education can facilitate interactions between different teams to build trust, increase awareness, and promote learning. This can be achieved through a consciously designed physical and virtual environment, and time away from desks at guilds, communities of practice, internal tech conferences, and evening meetups.
What is the importance of deliberate team design? To maximize effectiveness, teams should be consciously designed rather than formed accidentally or haphazardly. These intentionally formed teams are referred to as 'team topologies', which acknowledges the deliberate placement of teams within the organization and defines the boundary of responsibility for each team.
What are the key questions for designing teams? Organizations must consider several key questions when designing teams, including what team topology will help deliver results faster and safer given our skills constraints, cultural and engineering maturity, desired software architecture, and business goals, how can we reduce or avoid handovers between teams in the main flow of change, and where should the boundaries be in the software system to preserve system viability and encourage rapid flow?
What is the Spotify model of organizational design? Spotify provides an example of explicit organizational design to improve the effectiveness of software delivery and operations. Technical staff at Spotify are arranged into small autonomous cross-functional squads, each with a long-term mission. These squads are grouped into tribes, which are affinity groupings of squads. Within a tribe, engineers with similar skills share practices through a chapter.
How can effective intercommunication within teams enable flow and sensing? Effective intercommunication within teams can enable flow and sensing. Delivery teams should be cross-functional with all the skills necessary to design, develop, test, deploy, and operate the system on the same team. Organizations that value information feedback from live production systems can improve their software more rapidly and develop a responsiveness to customers and users.
Why should organizations automate and evangelize knowledge sharing? Organizations should strive to automate and evangelize knowledge sharing to embed best practices into the culture and make themselves obsolete along the way. For example, a DevOps team can evolve into a DevOps evangelist team pattern, working with the client to educate and enable individual project teams.
What are the four fundamental team topologies in an organization? In an organization, there are four types of team topologies. Stream-aligned teams are oriented towards the main flow of business change and can deliver significant increments independently. Platform teams work on the underlying platform supporting stream-aligned teams in delivery, simplifying complex technology and reducing cognitive load. Enabling teams assist other teams in adopting and modifying software as part of a transition or learning. Complicated subsystem teams handle a subsystem that is too complicated to be dealt with by a normal stream-aligned team or platform team and is used only when necessary.
What is a stream-aligned team? The stream-aligned team is the primary team type in an organization, responsible for a single valuable stream of work. This might be a single product, set of features, user journey or user. Such a team is funded in a long term and sustainable manner, and is empowered to build, deliver customer or user value quickly, safely and independently.
What capabilities does a stream-aligned team possess? A stream-aligned team possesses a variety of capabilities, including application security, commercial and operational viability analysis, design and architecture, development and coding, infrastructure and operability, metrics and monitoring, product management and ownership, testing and quality assurance, and user experience (UX).
What are the behaviors and outcomes of an effective Stream-aligned Team? An effective stream-aligned team aims to produce a steady flow of feature delivery, is quick to course correct based on feedback, uses an experimental approach to product evolution, and has minimal handoffs of work to other teams.
What is the mission of enabling teams? The mission of enabling teams is to help stream-aligned teams acquire missing capabilities, usually around a specific technical or product management.
What is the difference between enabling teams and communities of practice? The members of an enabling team work on enabling activities full time, whereas a CoP is a more diffused grouping of interested individuals from across several teams with an aim to share practices and improve working methods on a weekly or monthly basis.
What is a complicated subsystem team? A complicated subsystem team is responsible for building and maintaining a part of the system that depends heavily on specialist knowledge.
What is the purpose of a platform team? The purpose of a platform team is to enable stream-aligned teams to deliver work with substantial autonomy.
What are the expected behaviors for a platform team? A platform team uses strong collaboration with stream-aligned teams to understand their needs, relies on fast prototyping techniques and involves stream-aligned team members for fast feedback on what works and what does not.
What is a good platform? A good platform provides standards, templates, APIs, and well-proven best practices for Dev teams to use to innovate rapidly and effectively.
What is the Thinnest Viable Platform? The simplest platform is purely a list on a wiki page of underlying components or services used by consuming software. In all cases, we should aim for a thinnest viable platform (TVP) and avoid letting the platform dominate the discourse.
What is the role of support teams? Support should consist of cross-functional collaboration across multiple teams that swarm when necessary. When an incident occurs with the live production systems, these support teams initially attempt to resolve the problem within stream areas alone. If necessary, other stream-aligned support teams are brought in to help diagnose the problem.
What does optimizing for flow involve in software boundaries? Optimizing for flow involves aligning software boundaries with team cognitive load, meaning stream-aligned teams should be responsible for a single domain.
What is the goal of dividing a system along fracture planes? The goal is to find natural ways to divide the system along fracture planes, allowing the resulting parts, and their respective teams, to evolve independently.
What is the primary goal when defining subsystem boundaries? The primary goal should be to delineate the software fracture planes aligning to business domain bounded contexts.
How does team division and boundaries impact an engineering organization? How teams are divided and the boundaries created significantly influence the success of an engineering organization. Tightly coupled architectures negatively affect the capacity for autonomous teams with clear responsibilities.
What is a distributed monolith? A distributed monolith is a situation where there's a risk of splitting the monolith in the wrong places or creating a complex system of interdependent services. This results in teams lacking autonomy over their services as almost all changes require updates to other services.
What is the impact of monolithic thinking and standardization? Monolithic thinking imposes a one-size-fits-all approach on teams, leading to unnecessary restrictions on technology and implementation approaches. Standardizing everything simplifies management oversight but limits teams' freedom to choose the right tool for the job and can demotivate them.
What are the three essential team interaction modes? The three essential team interaction modes are Collaboration, X-as-a-service, and Facilitating.
What is the Collaboration mode in team interaction? In Collaboration mode, two teams work closely together to discover new patterns, approaches, and limitations. It encourages rapid innovation and discovery with fewer handoffs, but has a wide shared responsibility for each team, leading to a higher cognitive load and possible reduced output during collaboration.
What is X-as-a-service mode? X-as-a-service mode is suited to situations where there is a need for one or more teams to use a component, API, or platform that just works without much effort. The team providing the service must have a strong sense of responsibility toward both the consumers and the viability of the thing they are providing. It offers clarity of ownership with clear responsibility boundaries and reduced cognitive load.
What is facilitating mode? The facilitating mode is suited to situations where one or more teams would benefit from the active help of another team facilitating or coaching some aspect of their work. The facilitating team focuses on the quality of interactions between other teams building and running the software.
Why is it important to have consistent experiences in team interactions? Clear roles and responsibility boundaries help provide consistent experiences for others in the organization, thereby building trust and avoiding invisible electric fences. This is crucial in team interactions.
What is the role of Developer Advocates in team interactions? Developer advocates, like the ones in IBM, gather successful patterns from various teams around the world to encourage and educate others, helping the ideas to diffuse through the organization.
What is the importance of evolving team structures? The constant change in technology, markets, customer demands, and regulatory requirements necessitates regular adaptation and evolution of organizational structures. Organizations running software systems should ensure that their team interactions are optimized for flow, adhere to Conway's Law, and adopt a team-first approach.
What is local optimization? Over time, understanding of the codebase within a product team can become specialized, leading to certain team members being routinely assigned to specific components or workflows. While this local optimization can expedite delivery, it can also create bottlenecks and affect the team's overall workflow.
What is organizational sensing? Organizational sensing uses teams and their communication as the organization's senses. Similar to living organisms, organizations need well-defined and stable communication pathways to effectively sense and make sense of things.
What are team topologies? Team topologies are a team-first approach to software delivery that address issues in software delivery. They are based on four fundamental team types, three team interaction patterns, and methods of using delivery difficulties to enable the organization to sense its environment.
How to get started with team topologies? To start with team topologies, the initial step is to focus on the team. The organization should ask questions about what the team needs to function effectively, manage a portion of the software, meet user needs, reduce unnecessary cognitive load, and interact with other teams in terms of software and information exchange.
What are the streams of change in implementing team topologies? Identifying suitable streams of change is the next step in implementing team topologies. These are areas where changes can be made to improve the overall functioning and efficiency of the team.
What is a Thinnest Viable Platform in team topologies? A Thinnest Viable Platform (TVP) is the minimum set of services and tools that a team needs to operate effectively.
What does addressing capability gaps in team topologies involve? Addressing capability gaps in team topologies involves identifying and addressing areas such as team coaching, mentoring, service management, and documentation where the team may need additional resources or training to function effectively.
What does practicing interaction modes in team topologies entail? Practicing interaction modes in team topologies involves sharing and explaining the principles behind new ways of working and ensuring that all team members are comfortable with these new methods.
Glossary
Conway's Law: An organizational theory that states that an organization's design will mirror its communication structure, affecting the learning experience in Developer Education.
Empowering Engineers through Developer Education: A focus in Developer Education on enabling teams to adapt quickly to new conditions by understanding the informal structure within the company and identifying where value is created.
Engagement Models in Developer Education: Various models such as collaboration, X-as-a-service, and facilitation used by Developer Education to engage learners and provide consistent experiences.
Reverse Conway Maneuver: A strategy used in Developer Education to overcome the constraints of Conway's Law by restructuring the organization to mirror the desired communication patterns.
System Thinking: An approach emphasizing optimizing the overall work process, identifying and eliminating bottlenecks, setting up dynamic team structures and interaction modes that help teams quickly adapt to new conditions and ensure safe software delivery.
Team Topologies: A methodology that helps organizations understand and adapt their team structures to improve software delivery by providing a framework for visualizing the interconnections between different teams, and how information flows between them.
Team-First Thinking and Diversity in Developer Education: A critical aspect of Developer Education that emphasizes a team-first approach and fostering diversity, taking into account the cognitive load of developers and facilitating interactions that build trust, awareness, and learning.
The Misconception of Organizational Charts: The idea that traditional organizational charts often fail to accurately depict how work is conducted and how teams interact in modern workplaces.
Cognitive Load: Refers to the total amount of mental effort being used in the working memory. It encompasses intrinsic cognitive load (task fundamentals), extraneous cognitive load (environment in which the task is done) and germane cognitive load (aspects of the task that need special attention). Ignoring cognitive load can lead to teams being overstretched across multiple responsibilities and domains, hindering their ability to master their trade due to constant context switching.
Conway's Law: Suggests that the communication paths within an organization control the types of solutions that can be created. Decisions about the shape and placement of engineering teams strongly influence the software systems architecture.
Dunbar's Number: A theoretical limit to the number of people one can maintain stable social relationships with, should influence the size of team groupings. This number suggests limits to close personal relationships (five people), deep trust relationships (15 people), mutual trust relationships (50 people), and the limit of people whose capabilities we can remember (150 people).
HR's Impact on Software Architecture: Conway's law implies that decisions about the shape and placement of engineering teams strongly influence the software systems architecture. Managers who decide which services will be built by which teams indirectly decide on the system architecture. Therefore, it is crucial for HR departments and leaders who allocate budgets across teams to understand the potential effects of their choices on the software architecture.
The Balance of Communication in Organizations: Increasing communication is not always beneficial. What's more important is focused communication that addresses the cause of unexpected communications. Organizations should aim for low or zero bandwidth communication between teams, especially in areas where execution prevails over discovery.
The Influence of Dunbar's Number on Team Size: Dunbar's number, a theoretical limit to the number of people one can maintain stable social relationships with, should influence the size of team groupings. This number suggests limits to close personal relationships (five people), deep trust relationships (15 people), mutual trust relationships (50 people), and the limit of people whose capabilities we can remember (150 people).
The Importance of Team-First Thinking in Developer Education Members: Members of Developer Education should prioritize team goals over individual goals. This includes arriving for meetings on time, helping unblock other team members before starting new work, and mentoring less experienced team members. Accomplishments should be attributed to the team as a whole, not to individual members.
The Value of Diversity in Developer Education Teams: Diverse teams tend to produce more creative solutions and are better at empathizing with other teams' needs. A diverse mix of people also fosters better results as team members make fewer assumptions about the software users' context and needs. Heterogeneity can aid in creating a cohesive team and discovering new possibilities.
Tuckerman Teal Performance Model: Describes team performance in four stages (forming, storming, norming, and performing), has been found to be inaccurate in recent years. This is because 'storming' or working through differences, occurs continually throughout the life of a team, not just in the initial stages.
Understanding and Managing Cognitive Load in Developer Education: Cognitive load refers to the total amount of mental effort being used in the working memory. Developer Education should respect the finite cognitive capacity of developers and manage their cognitive load effectively.
Automation: Tasks or commands that add little value to the working memory should be automated, leaving more space for germane cognitive load, where value-adding thinking lies.
Cognitive Load: The total amount of mental effort being used in the working memory.
Domains: Particular areas of knowledge or activity.
Team API: How engineering teams can interact with your team, and the actual APIs of learning materials and knowledge repositories.
Team Interactions: The process of teams communicating and working together to build trust, increase awareness, and promote learning.
Physical and Virtual Environments: Spaces, either physical or digital, where team interactions occur.
Deliberate Team Design: The intentional formation and organization of teams within a company.
Team Topologies: The placement of teams within the organization and the defined boundaries of responsibility for each team.
Spotify Model: An example of explicit organizational design where technical staff are arranged into small autonomous cross-functional squads, grouped into tribes, and share practices through a chapter.
Intercommunication: The exchange of information between individuals or teams.
Knowledge Sharing: The exchange of information, skills, or expertise among individuals or teams.
Four Fundamental Team Topologies: Stream-aligned teams, platform teams, enabling teams, and complicated subsystem teams.
Amazon Case Study: In 2002, Jeff Bezos sent a mandate to the Amazon engineering division that set out very specific rules for team organization. Each team is solely responsible for developing and operating its own service, provided through an API. The teams are cross-functional and include all the required capabilities to manage, design, develop, test and operate their services. Amazon has been using this model for over 17 years, showing how effective it can be to align teams to independent streams of change.
Behaviors and Outcomes of an Effective Stream-aligned Team: An effective stream-aligned team aims to produce a steady flow of feature delivery, is quick to course correct based on feedback, uses an experimental approach to product evolution, and has minimal handoffs of work to other teams. It is evaluated on the sustainable flow of change and produces, together with some supporting technical and team Health Metrics. A stream-aligned team must have time and space to address code quality changes, sometimes called Tech debt to ensure that changing the code remains safe and easy to do.
Capabilities within a Stream-aligned Team: A stream-aligned team possesses a variety of capabilities, including application security, commercial and operational viability analysis, design and architecture, development and coding, infrastructure and operability, metrics and monitoring, product management and ownership, testing and quality assurance, and user experience (UX).
Complicated Subsystem Teams: A complicated subsystem team is responsible for building and maintaining a part of the system that depends heavily on specialist knowledge. The goal of this team is to reduce the cognitive load of stream aligned teams working on systems that include or use the complicated subsystem. Examples of complicated subsystems might include a video processing codec, a mathematical model, a real-time trade reconciliation algorithm, a transaction reporting system for financial services, or a face recognition engine.
Enabling teams: The mission of enabling teams is to help stream-aligned teams acquire missing capabilities, usually around a specific technical or product management. These teams are composed of specialists in a given technical or product domain, and they help a stream-aligned team with end-to-end ownership. The end goal of an enabling team is to increase the autonomy of stream-aligned teams by growing their capabilities with a focus on their problems first, not the solutions per se.
Enabling Team versus Communities of Practice (CoP): Enabling teams and communities of practice can help to increase awareness and capabilities within other teams. The members of an enabling team work on enabling activities full time, whereas a CoP is a more diffused grouping of interested individuals from across several teams with an aim to share practices and improve working methods on a weekly or monthly basis.
Expected Behaviors for a Platform Team: A platform team uses strong collaboration with stream-aligned teams to understand their needs, relies on fast prototyping techniques and involves stream-aligned team members for fast feedback on what works and what does not. A platform team has a strong focus on usability and reliability for their services, treating the platform as a product and regularly assesses if the services are still fit for purpose and usable.
A Good Platform is 'Just Big Enough': A good platform provides standards, templates, APIs, and well-proven best practices for Dev teams to use to innovate rapidly and effectively. A good platform should make it easy for the teams to do the right things in the right way for the organization.
Platform Team: 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. Ease of use is fundamental for platform adoption and reflects the fact that platform teams must treat the services they offer as products that are reliable, usable and fit for purpose, regardless of if they are consumed by internal or external customers.
Stream-aligned Team: The stream-aligned team is the primary team type in an organization, responsible for a single valuable stream of work. This might be a single product, set of features, user journey or user. Such a team is funded in a long term and sustainable manner, and is empowered to build, deliver customer or user value quickly, safely and independently. A stream-aligned team works on the full spectrum of delivery, which makes them closer to the customer and able to quickly incorporate feedback from customers while monitoring their software in production.
Support Teams: To have a single support team handling everything is a monolithic setup and not sustainable. Support should consist of cross-functional collaboration across multiple teams that swarm when necessary. When an incident occurs with the live production systems, these support teams initially attempt to resolve the problem within stream areas alone. If necessary, other stream-aligned support teams are brought in to help diagnose the problem and if the incident affects many teams, a dynamic swarm or incident squad of support specialists is formed from the various support teams to triage the problem and restore service as rapidly as possible.
The Thinnest Viable Platform: The simplest platform is purely a list on a wiki page of underlying components or services used by consuming software. If those underlying components and services always work reliably, then there is no need for a full-time platform team. In all cases, we should aim for a thinnest viable platform (TVP) and avoid letting the platform dominate the discourse.
Optimizing Team-First Boundaries: Process of aligning software boundaries with team cognitive load, meaning that stream-aligned teams should be responsible for a single domain. This allows teams to evolve independently, granting them greater autonomy and ownership.
Aligning Subsystem Boundaries with Business Segments: An approach that involves aligning subsystem boundaries with independent business segments. It also involves identifying other fracture planes, such as change cadence risk, regulatory compliance, etc. to optimize the system.
Defining Software Fracture Planes: The process of delineating the software fracture planes aligning to business domain bounded contexts. This promotes flow across the organization and allows teams to effectively own and evolve their software.
Impact of Team Division and Boundaries on Engineering Organization: The way teams are divided and the boundaries created can significantly influence the success of an engineering organization. Decoupled architectures, such as the use of bounded contexts and APIs, support teams' full ownership from design through to deployment.
Challenges of Distributed Monolith: A situation where a system is split without considering factors like team cognitive capacity, their location, and their interest in the new services. This results in teams lacking autonomy over their services as almost all changes require updates to other services.
Monolithic Thinking and Standardization: An approach that imposes a one-size-fits-all on teams, leading to unnecessary restrictions on technology and implementation approaches. While it simplifies management oversight, it limits teams' freedom to choose the right tool for the job and can demotivate them.
Introduction to Team Interaction Modes: The concept that organizations should anticipate the evolution of team patterns to meet various needs. Intermittent collaboration often gives the best results.
Three Essential Team Interaction Modes: These modes include Collaboration, X-as-a-service, and Facilitating. They define how teams interact with each other and contribute to the overall flow and productivity of the organization.
Collaboration Mode: A team interaction mode that encourages rapid innovation and discovery with fewer handoffs. However, it leads to a higher cognitive load and possible reduced output during collaboration. It should be used when there is high value gained from working together.
Evolving Team Structures: The constant change in technology, markets, customer demands, and regulatory requirements necessitates regular adaptation and evolution of organizational structures. This includes considering team cognitive load and implementing the four fundamental team topologies along with the three core team interaction modes.
Facilitating Mode: The facilitating mode is suited to situations where one or more teams would benefit from the active help of another team facilitating or coaching some aspect of their work. While it helps unblock teams to increase flow and detect gaps and misaligned capabilities, it requires experienced staff to not work on building or running things and the interaction may be unfamiliar or strange to one or both teams involved in facilitation.
Getting Started with Team Topologies: To start with team topologies, the initial step is to focus on the team. The organization should ask questions about what the team needs to function effectively, manage a portion of the software, meet user needs, reduce unnecessary cognitive load, and interact with other teams in terms of software and information exchange.
Identifying Streams of Change: The next step in implementing team topologies involves identifying suitable streams of change. These are areas where changes can be made to improve the overall functioning and efficiency of the team.
Importance of Consistent Experiences in Team Interactions: Humans work best with others when they can predict their behavior. Clear roles and responsibility boundaries help provide consistent experiences for others in the organization, thereby building trust and avoiding invisible electric fences. This is crucial in team interactions.
Introduction to Team Topologies: Team topologies are a team-first approach to software delivery that address issues in software delivery. They are based on four fundamental team types, three team interaction patterns, and methods of using delivery difficulties to enable the organization to sense its environment.
Local Optimization: Over time, understanding of the codebase within a product team can become specialized, leading to certain team members being routinely assigned to specific components or workflows. This level of specialization, as explained in the Phoenix Project and the DevOps handbook, can also negatively impact individual motivation.
Organizational Sensing: Organizational sensing uses teams and their communication as the organization's senses. Teams can detect signals from across the organization and outside it, making the organization akin to an organism.
Organizational Sensing Questions: Organizational sensing involves asking questions such as: Have we misunderstood how users need/want to behave? Do we need to change team interaction modes to enhance how the organization is working? Should we still be building thing X in-house, or should we be renting it from an external provider? Is the close collaboration between Team A and Team B still effective? Should we move toward an 'x as a service' model? What hampers the flow of work for Team C? Does the platform for Teams D, E, F, and G provide everything those teams need? Is an enabling team needed for a period of time? Are the promises between these two teams still valid and achievable? What needs to change to make the promises more realistic?
Platform Experience in Team Interactions: When a platform team is providing a set of dynamic cloud testing environments for a stream-aligned team, both teams should emphasize the experience of interacting with the environments. A focus on the experience of using the platform is essential for driving the best and most fruitful interaction between teams.
Role of Developer Advocates in Team Interactions: Developer advocates, like the ones in IBM, gather successful patterns from various teams around the world to encourage and educate others, helping the ideas to diffuse through the organization. It's crucial that developer advocates ensure they are not the blockers and that the services they offer can be self-serve autonomous.
X-as-a-service Mode: X-as-a-service mode is suited to situations where there is a need for one or more teams to use a component, API, or platform that just works without much effort. The team providing the service must have a strong sense of responsibility toward both the consumers and the viability of the thing they are providing. It offers clarity of ownership with clear responsibility boundaries and reduced cognitive load. However, it may lead to slower innovation of the boundary or API and danger of reduced flow if the boundary or API is not effective.
Addressing Capability Gaps: Part of implementing team topologies involves identifying and addressing capability gaps in areas such as team coaching, mentoring, service management, and documentation. These are areas where the team may need additional resources or training to function effectively.
Defining a Thinnest Viable Platform: A critical part of implementing team topologies is identifying a thinnest viable platform (TVP). The TVP is the minimum set of services and tools that a team needs to operate effectively.
Practicing Interaction Modes: The final step in implementing team topologies involves sharing and practicing different interaction modes. This involves explaining the principles behind new ways of working and ensuring that all team members are comfortable with these new methods.
