chapter 1

A remote-first way of working requires a new mindset from organizations. This overview chapter explores some of the techniques that can help organizations adopt an effective remote-first approach.

Many organizations have found, to their dismay, that rolling out a new chat tool for staff working remotely does not magically make the organization remote-first. A viable remote-first approach needs more than just chat and video tools.

Certainly, tools are needed and useful, but for a successful digital transformation—whether colocated or remote-first—the organization also needs good psychological safety and an effective set of “ground rules” and practices for teams to use for working together.

An example of this is Google’s five keys to successful teams. As they lay out, “Who is on a team matters less than how the team members interact, structure their work, and view their contributions.”1

Clear ground rules and practices define ways of working, set expectations, and provide easy-to-recognize patterns and modes of behavior that make it easy for people to work in well-defined ways. In particular, well-defined team interactions clarify the relationships between different groups in the organization and the purpose of different activities. This in turn helps to minimize the cognitive load on teams and provides more “head space” for focusing on the most important aspects of work within the organization.

Broadly speaking, cognitive load is the amount of mental effort being used on a task or set of tasks. For teams, you can think of cognitive load as the collective amount of mental effort being used by the team.

You can read more on cognitive load as it pertains to teams in Team Topologies, pages 11–12 and 39–47.

You can use this survey template as a starting point to assess the overall cognitive load of your team.

1.How is the experience of building your services? Things to consider: Is building a clear and repeatable task? Is it fast “enough”? What happens when builds fail? Are failures easy to diagnose?

2.How is the experience of testing your services? Things to consider: Is testing a clear and repeatable task? Is it fast “enough”? What happens when tests fail? Are failures easy to diagnose? Are test environments adequate? Are test environments easy to access/spin up/clean up/inject test data into?

3.How is the experience of deploying your services? Things to consider: Are deployments a clear and repeatable task? Do you know what the deployment strategy is? What happens when deployments fail? Is it possible and straightforward to roll back a failed deployment? Do you have access to the necessary logs to understand why a deployment failed and/or its current status?

4.How is the experience of operating your services? Things to consider: Do you know how each service is being monitored? Do you have access to the data? Are adequate alerts (few false positives) being sent? Are logs and information accessible and easy to find? Are data flows across services relatively easy to follow?

5.How is the experience of being on call for your services? Things to consider: Do you know what the incident response procedure is? Do you feel you have enough experience (either real or simulated) to deal with incidents without high levels of stress? Do you know who to reach out to for help during an incident when you’re on call? Would you be anxious about a 3 a.m. outage? What about an incident in a service that hasn’t been modified for months or years?

6.How is the experience of dealing with health industry regulations and compliance? Things to consider: Do you feel you have sufficient awareness to raise questions on changes that might require compliance oversight or at least a quick debrief? Are you confident that you know which industry regulations are of concern for your services? If yes, do you feel that this knowledge is being refreshed often enough?

Notice that questions #1 through #5 focus on the experience of building, testing, deploying, and supporting software services, so they are broadly applicable. However, question #6 is specific to an organization working in the healthcare industry. It is included as an example of the kind of context-specific questions you will need to use in order to assess other aspects that might be causing high cognitive load for your teams.

The point is that this form is just a starting point. You will need to adapt and expand it to your organization’s specific needs.

RESOURCE

You can access an online form of this assessment here: GitHub.com/TeamTopologies/Team-Cognitive-Load-Assessment.

Use the Team API Approach to Define and Communicate Responsibilities and Team Focus

So what approaches can organizations take to improve interactions between teams? In Team Topologies, we explain the concept of a team API. A regular API is an application programming interface, a technical term for the way one piece of software interacts with another piece of software programmatically. A given team’s API is therefore a kind of specification for how other teams in the organization can and should interact with that team.

Read more on team APIs in Team Topologies, pages 47–49.

By defining these aspects and making them easily discoverable by other teams, a team increases its clarity of purpose and helps other groups to understand how that team fits into the wider organization.

See Chapter 2 of this workbook for more on team APIs, including exercises/templates.

All teams are part of a socio-technical system, and therefore depend on other teams at some point in time, to a greater or lesser extent. That means we should be tracking dependencies between teams now and over time. Some dependencies might be fine today, but in a few months from now they will start slowing down the dependent team too much and we’ll need to address it.

While ideally we might want to remove all dependencies, in practice we should identify which ones are problematic and should be removed, and which ones are “under control,” for now at least. A problematic dependency introduces significant delays, is too unpredictable, or increases work in progress (WIP) for the dependent team, slowing them down considerably.

A remote-first environment creates unique challenges in this space. It’s impossible to simply walk up to the desk of someone on another team to ask about progress. But a constant stream of chat messages asking for status updates becomes a cognitive burden.

Instead of spending time waiting on other teams to finish their work, focus on tracking and then removing these in-flow dependencies. Books like Making Work Visible by Dominica DeGrandis explain useful techniques for visualizing team dependencies, many of which can easily be adapted to work in a fully remote context. DeGrandis also has a great article on TechBeacon, “How to Defrag Your DevOps Value Stream,” that can be useful.3

Chapter 2 of this workbook has more details and exercises on tracking and removing in-flow dependencies.

In a remote work setting, it’s vital to “overcommunicate.” As Meaghan Lewis outlines in her article on TechBeacon, communicating mainly through text messages or chats makes discerning tone and urgency challenging, not to mention problems arising from cultural differences in phrases. Also, navigating when and how to post (to an individual or the whole team) is new territory.4

Ultimately, in a remote-work world it is essential to be very clear all the time about what you are working on, why you’re working on it, how your work is being completed, and when it should be completed by. Overcommunication feels almost like an externalization of your key decisions and reasoning so that people can easily reconstruct the sequence of thoughts that led you to your current work. It is vital to successful remote teams.

Overcommunication will take several forms: share small decisions in a chat tool, write up larger decisions or designs in a wiki or document, and even create a presentation or report to explain important concepts. Don’t just rely on people seeing scrolling messages in the chat tool.

Because most human-to-human interaction in a remote-first organization or team will be via chat and text media (such as wikis, documents, and so on), it is essential to emphasize good written skills. It’s not just about typing lots of text, though. The text needs to have context when seen by itself.

For example, chatting “Hi, what do you think?” requires a mental context-switch for the person reading the message. What does that question refer to? They might even have to scroll back through a series of chats to find the original ask. On the other hand, “Hi. So, do you think we should switch component A for component B due to the performance issues with A?” gives plenty of context for the reader. There’s no need for them to hunt down the original question or chat thread.

Don’t make it hard for people to discover meaning in written communications. Make the messages self-contained.

Well-defined interactions are key to effective teams, and this is especially true for remote work situations. Team-focused conventions within chat tools and wiki documentation increase discoverability and reduce cognitive load on communications. For example, using a chat tool like Slack you can enforce predictable channel naming conventions. Plus, the chat tool’s ability to search across channels increases discoverability.

By adopting clear ground rules and practices, like the team API and predictable chat tool naming conventions (discussed in Chapter 3), organizations can take advantage of remote-first ways of working to increase their chances of success.