Reinventing “teams” (and renaming them at the same time)

5 minutes read


The limits of my language …
mean the limits of my world
Ludwig Wittgenstein

One of the seldom-noted side effects of various new forms of organizing is the enrichment of the language with which we describe organizations. Arguably, this broadening of the terminology itself supports organizational innovation. It allows us to distinguish, for example, between different organizational entities and forms. Tribes, squads, chapters, or guilds may all be incarnations of units or teams. And yet, those labels are not just fancy new titles for something well known from tons of social group research. On the contrary, they represent an ambition to try something new when it comes to structuring and leading teams and organizations. The concepts they stand for convey an idea of how an organization as a whole should function, and present an opportunity to learn from experiments in order to enhance classical management ideas.

In this blog post we collect examples of various terms used for social groups, many of which don’t yet have an accepted “orthodoxy” or even a widely shared definition. And that’s good, because it makes it easier for their meanings to further develop – or for organizations to invent new terms altogether. As such, this (incomplete and growing) list of terms is not intended as a work of reference, but as inspiration to inform business design discussions about teams, and have some fun along the way. Because, as we have seen in our project work time and again, it’s much more exciting and engaging to work on a concept that your team generates by itself.

Do you feel we are missing an important example? Any other terms we should add to this list? Some funky new concept you came up with for use in your organization? Shoot us a note or leave a comment below!


“Cabal” is the title for project teams at the game design company Valve. Cabals are multidisciplinary teams. As project teams, they are temporary. They exist to develop a large product or product feature. Their most striking feature is that they form organically, as employees deem necessary, or as Valve’s handbook states: “People decide to join the group based on their own belief that the group’s work is important enough for them to work on.” Cabals decide whether and which organizational structures are necessary (in contrast to a standard and shared team methodology that is defined upfront and then rolled out across the whole organization). There are “de facto leads” in cabals but no formally imposed and assigned leadership roles.


“Circle” is the core term used for teams/working groups within the system of Holacracy (Please note that Holacracy is a trademark of the firm HolacracyOne). A circle has numerous formally defined roles and design features, including rigid process scripts for decision-making. This design allows for individual membership in numerous, partly overlapping circles (membership in the sense of assuming a role in a circle). Allocation, and in fact definition of roles and thus membership in circles, is subject to self-organization within the framework of a formalized governance (the Holacracy constitution). There is a uniform template for working roles in a circle and necessary governance roles, including lead link (responsible for resource allocation), rep link (representing the circle in governance processes outside the team), and organizing roles, namely the circle’s facilitator and secretary.


“Squad” is a label commonly used for agile development teams. The broader significance of squads for organization design – that is, beyond the methodology for software development that “agile” usually stands for – lies in their integration into a broader model of “tribes, squads, and chapters”. This type of model was implemented in a massive reorganization at ING, mostly based on a model developed by Spotify, but also drawing additional inspiration from other companies. While there is much to be said about the broader model, the structure of squads as such offers relevant inspiration for structuring and leading teams. Each squad contains no more than 10 people. In terms of roles, the model features: a tasks product owner, who is responsible for a squad’s output (the “what”); a (functionally aligned) chapter lead, who is responsible for the “how”, with regard to a specific function, e.g. design, as well as for the development and performance management of people working within the function; the tribe lead, who is responsible for knowledge sharing between squads within a tribe (a tribe comprises around 150 people); and an agile coach, who is responsible for coaching individuals and squads. Guilds are an additional, cross-cutting entity within the construct, similar to communities of practice, and are made up of people from different squads/chapters and tribes.

Taking new routes

There are several general conclusions – or better, inspirations – that we can derive from these examples, especially for going beyond classical hierarchies and team set-ups in organization design.

First: differentiate leadership roles beyond a single boss who has direct authority over the team members.

Second: in differentiating this role, consider, among other things, purpose and goal setting, coaching, functional skills, and relationships to other units within the organization. These and other examples show that these responsibilities, which contribute to team success and represent leadership roles, can be designated to different people within the team. (In fact, high-performing teams in classical structures find ways to do this in any case – and their formal leaders often play an important role, but not an exclusive role, in making leveraging the power of self-organizing for team success).

Third: consider elements of self-organization when it comes to team membership and team leadership, and think thoroughly about the level of formalization you apply to those mechanisms.

Fourth: learn from these and other examples but don’t stop innovating! Change always involves an element of innovation in the very context you’re working in, and it will never be about simply plugging in “best practices”.

A case in point: an organization we have the privilege of working with calls management work groups outside their core development business “branches”. Each branch is defined by a charter, which describes the purpose, scope, and agreements of the branch. The charter is defined by the team itself and is a living document that can evolve as the context and the purpose of the tasks change. The design of the branch includes example questions that must be answered in order for the branch to come into being, a list of attributes, and formal conditions for a branch’s inception.


Bernstein, Ethan, et al. (2015): Opening the Valve: From Software to Hardware. Harvard Business School Case 9-415-015.

Birkinshaw, Julian (2018): What to Expect from Agile. MIT Sloan Management Review 59(2), 39–42.

Robertson, Brian J. (2015): Holacracy. The New Management System for a Rapidly Changing World, New York: Holt.