Scenarios and Examples

The Team Onion applies to many different situations depending on what’s needed. Here are some tips and scenarios as told to me by people using the model to help their organisations with real problems

Building a new team from scratch: getting the right people involved

A common use of the Team Onion is for guiding the conversation and decision making when creating a new team. 

One example organisation has moved from a more hierarchical team structure to a flatter, more autonomous one. Previously their working practices were fairly siloed. Teams consisted of many individuals contributing to work, but decisions were often made outside of the team by others. Team sizes were unmanageable, which came with significant overhead and slowed things down.

They undertook a new approach to create multidisciplinary teams focused on a common goal, and the Team Onion helped them do that.

The model helped them frame discussions about what capabilities they needed to achieve their goal. Notably, the guide core team size of 5-9 people enabled sometimes difficult conversations and decisions about who should be on the core team. It also helped to emphasise the need for full-time commitment from them.

They then used the definitions to help the collaborators remain involved and feel like a valued part of the wider team. This expectation setting helped communicate the collaborators’ importance and keep them involved while keeping the core team small.

Now when they have a high-level idea of a goal for a new piece of work, they use the Team Onion to build a team around it; and then allow the team to build upon it during their kick-off.

Team kick-off: coalescing a new team

Organisations often start using the Team Onion as part of a team kick-off; it helps teams take ownership of their responsibilities for collaboration and communication.

After creating a new multidisciplinary team in one organisation, they came together for a multi-day kick-off. The kick-off activities covered three main areas: understanding the problem space and overarching goals, getting to know each other as a team and identifying the initial team backlog of work. 

The Team Onion was an integral part of that kick-off to help set up the team.

They started by building out their core team ring of the Team Onion, which helped them learn more about what capabilities each other brings to the team. Then they moved on to listing out everyone who could potentially be a collaborator or supporter and collectively agreed on their expectations.

Through discussion and prioritisation, they focused their collaborator list and decided who in the team would be the contact for that person.

Finally, they used the supporters list to create their show-and-tell invite list.

They used the Team Onion as a living artefact and revisited it when they moved into a new phase or needed to review how things were working.

The Team Onion helped them learn more about each other and proactively engage with the right people.

Team Retrospective: breaking down silos and reducing communication overhead

In an organisation I spoke to, there was a team that many other teams relied on for both new features and technical support. The team was getting so many daily requests for updates from all directions that they had barely any time left to write code. A rough estimate was that they were getting through 15% of their planned work and only able to spend an hour a week on new features. 

They were often delivering less than they had planned, and the less they could deliver, the more urgent the demands became, which in turn gave them less time to do work. It was leading to animosity, blame and siloed language. They needed a way to manage all the communication overhead, so they reached for the Team Onion.

In their team retrospective, they created a list of everyone they had engaged with recently.  They then placed them in the Core, Collaborator and Supporter rings. They used the communication and collaboration frequency to guide them where to place people.

While creating their Team Onion, they moved everyone they didn’t need to actively collaborate with to the supporter ring. They then agreed on what communication patterns allowed them time to focus on work.

They identified a team they collaborate with so frequently that they decided to sit next to them for more natural collaboration. 

They also discovered that everyone in the team was working daily with the same person on another team and that this person wasn’t working with anyone else, so they moved them into the core.

The Team Onion allowed them to set up better expectations with their supporters and gain back a lot more time to do their work, which meant everyone was happier.

Starting a new engagement: building a picture of who’s who

One organisation I spoke to uses the Team Onion when beginning a new piece of work with a client or a different part of an organisation. 

Many places don’t have an up to date org chart; if they do, it shows roles and reporting lines and doesn’t accurately reflect the people involved, making it hard to navigate. When starting a new piece of work, it helps to map out the people involved as quickly as possible, giving more time to focus efforts on adding value. 

They use the Team Onion as an introductory exercise, which helps the core team understand what capability each other brings to the team. They then identify people they need to collaborate with or engage as supporters.

They find that writing names down exposes gaps, uncovers teams they weren’t aware of, and explicitly calls out who should be on the communication list early on. It also helps to bring out any underlying conflicts, silos or areas where they need to make extra effort to engage people.

It fast tracks the discovery work of who’s who in an organisation and those people who help make the core team successful.

Hear from some of the people using and sharing their thoughts on the Team Onion around the web

Emily Webber The original blog post

Only Dead Fish The Agile Team Onion

DWP / Alison Baines Learning as part of the Business Analysis community blog post

Scott Colfer Product Managers Handbook

Giles Turnbull The agile comms handbook

Centre for Digital Public Services Service Standard for Wales

Centre for Digital Public Services Multidisciplinary teams webinar

Digital Leaders / Colin Banno-Thornton Invest in people if you want to transform

Emily Webber Article in Public Digital Signals book


If you have a story to share, a link to add or just want to say hello, I would love to hear from you, please get in touch