Reading Time: 3 minutes

I have been working with digital, data, and technology organisations for a long time, many of which are in UK government departments. One thing that I have seen people get tripped up on is how they describe teams. 

Ambiguity about what a team is can create tensions, rework, and confusion and ultimately get in the way of the work.

To help, I’ve been developing a team taxonomy so that some of my clients and their teams can have better conversations about differences and similarities and hint at the expectations of interactions. This post shares these taxonomies in case they are useful to others, too.

It’s clear that people find team categorisation valuable when thinking about their organisations. The popularity of Team Topologies, which focuses on software organisations, shows just that. You’ll see some crossover with those topologies here.

I hadn’t yet seen a taxonomy specific to some of my clients’ situations—ones that reflect the reality of their worlds and also help elevate enabling teams, like business operations, to equal importance as the digital delivery teams—so I created this one, which has proved helpful to my clients.

Team Taxonomies

Four classifications define the team types, and they are as follows.

Teams fall into one of these types…

(Mostly) works to enable or empower other teams and people through internal operations, support, platforms, products or services.


(Mostly) works towards delivering end-to-end outcomes that create value for end users.

… with one of these makeups …

A mix of capabilities and disciplines, collaborating daily towards common goals or outcomes.


Mostly made of the same skill set or profession, collaborating daily towards common goals or outcomes.

… operating in this mode …

A team that stays together on an ongoing basis, even through team member changes.


A team that is set up for a defined period or specific outcome and then disbanded.

AND they could also be

A team that collaborates with other teams on a specific task or outcome and then moves on to work with another team.

… spanning one of these areas.

Where the team works, specific to the makeup of a particular organisation, some examples are.

Putting it together

Team taxonomies
Enabling and empowering 
or User outcome aligned 
Multidisciplinary or Specialist 
Long-lived or Temporary AND could also be Roving 
Span (examples) Within an area or
Across areas or Across department


A finance team could be

An enabling and empowering, specialist, long-lived team working across the org.

An agile delivery team could be

A user outcome aligned, multidisciplinary, long-lived team working within an area.

A coaching team could be

An enabling and empowering, specialist, long-lived team and roving team, working across areas.

What to think about next

Having these taxonomies is the first step towards understanding the teams; the other things to consider are how they operate and how others engage with them.

Each team will likely have different ways of managing their work and backlog, such as ticketing systems or monthly planning and prioritisation.

Teams may also have other specific operating methods. For more on that and some approaches to team dependencies, take a look at Team APIs from Team Topologies.

Teams will need to collaborate and communicate with others, often across different taxonomies. See my model, The Team Onion, for approaches to identifying who they are and creating shared responsibility across team boundaries.

If this resonates with you and you found this post useful, please let me know in the comments.