Wading through treacle [Part 1]

How to think about team organisation for fast flow of value

This is the first part of a two part special focusing on how a value stream approach can help your organisation shorten time-to-market, increase throughput, improve product quality and optimise for business outcomes.

Have you ever worked in a business where it feels like it takes forever to get anything done but you can’t understand why?

Whilst working in the innovation team for a large UK retailer, I had a conversation with the MD about the pace of change. One of their frustrations with the core business was it felt like teams were “wading through treacle” to get things done but in the innovations team we could move a lot faster. That analogy stuck with me and I have been fascinated since that conversation about how best to organise teams so they can consistently deliver value at pace. 

A couple of years ago I read the book Team Topologies by Manuel Pais and Matthew Skelton and their approach to team structures is a great way to think about how to organise teams. 

In the book they describe how slow delivery, confusing team structures and excessive cognitive load on teams can lead to pushing against Conway's Law, teams being pulled in many directions and ultimately disengaged teams. 

If you’ve not come across Conway’s Law before, the concept was introduced in 1967 by Melvin Conway. In simple terms it describes the relationship between an organisation's communication structure and the systems it designs. If a team is siloed with limited communication between departments, Conway's Law suggests the resulting software might also be siloed with separate, poorly integrated components. Conversely, a team with open communication and collaboration is more likely to build a well-integrated system with clear ownership of different parts.

So what’s a potential answer to this challenge? Manuel Pais and Matthew Skelton proposed four key elements to organising teams for fast flow of value.  

1. Team first approach
   
   Teams are the building blocks. Individual contributors are important, but the team as a whole is the unit responsible for delivering value. A team first approach emphasises four key aspects:

   1. Focus on team effectiveness: Structures and processes are designed to optimise team communication, collaboration, and decision-making.

   2. Limited cognitive load: Teams are kept small enough to avoid information overload and ensure efficient knowledge sharing.

   3. Clear ownership: Teams have clear ownership of specific domains or functionalities, fostering accountability and a sense of pride in their work.

   4. Cross-functional teams: Teams are composed of members with diverse skill sets to minimise dependencies and promote independent delivery.
      

2. Using Conway’s Law to define your architecture
   
   It is recommended that organisations use the inverse Conway Maneuver. This proactively designs the team structure to match the desired system architecture. This fosters better communication from the start. Teams should be sized so that they do not have too much cognitive load.
   
   A good way to test if a team has too much cognitive load is to ask the team in a non-judgemental way, “Do you feel like you’re effective and able to respond in a timely fashion to the work you are asked to do?” If the answer is no then the team you should explore if the team has too much cognitive load.
   

3. Utilising 4 fundamental team topologies
   
   These are four team types that allow for teams to work independently and reduce cognitive load

   1. Stream-Aligned Team:
      These are teams that deliver continuous value to customers and own a single, valuable stream of work (product, feature set, user journey). An example is a team responsible for a specific functionality within a mobile app.

   2. Platform Team:
      These are teams that empower stream aligned teams to be autonomous by providing self-service platforms and tools (infrastructure, APIs, development environments). An example is a team managing a cloud platform used by multiple stream aligned teams for development and deployment.

   3. Complicated-Subsystem Team:
      These are teams that reduce the cognitive load of stream aligned teams by owning and managing complex subsystems that are critical to the overall system. An example is a team managing a core authentication system used by multiple stream aligned teams.

   4. Enabling Team:
      These teams enhance the capabilities of SA teams by providing expertise and services that Stream aligned teams don't have (security, data analysis, legal compliance). They act as a consultant and advisor, not a bottleneck in the workflow. An example is a security team that helps stream aligned teams implement secure coding practices.
      

4. Team API’s
   
   A team API is a way for a team to clearly define how it interacts with the rest of the organisation. It's essentially a document that describes the team's:

   1. Purpose: What the team is responsible for and the value it delivers.

   2. Inputs: What the team needs from others (e.g., dependencies, requests).

   3. Outputs: What the team delivers to others (e.g., features, services, information).

   4. Boundaries: How the team prefers to collaborate and what's considered "internal" vs. "external."

I hope you have found part one useful and stay tuned for part 2 in the next couple of weeks which will cover flow metrics as an approach to measuring stream aligned teams against business outcomes.