Consider two schools of thought - let’s call them teamism and reteamism.

For the teamist, a team is more than the sum of its parts. A team is superpowered by a close shared understanding built up over time, a sense of autonomy and effectiveness that comes from cradle-to-grave responsibility for their ongoing deliverables. The teamist philosophy allows that true teams take time to form (and, if you like, storm, norm and perform…) and to mesh into a cohesive unit and yearns for stability to allow teams to blossom.

The reteamist values the benefit of common expertise and the ability to redeploy people to where they are most needed. They view professionalism as an ability to slip into a new team or project at short notice and be productive instantly. They would have teams created and disbanded frequently according to business need because, for the reteamist, it is all ultimately “one team, one dream”.

The division reflects many other oppositions.

  • Teamism sees products. Reteamism sees projects. For this reason, consultancies and agencies are invariably reteamist and often rely on a rigorously reinforced shared ethos to be so.
  • Teamism stresses team ownership of services and applications. Reteamism stresses common ownership of all code.
  • Teamism accommodates diverse tech stacks. Reteamism requires homogenous tech.
  • Teamism emphasises team responsibility. Reteamism emphasises individual accountability. For this reason, some organisations find too much teamism incompatible with their performance management and remuneration schemes.
  • Teamism more easily accommodates evolutionary delivery. Reteamism is substantially eased by an emphasis on right first time. Teamism can accommodate levels of technical debt which would be irresponsible in a reteamist world.
  • Reteamism offers better resource efficiency. Teamism entails some tolerance of slack.
  • Reteamism offers fulfilment through mobility, variety and chances for individuals to shine. Teamism offers greater chances to work across technical disciplines within a known and safe context, stronger team spirit and arguably better support.
  • Reteamism works well for rock stars. Teamism offers better support for non-rock-stars.

These are caricatures. In reality every organisation blends the two philosophies and finds ways to mitigate the downsides of whichever philosophy is predominant. Reteamism at a small scale often exists within teamism at a higher scale. In very small organisations the distinction is academic.

Predominantly teamist organisations sometimes artificially stress reteamism for new recruits to broaden their initial experience, seconding them through a variety of teams in quick succession.

Alternatively predominantly reteamist organisations sometimes apply more teamist sensitivities with new recruits to give them an easier environment to learn in.

Tech companies with team ownership of services there usually exist shared codebases and extra-team structures and responsibilities which offer vehicles for personal development and career progression outside the team structure.

Small organisations are almost invariably reteamist at first when they don’t have the luxury of slack. Large organisations tend to become more teamist as they adjust to inefficiencies of scale.

There are certainly some bad ways of combining the two philosophies. A stable team with a sense of permanence can take on technical debt under the expectation that the they will manage and repay the debt. If that ownership is ripped away the debt remains but the management disappears. Reteaming in a teamist context is more like aborting the team, and this is a mismanagement of expectations.

From my experience, arguments on this stuff can get really heated, so its important to recognise the shortcomings of each viewpoint when trying to find the right balance.

The teamist must accept and agree that people will end up working on unimportant tasks while critical business needs go unserved and that others will find this unpalatable. They must admit measures or compromises intended to make this effect infrequent and unpronounced. They can contend that the impact of eroding team ownership outweighs occasionally inefficient delivery of business priority but they must not make their position ridiculous and must recognise that there are circumstances in which even they would turn everyone aside to swarm on an emergency project.

The reteamist must recognise that some longer term priorities will be deferred indefinitely as the organisational make-up evolves to match shorter term priorities and they will likely have to introduce special measures or teams over time to address items that don’t fit elsewhere. There may be unloved parts of the codebase that no-one wants to tend to, unloved users who make do with manual workaround, or cross-cutting concerns that cannot be serviced by all the other teams “pitching in”.

Neither seems to be exclusively better for team members. Some people flourish under one regime, others in the other.