Using Shapes for Team Topologies Modeling

Welcome to the Team Topologies Modeling Shapes resource page!

Here, you will find everything you need to get started with Team Topologies modeling, including tips, guides, templates, and more. The practice of Team Topologies Modeling allows you to start exploring the obstacles of flow and sources of cognitive load, then identify ways to reduce or remove their effects by designing and testing a better team-of-teams organization.

Important Definitions & Considerations

First things first, these are really important aspects to consider before throwing your shapes on a board, table or in your favourite diagramming tool. Make sure you and your team review and understand the below before you start modeling.

Team Topologies Modeling Purpose

The modeling shapes are used for Team Interaction Modeling. The purpose is to understand and design a team-of-teams organization AND model the interactions between the teams inside in a very intentional/purposeful way, which delivers an accelerated flow of value to your customer/s.

Definitions & Key Assumptions

  • “Team” - “The team is the smallest entity of delivery within an organization and should be a stable group of 5 to 9 people working towards a shared goal as a unit."

  • Stable teams - Team Topologies relies on long-lived teams.

  • Team boundaries - each team should generally be aligned to one or more areas/subsystems of the business domain.

  • End-to-end responsibility - teams are responsible for the flow of value in a value stream.

  • A flow doesn’t include handoffs or interruptions - we get it isn’t always possible and we should always strive for flow.

  • Team Topologies Modeling should be viewed and applied using the following 2 lenses: 

    • Team Cognitive load 

    • Fast Flow of Value

Team Topologies Modeling is NOT

  • NOT another way to draw and org chart.

  • NOT about labelling or categorizing teams in different team types. We would have used the word “taxonomy” if that was the purpose.

Important considerations

  • Do it together - modeling alone is neither fun, nor useful. More importantly it never leads to real change and business impact.

  • The diagrams represent a certain point in time, a snapshot. Your organization evolves and the diagrams should be evolved too.

  • Create a shared understanding and establish a common language / vocabulary to discuss flow and value streams.

  • There is no target end state or perfect design. Team Topologies is about transition and evolution.

  • Refine and iterate, continuously - it is like Design Thinking - the more you apply it, the better the results.

  • Physical shapes or digital shapes - choose your tool, we have them both.

  • Results are limited if you don’t consider the three different aspects impacting the flow of value in your value streams:

    • The process design - think your Continuous Deliver, CI/CD design, DevOps processes, release processes. They need focus on flow.

    • The Architecture - decoupled architectures, considering Conway’s Law provide good ground for faster flow of value

    • The team-of-teams organization - this is what you are trying to design with the Team Topologies modeling and it won’t go far if the other two are not aligned and appropriate.

Diagraming Principles

Principle #1: Implied Flow of change from left to right.

There is always an implied flow of change from left to right in the diagram (with apologies to people more familiar with a right- to- left flow!).

Principle #2: Use the undefined team type to represent non- Team Topologies teams

If the teams do not currently have the traits or behaviours of the Team Topologies teams represent them using the "undefined team type"

Principle #3: If it helps, use a handover symbol to make handovers more obvious

If the teams do not currently have the traits or behaviours of the Team Topologies teams represent them using the "undefined team type"

Principle #4: No- hand offs for stream- aligned teams

If the teams do not currently have the traits or behaviours of the Team Topologies teams represent them using the "undefined team type"

Principle #5: Stream- aligned teams should not provide XaaS directly

Stream- aligned teams should generally never provide an X- as- a- Service directly. Instead, data or services from the Stream- aligned team should be made available "as a Service" via a platform of some kind.

Principle #6: X- as- a- Service or Collaboration crossing multiple teams

If an X- as- a- Service or Collaboration interaction crosses over multiple teams, it may be appropriate to use an black asterisk "*" to clarify which teams are interacting.

Principle #7: Collaboration should be short- lived and purposeful

Collaboration should be short- lived and purposeful. If the interaction is actually ongoing then represent it as a "undefined interaction" rather than collaboration.

Principle #8: The fractal nature of flow and teams

Platforms can be fractal in nature meaning similar patterns recur at progressively smaller scales. It is possible for a platform to depend upon other lower- level platforms.

Principle #9: Capture "as- is" and "to- be" evolutionary steps as snapshots 

Modifing the structure of an organization should be an incremental process, not a big bang approach. Consider each evolutionary step for the teams - what is their "as- is" and "to- be" evolution?

How to Get Started with Team Topologies Modeling

The following steps are described in more detail and tips in Team Interaction Modeling With Team Topologies.

We highly recommend taking 10 minutes to read the full article before you start. It will multiply by 10x the value you get out of this exercise.

STAGE A: Identify your current teams and map them to the fundamental team types & Interaction Types

Step A1: Identify your current teams.

At this stage, you can use the team classifications which are common in the industry, e.g. infra, component, tooling, architecture, support, etc.

Step A2: Evaluate how those existing teams may (or NOT) map to one of the four Fundamental Team Types from Team Topologies.

If some teams don’t map cleanly to the fundamental team types, use the “undefined team type”. This is a mark of an area of extra focus.

Step A3: Evaluate the flow of value (from idea/request to production) and check how teams map to it.

Do teams carry responsibility end-to-end OR do they hand work to each other on the path to production. Identify handovers, bottlenecks, places where your flow breaks, slows down or branches off. Mark clearly all bottlenecks, handovers.

Step A4: Evaluate the interactions between teams and assess them against one of the Team Topologies defined interactions.

When in doubt use undefined interactions. This is a mark of an area of extra focus. Also, mark clearly longer collaboration between teams. This is a mark for further analysis of the need of this interaction and how to do differently.

STAGE B: Defining first team evolution

Fix teams not mapping well to the Team Topologies types.

Siloed or functionally defined teams lead to handovers between teams. Fast flow requires an end-to-end flow without handovers with a team owning the flow end-to-end with all required capabilities available within the team.

If your teams already look like that, this phase of the design iteration serves as validation and won't take a lot of time.

Step B1: Reduce handovers by building small (5-9) end-to-end responsible and capable stream-aligned teams.

Step B2: Use a stream-aligned team shape and name your team.

For teams with larger responsibility, you can use a bigger shape of the same type, e.g. bigger stream-aligned team shape.

Step B3: Repeat till there are no undefined teams left.

STAGE C: Limit The Cognitive Load of each team

Your newly shaped stream-aligned teams may not be able to produce faster flow of value if their cognitive load is high and hard to manage by the team.

Our diagrams use some brain emoji to help you understand the logic of evaluation we apply.

Step C1: Evaluate cognitive load on the team.

Evolution from siloed to stream-aligned teams may take quite some time. You need to allow those new teams to form and get a grip of the value stream they are serving. This could take weeks, but you don't need to wait for this before evolving your design further.

You could simulate the transition by giving people on the team some time to have a conversation and understand what it would take to serve the value stream and identify points of friction, complexity, lack of knowledge, cognitive load they may need to deal with before being able to deliver appropriate flow of value. This could take from a few hours to a couple of days.

Identify the capabilities or other source of cognitive load and add a sticker on your stream aligned team to identify the source.

Remember: For teams with larger responsibility, you can use a bigger shape of the same type, e.g. bigger stream-aligned team shape

Step C2: Evaluate if a Platform Team help by providing some capability in an X-as-a-service mode

Step C3: Evaluate if some complicated process or technology component be handled by a Complicated Subsystem Team and providing it in an X-as-a-service mode.

Step C4: Evaluate if a missing/new complex part can be developed by a Complicated Subsystem Team temporarily interacting with the Stream-Aligned Team in collaboration mode to develop something fit-for-purpose, before moving to an X-as-a-service mode.

Step C5: Evaluate if cognitive load linked to lack of knowledge or insufficient/immature capability in the team can be reduced by temporarily adding an Enabling Team interacting with the Stream-Aligned Team through a facilitating mode.

Step C6: Keep sensing for the need to reevaluate the team-of-teams design if flow is slowing down, not fast enough for the business or teams show signs of high cognitive load.

Examples

You can find examples of real organizational designs mapped out in the Case Studies we publish on regular basis.

Diagramming Tools Templates

Available Templates:

Last but not least, have a look at how Matthew plots the physical shapes from Agile Stationery