Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Are poor team interactions killing your DevOps transformation?

Matthew Skelton Founder and Head of Consulting , Conflux
Manuel Pais IT Organizational Consultant, Independent

The COVID-19 pandemic has ushered in a new remote-first world for IT, with many organizations struggling to catch up with new tooling and ways of working. Some companies have embraced this new reality, ditched their expensive downtown offices, and told staff they can work from home permanently.

And some are discovering for the first time that the physical office was substituting for poorly defined teams and poorly defined areas of focus, threatening their digital transformation efforts.

A successful remote-first approach requires that you explicitly design the communication among teams using physical and online spaces. Using simple tools for dependency tracking, and patterns such as a "team application programming interface" (a concept we developed and explain in our book, Team Topologies), organizations are finding that well-defined team interactions are key to effective IT delivery in the remote-first world.

Here's what you need to know to go that route.

What does an organization need to thrive in a remote-first world?

Many organizations have found to their dismay that rolling out a new chat or video tool for staff working remotely does not magically make the organization remote-first. Certainly, tools are needed and useful, but for a successful DevOps transformation—whether co-located or remote-first—the organization also needs good psychological safety for teams and an effective set of ground rules and practices for teams to use for working together.

The 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 among 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.

So, what techniques can your organization use to improve interactions among teams?

The team API approach can define and communicate responsibilities and team focus

So, what's a team API? An API, or application programming interface, is a technical term for the way one piece of software interacts with another piece of software programmatically. A team's API is a specification for how other teams in the organization can and should interact with that team. 

A team API covers a wide range of things, including:

  • Artifacts owned by the team (libraries, applications, services, etc.)

  • Versioning and testing approach

  • Wiki and documentation

  • Practices and principles

  • Road map and priorities

  • Communication preferences (when/how)

By defining these things and making them discoverable by other teams, your team increases its clarity of purpose and helps other groups to understand how that team fits in the wider organization. (There's a free-to-use template for the team API on GitHub.) 

Track dependencies using simple tools and remove blocking dependencies

In a remote-first environment, it's impossible to simply walk up to the desk of someone on another team to ask about progress, and 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 such as 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.

We recently published a template for tracking team dependencies on GitHub. Based on work from Spotify, the tracker template helps teams to frame conversations around improving flow, avoiding blocking waits, and ultimately moving to a more autonomous delivery model.

Consciously design inter-team communications using team interaction modes

There are many different chat tools available for remote-first working, and most organizations are using a chat tool (or several) these days. However, simply providing all-staff access to a chat tool is only the first step in making remote-first a success.

Too many organizations allow a kind of free rein within the chat tool, with little or no consistency about channel names, display names, the meaning of emojis, or even etiquette. This can rapidly lead to the chat tool becoming both essential to watch (in case you miss a vital message) and incredibly confusing and difficult to use.

For effective remote work, some chat tool conventions are needed. The virtual space inside the chat tool needs to be predictable and discoverable. Arbitrary channel names such as #homepage_discussion, #increase-conversions, and #ninjas make it difficult to know where to go to discuss a topic. If this is combined with multiple private channels, finding the right people to speak to is a game of cat-and-mouse.

Instead, define a set of conventions that improve predictability and discoverability. For example, include the team name and type of team in the channel name for the team’s main outward-facing chat channel. For example:

  • #streamteam-green—the public channel for the stream-aligned team "Green"

  • #streamteam-blue—the public channel for the stream-aligned team "Blue"

  • #platformteam-data—the public channel for the platform team "Data"

  • #platformteam-infra—the public channel for the platform team "Infra"

  • #enablingteam-k8s—the public channel for the enabling team "k8s"

The team interaction modes from Team Topologies can help further increase the clarity of purpose for teams working together, including for these scenarios: collaboration (two teams working together for a defined discovery period to achieve a specific goal); x-as-a-service (one team provides something as a service, another team consumes); and facilitating (one team helps another to detect capability gaps or increase skills and awareness).

Figure 1. The four team types and their different interaction modes. Source: Team Topologies, by Manuel Pais and Matthew Skelton. 


For example, a stream-aligned team might currently be interacting with two other teams: a test-automation enabling team (using facilitating) and a face recognition "complicated subsystem" team (using collaboration). In this case, there could be two temporary chat tool channels to clarify these interactions:

  • #testautom-facilitating-green—the test automation team is facilitating the green stream-aligned team

  • #facerecog-collaboration-green—the face recognition team is collaborating with the green stream-aligned team

Furthermore, it can be hugely helpful to have channel names that make it clear where to get support or help for common or shared infrastructure or tools:

  • #support-environments—the support channel for environments

  • #support-logging—the support channel for logging

This makes it easy for people to "self-serve" and discover the best place to ask a question or ask for help. Similarly, set some conventions around the display name that shows in the chat for each person. "Jim" or "sara_b" provide much less context than something such as "Jim Ngo (infra platform team)" or "Sara Brown (green stream team)." With the more descriptive display names, we have immediate context for who they are and their team role.

Overcommunicate using just enough written documentation

In a remote work setting, it’s vital to "overcommunicate." Be very clear all the time about what you are working on, why, how, and when. 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.

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

"Being a good writer is an essential part of being a good remote worker," say Jason Fried and David Heinemeier Hansson in their classic 2013 book REMOTE: Office Not Required. The authors built the hugely successful company 37signals, starting fully remote in 2003. Among many other useful tips in their book, they explain that because most human-to-human interaction will be via chat and text media (such as wikis, documents, and so on), it is essential to emphasize good writing skills for remote work.

It's not just about typing lots of text, though. The text we type needs to have context when seen by itself. "Hi, what do you think?" requires a mental context-switch for the person reading the message (what does that question refer to?). But, "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.

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

Design and define the ways that teams interact

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.

By adopting clear ground rules and practices—such as team APIs and chat tool naming conventions—organizations can take advantage of remote-first ways of working to increase the chances of success with DevOps transformations, becoming more effective at software delivery.

This article has been adapted from material in the forthcoming Team Topologies Workbook for Remote Teams, to be published by IT Revolution in 2020. Find out more at https://itrevolution.com/newsletter-signup/.

Want to know more? Matthew Skelton and Manuel Pais spoke on this topic at DevOps Enterprise Summit London—Virtual, on June 24, 2020. Registrants have access to the recording.

Keep learning

Read more articles about: App Dev & TestingDevOps