Skip to content

April 28, 2022

Visualizing Team Dependencies with a Team API

By Matthew Skelton ,Manuel Pais

Dependencies between teams are a reality in any organization, even when we try to minimize them. If we don’t track team dependencies in the first place, we will run into scheduling and prioritization problems that slow down the flow of delivery. To understand inter-team dependencies, the work being done by each team needs to be visible. Once we are able to track these dependencies, we can then look into promoting healthy dependencies and removing (or minimizing the impact of) slowing or blocking dependencies.

This excerpt from the Remote Team Interactions Workbook by Team Topologies coauthors Matthew Skelton and Manuel Pais explores techniques to track and manage inter-team dependencies that work in a remote context.

Team API

The first step to start identifying team dependencies is for each team to clarify and provide visibility to the whole organization on the work they are currently doing and their priorities for the (near) future. Rather than starting with a top-down view of all the work in progress across the organization, we should promote that each team surfaces and exposes that information to others in all directions (upward, sideways, and downward) in an easy-to-consume way.

This decentralized approach also supports the fact that different teams might prefer to work with different timescales. For instance, some teams might only plan the current two-week sprint and prioritize high-level work items for the next couple of sprints, while other teams might do detailed monthly or quarterly plans. Teams also work with different artifacts—Scrum or Kanban boards or planning documents—depending on the team’s approach to work and, sometimes, the nature of the services they are delivering.

In Chapter 3 of Team Topologies we introduced the idea of a team API, a clear interface describing different aspects related to team ownership, communication preferences, practices, and principles. For example:

  • Which artifacts does the team own?
  • Which practices do they use to develop, test, version, and deliver those artifacts? Etc.

In the context of remote teams, it is even more important to include in the team API the road map for upcoming work as well as communication preferences, such as which channels (e.g., chat tools, video conferencing, email, or phone) they use, which days of the week and times are more suitable, and what the expected response time on asynchronous channels should be.

Making access to information and the team as clear as possible minimizes the cognitive load on others. It allows people to quickly find out who they need to talk to for a specific question, as well as when and how to talk to a specific team when it is needed. Even in situations where the team API does not provide all the necessary details, it should at least clarify when and how best to reach the team with further questions.

In addition to communicating preferences to other teams, the use of team APIs encourages a team to deliberately consider how they want to be viewed by and how they want to interact with people outside of the team. Teams can begin to define their own API independently from each other. This can lead to increased clarity and more purposeful communications and interactions between teams, provided they follow a consistent format that is easy to consume by people outside of the team. 

Example

In the first half of 2020, Zoom and other video communication tools saw exponential growth due to worldwide lockdowns caused by the COVID-19 pandemic. This unexpected growth put a great strain on these companies’ infrastructure and security. It’s not hard to imagine an identity management team in this situation buried with change requests to natively support more runtime platforms as well as fix security issues getting media attention. Let’s look at a fictitious company, Mooz, and their fictitious identity management team.

The use of a team API for the Mooz identity management team is even more critical in this situation, as the team attempts to navigate the storm of work befallen upon them. When a team like this is under pressure to deliver on their goals, the use of a well-known, easy-to-access team API could help other teams and individuals in the organization communicate their needs or issues in a way that is efficient for this team, reducing interruptions and their need to context switch. This will allow the identity management team to focus on the work at hand. There may be a need for other teams to collaborate with them for a short period in order to configure their authentication workflow.

The team API can also be used to define how the team prefers to use chat communication tools, such as Slack. For more complicated situations, a workflow builder can be used to ensure all requests are asked in a consistent, pro-forma enforced structure. The team should also look to be more purposeful about how those Slack channels are organized where possible.

The following team API example is from the imaginary Mooz identity management team.

Team Identity Management API
Updated: 2nd June 2021

Team name and focus: Team Identity Management is responsible for the identity management service
Team type: Platform team
Part of a platform? Yes, the Engineering Foundations platform
Do we provide a service to other teams? Yes. Details: An identity management service allowing users to authenticate and access resources provided by other teams.
What “service level expectations” do other teams have of us? Support requests to be acknowledged within 1 hour of submission. First response to support requests within 24 hours of submission.
Software owned and evolved by this team: Github: mooz_inc/ identity.management
Versioning approaches: Semantic versioning on nuget packages
Wiki search terms: Identity, access, ActiveDirectory
Chat tool channels: #platformteam-identitymgmt; #support-identitymgmt; #releases-identitymgmt
Time of daily sync meeting: 9 a.m., accessible via https://mooz.us/k/7846891894 (nonteam members are welcome to join but please mute yourself until the questions section at the end of the call)

What we’re currently working on:

  • our services and systems: an identity client allowing other teams to more easily integrate with the identity management system
  • ways of working: adopting daily showcases for a 2-week period, accessible via https://mooz.us/k/7846891894 (everyone is welcome to join but please mute yourself and use the “raise hand” feature to ask a question during the showcase)
  • wider cross-team or organizational improvements: helping to bootstrap the new internal tech conference

Teams we currently interact with:

Team Name Interaction Mode Purpose Duration
Test Automation Enabling Team Facilitating Understand test automation and data mgmt examples for iOS 2 months (from Mar 30 to May 29, 1 day per week)
VideoCalls Stream Team Collaboration Define workflow for authentication errors in VideoCalls service 3 weeks (from Apr 13 to Apr 30, 2h per day)
CallAdmin Steam Team Collaboration Clarify and test authentication permissions for new CallAdmin standalone app 2 weeks (from May 1 to May 14, 2h per day)

Now Your Turn

Think about a team within your current organization. What might their team API look like? Put together a team API that provides members of your organization who are outside of that team a clear description of the team’s purpose, their ways of working, and how they interact with other teams. Next, think about where you might want to store the team API to make it easily accessible to other members of your organization.

Use this template to help your team(s) think about their team API. Each team should answer the questions and fill in the details below. Remember that the answers and details will be a point-in-time snapshot of team relationships and team interactions.


Continue reading in the Remote Team Interactions Workbook by Matthew Skelton and Manuel Pais.

- About The Authors
Avatar photo

Matthew Skelton

Matthew Skelton has been building, deploying, and operating commercial software systems since 1998. Head of Consulting at Conflux (confluxdigital.net), he specialises in Continuous Delivery, operability and organisation design for software in manufacturing, ecommerce, and online services, including cloud, IoT, and embedded software.

Follow Matthew on Social Media
Avatar photo

Manuel Pais

Manuel Pais is a DevOps and Delivery Coach and Consultant, focused on teams and flow first. He helps organizations adopt test automation and continuous delivery, as well as understand DevOps from both technical and human perspectives. Manuel has been in the industry since 2000, having worked in Belgium, Portugal, Spain, and the UK.

Follow Manuel on Social Media

No comments found

Leave a Comment

Your email address will not be published.



Jump to Section

    More Like This

    Map Camp: Weird Mapping – How to Create a Revolution
    By David Anderson

    A version of this post was originally published at TheServerlessEdge.com. Dave Anderson, author of…

    Serverless Myths
    By David Anderson , Michael O’Reilly , Mark McCann

    The term “serverless myths” could also be “modern cloud myths.” The myths highlighted here…

    What is the Modern Cloud/Serverless?
    By David Anderson , Michael O’Reilly , Mark McCann

    What is the Modern Cloud? What is Serverless? This post, adapted from The Value…

    Using Wardley Mapping with the Value Flywheel
    By David Anderson , Michael O’Reilly , Mark McCann

    Now that we have our flywheel turning (see our posts What is the Value…