Here are summary notes from the book https://teamtopologies.com/.
The four fundamental team topologies are:
Stream aligned: a team aligned to the main flow of business change, with cross-functional skills mix and the ability to deliver significant increments without waiting on another team.
Platform: a team that works on the underlying platform supporting stream-aligned teams in delivery. The platform simplifies otherwise complex technology and reduces cognitive load for teams that use it.
Enabling: a team that assists other teams in adopting and modifying software as part of a transition or learning period.
Complicated subsystem: a team with a special remit for a subsystem that is too complicated to be dealt with by a normal stream-aligned team or platform team. Optional and only used when really necessary.
The combination of these specific team types is all that’s needed for effective software delivery with fast flow. however, the interaction modes between these four fundamental team topologies are vitally important to understanding and nurturing effective software delivery.
Collaboration mode: two teams work together on a shared goal, particularly during the discovery of new technology or approaches. The overhead is valuable due to the rapid pace of learning.
X-as-a-Service mode: one team consumes something provided by another team (such as an AAPI, a tool, or a full software product). Collaboration is minimal.
Facilitating mode: one team (usually an enabling team) facilitates another team in learning or adopting a new approach.
Team interactions outside these three core interaction modes are wasteful and indicative of poorly chosen team responsibility boundaries and poorly understood team purposes.
Intrinsic cognitive load—relates to aspects of the task fundamental to the problem space (e.g., “What is the structure of a Java class?” “How do I create a new method?”)
example: knowledge of the computer language being used (on top of the fundamentals of programming)
minimize through training, good choice of technologies, hiring, pair programming, etc.
Extraneous cognitive load—relates to the environment in which the task is being done (e.g., “How do I deploy this component again?” “How do I configure this service?”)
example: details of the commands needed to instantiate a dynamic testing environment (which needs multiple hard-to-remember console commands)
eliminate altogether: boring or superfluous tasks or commands that add little value to retain in the working memory and can often be automated away
Germane cognitive load—relates to aspects of the task that need special attention for learning or high performance (e.g., “How should this service interact with the ABC service?”)
example: specific aspects of the business domain that the application developer is programming (such as an invoicing system or a video-processing algorithm)
more space for where the “value add” thinking lies
Not just the code as part of the team’s external API, but also its documentation, onboarding processes, interactions with other teams, etc.
Team structures must match the required software architecture or risk producing unintended designs. Restructuring teams and facilitating (or potentially deliberately limiting) communication between teams have a much better chance of building systems that work well in production and feel natural to evolve over time.