<aside> <img src="/icons/info-alternate_yellow.svg" alt="/icons/info-alternate_yellow.svg" width="40px" /> This page is part of The Toolbox by Danny Smith.
</aside>
Most companies group people into teams to get work done. I’ve seen a lot of very complicated approaches for how to do this, and also a lot of confusion around what certain teams do and who is or isn’t part of what team. To address that, it’s useful to define what a team is and have a process for standing up formally established teams that’s universal across the company.
It's fine to informally establish a group for a short period of time to work on a particular thing – that’s not what we’re talking about here – I wouldn’t call that a “team”. Here’s my definition of a team…
A team is any formally established non-temporary grouping of people.
This definition is deliberately loose – it includes what most companies call teams, but also what many companies call departments, squads, guilds, functions etc. This keeps things simple… they’re all just called teams. This definition also allows us to create cross-functional teams drawn from right across the company. Bear in mind that people can (and should) belong to more than one team at once.
For this to work well, all teams must have more than one member and the following four things:
Being explicit about who is in what team and why creates clarity. Some teams’s membership will be based on role (eg Senior Leadership Team or Engineering Team); some will be down to arbitrary appointment (eg. feature team); some might allow anyone to voluntarily join. And some might be a mix of these.
| Team | Mandatory Membership | Voluntary Membership |
|---|---|---|
| Executive Team | All C-Suite | None |
| Senior Leadership Team | All C-Suite and their director-level direct reports | None |
| Engineering Team | ||
| (ie whole Eng Department) | All software engineers & managers in the company | None |
| Design Team | ||
| (ie whole Design Department) | All designers & managers in Product and Marketing functions | Those in design-focussed roles elsewhere, with agreement from team lead. |
| XYZ Feature Team | ||
| (Cross-functional delivery team) | As appointed. | None. |
| Social Events Team | ||
| (Organises internal social events) | None. | Open to all. |
| Security Team | ||
| (Owns security stuff) | Head of Engeneering & IT Manager | Open to all, with agreement from team lead. |
| Notion Gardeners Team | ||
| (Keeps Notion tidy) | People Ops Lead | Open to all. |
Every team needs to know why it exists, and it’s often best to describe this in the form of a mission. For some teams this should be fairly easy (most small delivery teams will already have some sort of mission), but it can be a bit harder with larger teams that we’d normally call “departments”.
It’s an incredibly useful exercise with these teams though – asking “why does the finance team exist?” or “how do we describe our collective mission as the engineering team?” doesn’t often happen and is super valuable on it’s own.