Manuel Pais, InfoQ editor and co-author of Team Topologies: Organizing Business and Technology Teams for Fast Flow, recently spoke on a webcast organised by Capra Consulting. Aslak Ege and Ørjan Bøe Thygesen, respectively CEO and Team Leader at Capra consulting, joined Pais and spoke of their journey with Team Topologies. Capra had applied the topologies to “radically redesign” their teams from a hierarchical structure to being more stream aligned. They described a journey during COVID-19, which resulted in an intentional move to a flat structure, with measured improvements in alignment and employee NPS. We spoke with Pais to understand how Team Topologies can help businesses like Capra in the current climate.

Team Topologies provides a lens which can help structure an organisation for effective collaboration, autonomy, delivery focus and product alignment. Pais talked about how Agile’s dream of team autonomy was often challenged by the range of competencies required by an effective cross-functional team. His proposed solution was a “family of teams” empowered to be effective through intentional use of Team Topologies.

Thygesen explained how Capra restructured towards autonomous teams aligned with the stages in their value stream. He shared how one of Capra’s goals was to increase “autonomy and flexibility” in order to “make the company more robust and respond faster to change.” Ege spoke of how they “started with one or two teams” to learn “what needed to change before other teams were started.” He also described how the teams were autonomous, communication rich and aligned with organisational wide OKRs.

In another recent talk at QEDx 2021 titled Playing Tetris with Cognitive Load, Pais described how product teams aligned with a particular value stream require a “support system” of teams in order to maintain focus on their mission. He explained that product delivery is like a game of Tetris, where different competencies attempt to fit smoothly together, in order to ensure delivery of new features. Pais talked about how cross-functional teams are often seen to address this, yet this becomes a challenge “if you look at the broader picture of everything we expect modern software teams to know.” He describes a tension between the value of autonomy and challenge involved in ensuring all required competencies, saying:

There is a much wider range of skills required to not just build the product right, but build the right product. To actually discover what our customers need and therefore provide more value… Whether that’s in revenue or some other value that we’ll get for the organisation. Pais explained that many teams fell short of the full set of required competencies. This often resulted in incomplete autonomy, where teams would be forced to “take short cuts or do things in a rushed way.” He explained how such situations would often cost more in the long run and produce results which were “less fitting to the customer and organisation needs.” Pais explained how flow can be improved by designing teams to account for “cognitive load.” Team Topologies uses the idea of cognitive load as measured for the mental effort, competency and knowledge required of a team.

Pais described the book’s four topologies which enable “stream aligned” product teams to reduce cognitive load through off-loading onto a family of supporting teams. He described:

Platform Teams which service a value-line aimed at enabling product teams. Enabling Teams delivering and coaching required competencies and capabilities. Complicated Subsystem Teams which hide the cognitive load of complex domains behind low-cognitive load abstraction. The book described this with examples of teams providing specialist capabilities such as “real-time trade reconciliation” and “face-recognition.”

In 2020, InfoQ published a recording of a talk by Pais titled ‘Remote-First Team Interactions for Business and Technology Teams.’ The talk, delivered at Assurity Consulting’s Bringing the Future Forward fundraiser early in the pandemic, explained how the practices of Team Topologies can be applied to team collaboration in a remote context to avoid more pronounced dysfunction. Pais pointed out that chats and “virtual space” can “be set up for good interactions.” He explained that the larger a Slack or other virtual space is, “the harder it is going to be” for teams to find the “people they should be talking to.” Pais suggested using intentionally designed virtual spaces with clear naming conventions describing who is collaborating:

We should be thinking about how we set up our tools to promote good kinds of interactions. It’s actually good to force a limit on how many people we can have in each virtual space. For each slack we can think about what are the right channels? …Within the virtual spaces, having some easy to understand conventions increases discoverability and reduces cognitive load. We spoke with Pais to better understand team topologies and their importance in current times.

InfoQ: How can Team Topologies help companies adapt to pandemic related changes forced on them through external factors?

Manuel Pais: The ideas in Team Topologies help organizations deliberately think about different teams’ purposes (fundamental topologies), and how and when they should interact with each other (core interaction modes). Techniques like the Team API expose a team’s working practices, roadmap, and preferred communication patterns, among other aspects, to the teams around them, explicitly trying to reduce communication overhead and misaligned expectations such as teams expecting near real-time answers from other teams in chat tools.

In the current pandemic situation, but generally in a remote-first approach, having clear expectations on team interactions (when, why, and for how long) becomes critical since social networks and casual exchanges of information that happen in an office setting are no longer possible. Otherwise, we will tend to see silos become more entrenched, and conflicts intensified. Some organizations might double down on strict processes to manage team dependencies, but that will come at a cost of reduced team autonomy and performance.

We can and should track team dependencies to increase visibility and address unhealthy dependencies, ideally removing them or at least minimizing their impact on flow.

This team-first approach is an opportunity for organizations to achieve faster flow (and feedback) in a remote-first context, so the pandemic can become an accelerant in that sense. Let’s clarify the ways of working and interacting across teams whose importance we might have underestimated in the pre-pandemic in-office situation.

By the way, we’re actually finishing a Team Topologies workbook for remote teams that covers all these aspects. It will be published by IT Revolution as a free PDF initially.

InfoQ: Which of the four topologies presents the hardest challenge to implement?

Pais: Perhaps Enabling teams due to the lack of familiarity for senior technical staff to take on a teaching and mentoring role helping other teams bridge their capability gaps. Experts are used to execute critical work rather than help others learn. But everyone understands that certain areas of expertise often become a bottleneck in the delivery lifecycle if we always depend on the experts to execute the work - if you’ve read The Phoenix Project book you are surely thinking of the Brent character right now, right?

Experts as enablers tend to be a foreign idea also for managers. Further, because the success of these teams is measured by improvements on other teams’ capabilities (possibly measured by the key metrics from the Accelerate book), there’s a sense of lack of control by the experts and managers can’t calculate an exact ROI for those teams. It requires an understanding of the importance of an ecosystem of teams as the drivers for success, or a “team of teams” if you like.

That said, platform teams also often struggle with holding off big plans for developing tech and new services. They are keen to provide value to internal teams, but early on they need to focus on establishing a clear value proposition for those services and treat the platform as a product (Who exactly are our customers and user personas? What do they need? What is stopping them from adopting the platform?). We often see platform teams rushing to provide X-as-a-Service before enough collaboration and validation was done with the internal teams (platform customers) which can lead to a flood of requests for help and support using those services, which means they were not ready for overall adoption yet. The platform teams can get stuck in a situation where they are spending all their time firefighting and responding to support requests.

InfoQ: What differences have you seen in the application of Team Topologies between the remote and onsite teams?

Pais: Onsite teams sometimes wonder why they need to clarify interactions with other teams. In some organizations there’s an over reliance on processes to address team dependencies, sometimes tying together teams that would benefit from more autonomy. In other organizations, there’s an expectation that every team can just collaborate with any other team to “get things done”.

Teams new to remote work quickly understand that the main obstacles to fluid communication are not the tools, but clarifying ways of working and communicating. Inside the team at first, but quickly also across teams. What could be done before by walking up to a colleague on another team, now requires a coordination overhead that we need to tackle.

So, in a way, remote teams have a heightened understanding of the need to improve their interactions with other teams via techniques like the aforementioned Team API and core interaction patterns. It also helps them regain some autonomy (and time) by setting up their preferred communication patterns (How should other teams contact us? At what time of the day? When can they expect an answer?) and avoiding “Zoom fatigue” (where we’re trying to replace every face-to-face meeting onsite with video calls). This becomes especially important for teams with a strong support role, like platform teams.

InfoQ: How has your own thinking around Team Topologies evolved since the release of the book?

Pais: We’ve learned new useful patterns from companies adopting Team Topologies that we hadn’t necessarily considered when writing the book. For example, platform teams taking an enabling role as well since they are effectively experts in the domains that platform services help with, that could be for example monitoring, telemetry, infrastructure automation, and so on. Platform engineers can not only develop and support those internal services, but also help other teams understand good practices around that domain.

We’ve also seen the platform pattern adopted beyond the initial technical “infrastructure” (broadly speaking) services, to more business-specific services. For example, at Uswitch they have created a “consumer data” platform and an “affiliate marketing” platform after the success of the initial “cloud infrastructure” platform. The Uswitch industry example is available on our website.

InfoQ: Where do you see the topologies going from here?

Pais: Well, several people have confirmed to us that the Team Topologies patterns could be applied beyond IT. For example, self-service capabilities curated into a high usability/low friction platform is a general pattern that could be applied in many areas of an organization (think HR services, or Finance, etc) to increase self-sufficiency and accelerate outcomes for internal “customers” (read teams and individuals). We are starting to see initial adoption there, and hope to have some concrete examples to share in 2021!

Meanwhile, we have already documented several industry examples on our website of companies using Team Topologies patterns, and we will keep adding more as we hear and learn more ourselves. For example, Footasylum has a great story on how they combined Team Topologies with Wardley mapping.

Also, there’s considerable new thinking being done by people like Nick Tune on the intersection between Team Topologies and Domain-Driven Design, as both approaches take a sociotechnical view on systems and business development.

InfoQ: Where can our readers learn more?

Pais: There are free Team Topologies resources online and also specific resources for remote-first team interactions with Team Topologies. We also publish new conference/meetup talks on our Team Topologies YouTube channel, as well as short videos with answers to frequently asked questions.

We also offer in-depth live online training sessions on different aspects of Team Topologies. There’s also on-demand video training for people new to Team Topologies.

To stay informed when new industry examples or public training is available, subscribe to our newsletter or follow Team Topologies on Twitter or LinkedIn.

Ege ended his presentation by speaking of his pride in having successfully adopted Team Topologies during the pandemic:

I am also really proud of the fact that we have done this in the middle of a pandemic that we didn’t pause or cancel the change. We went on with it despite being locked at home and so far the results are very good.