Virtual teams

The two examples I just discussed don't answer an important question: who takes care of the platform itself? As your team grows, so do your needs for infrastructure and maintenance.

Platform teams trouble me conceptually because I strongly believe in No privileges, no elites. Their work is different by definition, it feels like elite work. Platform engineering is horizontal to the whole product development organisation, so they have access to everything. After all, the whole point is to be a multiplier for everything else. So it couldn't really work any other way. Virtual teams is how I reconciled the need for platform engineering and staying true to my "no privileges, no elites" value.

The idea is doing with teams what you sometimes do with views in a relational database. Views have the same shape and behaviour of tables, but they often take data from multiple tables. Virtual teams are the same: they have a name, a mission, a backlog, and a roadmap. They don't have team members as they are composed of team members of other teams. They take from multiple teams.

The way you do this is by over-staffing physical teams enough so that they can go on without a team member or two for a few weeks at a time. Every X weeks team members go back to their physical teams and new ones join a virtual team. This seems like a lot of trouble, so why would you want to do it? Well, I think the benefits overcome the disadvantages:

• Everyone learns enough about whatever the "special" team is doing.
• Everyone practises handover often, a process vital to smoothly managing holidays and off-boardings.
• Everyone learns how to run systems and not just build product features on top of them.

Scheduling rotations can be a burden on the leaders of the organisation, so I suggest you ask the teams to help with the scheduling. A major problem with virtual teams is that it can be complicated to keep them diverse so that they can do a good job.

A practical approach to simplifying scheduling is to have some "pivot members": team members that officially belong to a virtual team. I think it would be fashion nowadays to call them Staff or Principal engineers. Their job is fun, they get to interact with literally everyone while being focused on their specialty and roadmap.

Apart from platform needs, virtual teams can also help with short-lived projects. Here are some examples:

• Complex data migrations

  One way you may end up there is after an acquisition. Your company buys a competitor in the space and you have to merge data. These projects are hard, they disrupt the flow of physical teams. Virtual teams mitigate the risk by isolating the effort.

• Feature peak in one area

  Special sales may have this effect: a bunch of features that would normally belong to one team needs special attention. Partnerships with other companies may have the same effect.

• Training activities

  Sometimes you migrate to a new technology or change a part of your system to a new language. In these cases, not everyone on your team is already trained. Such initiatives can help your organisation become self-learning, that's a wonderful achievement in itself.

These examples are a testament of how flexible virtual teams are.