BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Enabling Effective Remote Working - Principles and Patterns from Team Topologies

Enabling Effective Remote Working - Principles and Patterns from Team Topologies

This item in japanese

Bookmarks

Key Takeaways

  • The COVID-19 pandemic has accelerated the adoption of remote and hybrid ways of working. Today, most organizations are doing some form of remote work.
  • This transition has revealed that most organizations adopted strategies that don’t explicitly consider the design of their organizational structures to address the challenges that remote work imposes. 
  • Remote working is about more than just starting to use Slack and Zoom and creating new policies and ways of working. It requires a more deliberate design of the organization structures, namely being more explicit on setting up teams and their interactions since these are more complex in remote settings.
  • Team Topologies provides several principles and patterns to approach team design and interactions, which can equally apply to design more effective remote team interactions.
  • To succeed in remote work, adopting a mindset of more deliberate and continuous design and evolution of teams' boundaries, dependencies, and purposeful interactions is essential. These structural elements enable better dynamics to improve organizations' ability to achieve higher levels of effectiveness in remote settings.

Structures for effective remote work team interactions

The COVID-19 pandemic has accelerated a trend that companies building software were already experimenting with for the last decade: organizations building software can operate effectively in remote settings. Remote allows for more flexibility; better work-life balance; avoids unnecessary commuting; allowing organizations to hire people from different locations, among many other advantages. Although nowadays many organizations seem to be moving towards a “hybrid setting” way of working, it is unquestionable that remote work is here to stay.  

Regardless of the format, one thing has become clear over the last two years: remote working is not just about setting up Slack and Zoom and some new policies on the ways of working from home. This approach is naive and has led to several surprises. Remote imposes a physical separation of people and limits their communication ability, which creates several challenges on how teams can interact, mainly how information can flow in the organization. In remote settings, people don’t easily “bump into each other” as they used to when working in the office. In a remote setting, we need to be more deliberate about fostering structures that enable healthy and manageable interactions between people and teams. The bottom line is that it is not just tools and high-level ways of working. We must acknowledge that more foundational changes in teams and organization structures need to address remote working challenges better.

Figure 1: Some options for strategies for remote working 

Figure 1.A shows that it is not enough to focus our “remote work strategy” on tools and policies. Suppose we neglect to establish more deliberate structures. In that case, teams will have unclear boundaries and scopes of work, which means “everyone is working on everything”. This means people will be spending extra cognitive load (“the total amount of mental effort used in the working memory”) and energy to overcome unnecessary burdens caused by poorly designed structures in the organization. Such unclarity on boundaries is further compounded in remote settings.

Organizations must be more deliberate in developing and adopting foundational elements and structures to support their new work settings, being fully remote work or hybrid. Namely, as shown in Figure 1.B, develop more explicit boundaries and scopes of work for their teams and more clarity on their dependencies. These become essential enabling structures for more effective remote work conditions.

In this article, we share ideas, principles, and practices from Team Topologies (and related topics) to help organizations approach their structures' design and evolution to better support interactions in remote working. We also share examples to showcase their impact when used to better approach organizational design, in general, and particularly to support remote working.

Team Topologies principles and patterns for more effective remote working

Most organizations' remote working strategies tend to be too tactical, namely focusing on “ways of working”, “tools,” and “management styles”. Those are undoubtedly necessary; however, we must also ensure that we are actively designing and evolving the foundational structures of the sociotechnical systems of the organization. The following sections focus on three core principles and patterns from Team Topologies. These are essential to enable more effective remote working conditions: team dependencies, boundaries, and interactions. You can find more details on applying Team Topologies in remote settings in the Team Topologies Remote Interactions Workbook (RTIW). This workbook also provides hands-on practical examples of how you might apply these ideas within your organization.

Team Dependencies

Team dependencies are one of the most influential aspects to understand and act on if we want to enable effective remote working. It is one of the core principles in Team Topologies, which focus on understanding and evolving dependencies so teams can achieve a fast flow of change (the ability to quickly go from idea to value in front of the customer).

Understanding and minimizing dependencies is fundamental in remote-settings

Dependencies are unavoidable and reflect that teams are part of a more extensive system that allows organizations to create value for their customers. However, in general, we don't want all teams collaborating and depending on each other. That is challenging and tends to slow everyone down (enormous coordination challenges). We want to have only the necessary dependencies to achieve our goals. These ideas form a good general principle for organization and software architecture design in physical office settings. However, its importance becomes even more prominent in remote settings since inter-team dependencies and communication are more complex and expensive. Therefore, organizations must adopt operating models that promote minimizing team dependencies.

Figure 2: Visualizing and understanding Team Dependencies 

By making team dependencies visible, such as in Figure 2, we can observe and understand how to approach them. That should enable us to trigger the conversations and developments that need to happen to remove those dependencies. We are not able to remove all dependencies. However, we can explore ways to transform them into “non-blocking dependencies”. These allow two teams to evolve independently from each other, as they rely on a clear contract that does not require them to collaborate on every change they need to make.

In the following section, we discuss several patterns and practices that can help us track, understand and minimize dependencies.

Strategic tracking and evolving of dependencies   

A simple way to make team dependencies visible and start tracking is to use the Dependency Matrix Tracking tool.

 

Figure 3 - Credits 

Spotify used it in the early 2010s. This approach is still an effective way for organizations and teams to start tracking and understand how to track dependencies between teams and trigger actions that need to happen. We can make this artifact part of the Team API. The Team API allows us to describe the team's purpose and scope of work. Furthermore, it makes the team dependencies and other elements visible. In Team Topologies language, a dependency is more than just a software integration (e.g., producer-consumer API relationship). We can also define temporary interactions, such as: "collaboration" (discovering and shaping a given thing or boundary); or "facilitation" (one team helps another one to learn a particular topic or skill). This combination can provide an excellent way for teams to track dependencies and support the necessary conversations. Such triggers for conversation become crucial in remote settings since, as mentioned before, we cannot so easily "bump into each other" as we used to in the office.

In recent years we have also been seeing companies adopt more automated ways to approach dependency tracking and understanding, in particular, approaches to have more accurate ways of visualizing the software systems landscape. For example, Spotify and bol.com use Backstage (a software catalog and developer platform), which allows teams to describe and visualize all their systems. Backstage enables teams to observe what systems teams own and also explore the dependencies between teams. These insights become a great tool to support embracing Conway’s Law: “any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure”. In a nutshell, we recognize that the awareness of the mirroring between organizational and technical systems architecture becomes essential to evolve our systems (organizational and technical), which is even more relevant in remote settings. 

Team boundaries

Effective team boundaries are another core principle of Team Topologies, which plays a crucial role in a team-first mindset. Good team boundaries can help teams have a clear sense of ownership and reduced cognitive load, resulting in improved autonomy, mastery, and purpose. The misplacement of boundaries between teams can result in increased cognitive load and context switching, which in a remote setting, can be devastating to team morale and an organization’s ability to achieve a fast flow of change.

Figure 4

Good team boundaries are essential for effective remote working

Many organizations are organized around functional silos such as Engineering, Operations, Test, Marketing, Sales, etc. Organizing in this way can often result in scenarios where “everyone works on everything” and leads to a need for coordination of work using projects. This project-based approach means that, after a project ends, people have to leave what they have built behind and begin learning all over again for the next project, resulting in lost core domain knowledge. This also leads to people context switching and potentially unhealthy increases in people’s cognitive load, which can lead to stress, anxiety, and burnout. Within a remote setting, this functional organization can also lead to coarsely-grained communication channels such as #ask-sales or #ask-engineering. Such a setup can lead to frustration as employees attempt to find the “right” people to talk to about an issue by “broadcasting” messages in the hope that someone within the engineering department might be able to respond. This overuse of shared communication channels can result in a lot of noise and make it useless as people “mute” the channel.

The Team Topologies book suggests that organizations should adopt a team-first approach to organization design instead. This approach promotes creating small, long-lived independent teams with clear ownership of business areas within the limits of the team’s cognitive load, and also kept within appropriate trust boundaries using Dunbar’s number. Dunbar’s number, as defined by anthropologist Robin Dunbar, relates to how trust dynamics between people change based upon the size of the group they are in, i.e., a smaller group has higher trust levels than larger groups. If the size of a group reaches a Dunbar number, e.g., 15, 50, 150, we should expect the trust dynamics to change. If you are interested in reading more, look at this article: Dunbar’s number and Communities of Practice. 

In order to move towards this team-first approach it is vital, especially in a remote setting, to rethink how the boundaries between teams are defined. This can be achieved by viewing the system through a different lens and using techniques such as User Needs Mapping (UNM) and Independent Service Heuristics (ISH) to identify potential fracture planes, ways of breaking up the system, and validate them as possible team boundaries. These boundaries can then be used to provide small long-lived, cross functional teams with a common goal, shared purpose and higher trust levels. Take a look at these articles if you are interested in learning more about UNM or ISH.      

One example of the effect of trust boundaries in action that we have seen, especially in startups, is when a team grows from 8 to 15 people. In this scenario, as the team size grows closer to 15, the group starts to behave more like two separate teams, one of 8 people and one of 7 people - at this point, it therefore makes sense to re-evaluate the boundaries between those two groups and form two separate teams. Another example is described in an article by Oyster HR, who experienced the side effects of lacking clear team boundaries and trust levels whilst designing their online tooling because they did not consider them. Everything was fine until they hit a tipping point of about 100 employees: “People were leaning on Slack to talk to each other about everything”. That had a significant impact on cognitive load and context switching for everyone. You can read more about this in the following article: Using Slack for remote teams: Where we got it wrong.

Designing online communication channels for good team boundaries

When we recognize the negative impact of not having clear team boundaries and understand some of the causes, as mentioned previously, it is possible to start designing our online communication tooling in a way that helps address some of the inherent remote working pitfalls.

It is essential to be deliberate when designing channels to avoid pure “open space” models for online communication. Instead, try to be more explicit about creating groups and collaboration spaces based on group trust boundaries. Having dedicated chat rooms/channels for teams is essential. It is equally important to create dedicated channels for certain types of communication within larger groups or departments that the team might be part of, enabling the group members to have a closer trust boundary since they might be working on more closely related things.

As a real-world example, within the Team Topologies internal chat tool, we use channels with names such as #tt-products-p89-blockers-to-flow to focus discussions around this particular workshop or #tt-customer-xxx to focus discussions around work for a particular customer. These simple naming conventions make it easy to discover the best place to communicate about a particular topic. Suppose you are looking to explore possible ways to restructure the online communication channels within your organization. In that case, the Remote Team Interaction Workbook (RTIW) suggests using the Online Space Assessment tool to help assess whether online spaces within an organization might likely be impacted by trust problems based on the number of people and the closest Dunbar trust boundary. This can help us determine whether we should consider changing the channel's focus to a smaller segment of users, which can be achieved by introducing a channel naming convention to reduce cognitive load.

When used in a remote setting, it becomes possible to create far more focused communication channels, such as #platform-security-ask and #stream-acquisition-ask, rather than coarser-grained channels, such as #ask-engineering, as described in the Oyster HR example above. On page 48 of the RTIW there are some excellent example channels from a telecommunications company with over 120 teams. Here they use channel names such as #tribe-payments-card-management, which can be interpreted as the Card Management team within the payments tribe allowing people within the org to simply search for “tribe” to find all Tribe-related channels, therefore, reducing cognitive load and making discoverability more straightforward.

Purposeful interactions

How teams interact is a foundational aspect of Team Topologies. It's not enough to focus on team types and cognitive load. It's also important to pay attention to how teams interact. Poorly defined team interactions can be a huge source of friction and inefficiency, which can be especially relevant in a remote setting.

Figure 5

The need for purposeful interactions

When organizations are struggling, we often hear the argument: “Let’s collaborate more…so that we can solve this problem”. Such behavior tends to be a false remedy that avoids addressing the real challenges (e.g., teams with unhealthy boundaries and interactions) and exacerbates the issue by increasing the number of meetings and general processes that try to compensate for those unhealthy structures. Ultimately, more collaboration is rarely the answer. Instead, we should focus more on understanding and addressing the structural challenges, such as what drives the need for handovers and blocking dependencies between teams. Having a clear understanding of how and when teams interact is especially important in a remote context due to the reduced options for engagement between teams.

As described in the previous Team Dependencies section, we must strive for “non-blocking” dependencies between teams. If our teams face scenarios where they have to wait for another team to complete some work before they can continue, we would consider this a “blocking” interaction, which we want to avoid. After recognizing this awkward interaction, the teams can then be purposeful about a collaboration over a short period to create an X-as-a-service interaction allowing the consuming team to self-serve in future interactions. 

We observed a great example of this evolution, from a blocking interaction to an X-as-a-service interaction, in a company in the fitness industry. In that context, whenever a stream-aligned team needed a new test member account, they would need to request to create a new account to the membership platform team via email. The request would be added to the membership platform team’s backlog, who would create the account when they had available time. This resulted in a blocking dependency since the stream-aligned team could not continue developing the feature without the test account. However, after a period of collaboration, the platform team identified that they could create a simple chatbot with which stream-aligned teams could request test account creation via a simple chat interface, allowing them to simply self-serve any required test accounts without becoming blocked by the membership platform team.

Using platforms as an enabler within remote settings

One technique introduced by Team Topologies that can be especially useful within a remote setting is the Thinnest Viable Platform (TVP). This concept encourages teams to consider the simplest way a blocking interaction can be changed to non-blocking. In many cases, simply adding information to a wiki page and making it visible to other members of the organization can significantly reduce the cognitive load for employees in a remote environment. You can find out more about TVP in this article: What is a Thinnest Viable Platform (TVP)?

A practical industry example of using a TVP can be found in an article written by Andy Norton (head of engineering at FOOTASYLUM). FOOTASYLUM used the TVP concept to encourage teams to have conversations around the actual data required from their platform. By simply asking the question: “Is this the minimum viable version of this service?” and keeping the idea of TVP in mind (i.e., questioning the nature of the data and the required outcome of the service), the platform team was able to reduce the time required to validate an assumption about the services they were building for consumption by other teams. In this case, they simply used static data to support the initial requirement, which is still in place. If you would like more details, you can read the article here: FOOTASYLUM’s Team Topologies case study.

Closing remarks and next steps

Every organization is different and requires context understanding to approach its design deliberately. Nevertheless, this article shares several principles and patterns you can explore when designing better remote working environments. In particular, we emphasize the need to look beyond “adding slack and zoom” and a few managerial practices to be successful in remote working. We showed that if organizations don’t take care of their foundational structures, namely team dependencies, team boundaries, and team interactions, it becomes challenging to be effective in remote working. Also, very importantly, this is not a one-time redesign. These aspects should become part of the organizations’ operating models, i.e., evolve foundational structures to sustain their ability to have healthier conditions to support remote work. 

Our experiences over the last two years have shown how important it is to be mindful of these aspects to be effective in remote work. For example, while working at bol.com, we observed that having clear boundaries and structures for evolution allowed teams to transition effectively into a remote setting. However, in our consulting activities, we often observe that organizations need more clarity on team boundaries and organization structures, mainly when working in remote settings. 

Starting by better understanding team boundaries and dependencies is essential. The article shares ways to approach that, including identifying boundaries and consolidating them in the Team API and dependency tracker artifacts. Furthermore, you can also start adopting Team Topologies interaction modes to more accurately describe the dependencies in your teams. That should give you an excellent shared language to describe existing dependencies and how to transform them or identify new ones. 

Please check the Team Topologies Remote Team Interactions Workbook for further guidance on other aspects for improving your remote working environment.

About the Authors

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT