People who don’t work at Microsoft but who are aware of its jargon might encounter the term v-team and guess that it’s a team consisting of vendors, because the Microspeak term v-dash is used to refer to vendors (whose email addresses begin with v-).

It’s a good guess, but in this case, it’s wrong.

Tasks at Microsoft typically map to organizational boundaries. (Organizational boundaries having been chosen so that tasks fall nicely within them.) A memory management feature will be handled by the memory management team. A user interface feature will be handled by the user interface team. But there are some tasks that span teams, and for those cases, Microsoft managers like to create a virtual team, usually abbreviated v-team and pronounced vee team. (Not to be confused with the Virtualization Team.)

The defining characteristic of a v-team is that the members of the v-team come from different parts of the organization. For example, you might have Alice from the Power Management team, Bob from the User Interface team, and Charlie from the Networking team working together to design cloud-based notifications. These people do not share the same immediate manager, but for the purpose of this feature, they’ve been plucked out of the tree and formed into a self-organizing team to solve a particular problem.

These virtual teams are formed as needed and conversely are disbanded when no longer needed. Some may be short-lived, like a virtual team to review all the sample apps for the //build conference, which disbands once review is complete. Others may last for the duration of the project, like a virtual team to debug performance issues.