Speaking of rotation … what happens when the same principle is applied to other types of teams? For example, software development teams.
You could argue that we use a rotation policy of sorts within the dev team at Trade Me in that we tend to mix up the projects a bit so that over time everybody works on different parts of the site.
This is a form of collective code ownership, which is not a new idea.
The main benefits are anybody is able to make changes to any part of the application, without fear of stepping on others toes; no individual becomes a bottleneck when changes are required; and the team is resilient to changes in roles and personal (this was also the justification used by Graham Henry for his rotation policy, pointing at the impact injuries to key players had in previous World Cup campaigns).
But what are the associated costs?
As Stefan Reitshamer points out, there is a pretty fine line between everybody owning the code and nobody owning the code. Instead of maximising flexibility and code quality as intended it becomes a tragedy of the commons.
I’m not sure there is a simple answer to this problem. However, unlike Messrs Henry and Bracewell, it’s nice to be able to work through these trade-offs without the media scrutinising every decision.