Semantic Versioning for Teams

Over the last year or so I have had my entire team change around me. I am trying to not take that personally.

This means we often run into the situation where my team made certain decisions or commitments months ago, which we are being held to now. However, almost no-one who made that decision is still around. Much like the Ship of Theseus¹, if you change every member of a team, are they the same team?

Someone smart² said to me that “Teams are Immutable”, so they would contend that if you add or take away one member you essentially have a whole new team because the dynamics and skills within the team are different. So how can you convey that idea that the team is significantly different at different stages in time? One option is to rename the team each time, but that would become untenable in an organisation. Perhaps what we need is a versioning system for teams.

This is how it could work³:

• MAJOR version when you a team member leaves, joins or a title changes.
• MINOR version when you change an outwardly facing policy or process.
• PATCH version when you change an inwardly facing policy or process.

Let’s work through an example.

• A new team is spun up at FooCorp called Team Bars. Team Bars has Sarah, Mike and Mahitha on it. That is Team Bars 1.0.0.
• Andrew is added to the team. Team Bars 2.0.0.
• Team Bars are getting a lot of requests through, so they put in a triage system. Any requests to the team go to a Jira board. Team Bars 2.1.0.
• Team Bars decicde they want to do async standups in slack. Team Bars 2.1.1.
• Benaz joins Team Bars. 3.0.0.
• Mike is promoted to Engineer. 4.0.0.

Much like in versioned software there is an accompanying changelog. It might look something like this⁴.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

# 1.0.0 [2021-01-18]
Team Bars formed with Sarah, Mike and Mahita. We chose the team name Bars because that's where we spend all our time 🤪.
You can see our team missions here.

Sarah - Lead Engineer
Mike - Junior Engineer
Mahita - Project Manager

# 2.0.0 [2021-01-25]
Andrew joins the team! Andrew will be our senior designer to help us spin up some prototypes quickly.

Sarah - Lead Engineer
Mike - Junior Engineer
Mahita - Project Manager
Andrew - Senior Designer

# 2.1.0 [2021-02-07]
We are finding that the number of requests we get through slack and other channels is becoming too much. We have set up a Jira board and a Slack workflow to add tickets to the board so we can triage them.
See the linked Confluence doc for more details.

# 2.1.1 [2021-02-11]
We couldn't decide on a good time for everyone to be on a call, so we are experimenting with async standups on Slack.

# 3.0.0 [2021-03-03]
Benaz joins Team Bars! Benaz will be our new frontend focussed engineer that specialises in accessibility and HTML semantics.

Sarah - Lead Engineer
Mike - Junior Engineer
Mahita - Project Manager
Andrew - Senior Designer
Benaz - Senior Engineer

# 4.0.0 [2021-04-09]
Mike got promoted to Engineer!

Sarah - Lead Engineer
Mike - Engineer
Mahita - Project Manager
Andrew - Senior Designer
Benaz - Senior Engineer

I think this is interesting for a few reasons:

• The changelog provides a way to track team membership over time, so you can easily see who was in the team at any time:
• The changelog provides a record of historical decision making with some context as to why the decision was made.
• The version number provides a way to talk about the size and scale of changes in a team over time. For example, “Yes, we were more productive in January last year, but that was version 3.4.1 - we are now version 16.0.1.” In the same way that Rails v1 and Rails v6, while technically the same software, is significantly different.
• The version number and changelog can give good context to new senior leadership. “Why is Team Foo so burnt out? Well they went from v6 to v18 in the last 6 months, you can see from the changelog the amount of change has been pretty brutal”.
• A timestamped changelog would provide a way to give extra data around the rate of team change in a company or department.

I started off writing this somewhat facetiously but I am getting dangerously close to thinking this might actually be a good idea. I’d love to know what you think.

Thanks to Mark Barber and Thomas Ridge for reading an early version of this post and providing excellent feedback.