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 Theseus1, if you change every member of a team, are they the same team?
Someone smart2 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 work3:
- 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 this4.
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.
“The ship wherein Theseus and the youth of Athens returned from Crete had thirty oars, and was preserved by the Athenians down even to the time of Demetrius Phalereus, for they took away the old planks as they decayed, putting in new and stronger timber in their places, insomuch that this ship became a standing example among the philosophers, for the logical question of things that grow; one side holding that the ship remained the same, and the other contending that it was not the same.” - Plutach, Theseus ↩︎
Probably Sebastian von Conrad. ↩︎
Shown in reverse chronological order for ease of reading here, but would probably want to be in chronological order like a software changelog. ↩︎