Richard Hackman, a Harvard University professor, described four levels of allocating authority to teams. Let’s look at Hackman’s four levels of team authority, starting with teams with the least authority.

Teams with the least authority are manager-led teams. A manager-led team has authority to perform the work it has been assigned. But a manager-led team does not have authority over its process. That remains with the team’s manager.

Next are what Hackman referred to as self-managing teams. In addition to performing the tasks, a self-managing team manages its own process. A self-managing team can decide how it will work. It could, for example, decide to use (or not) an agile approach.

Increasing authority is given to self-designing teams. A self-designing team is given the additional authority to modify who is on the team. This type of team can kick a person off the team, decide to hire or transfer an additional person onto the team, and so on. In some cases, a self-designing team will also be given authority over reporting relationships both within the team and with those outside it.

The final type of team, and the one with the most authority, is a self-governing team. A self-governing team is given the additional authority to change the team’s main purpose. A self-governing team could decide to build the video game instead of the acoustic measurement product.

The four types of teams are summarised in the following table.

TYPE OF TEAMS	AUTHORITY
Manager-Led	Authority only for performing the work
Self-Managing & (self-organizing)	also has authority over how work is done (the team’s process)
Self-design	also has authority over who is on the team and sometimes over reporting relationships
Self-government	also has the authority to alter a team’s main purpose

Where Does Self-Organising Fit?

In Hackman’s authority hierarchy, self-organising agile teams would be classified as self-managing teams. Agile teams manage their own work (which team member should do this task?) and how they go about that work (should we start with Kanban or Scrum? How long should our sprints be? Agile teams are not, however, self-designing or self-governing. In other words, a self-organising agile team has authority over its work and the process it uses, but not over who is on the team or the team’s purpose.

So, is it self-organizing or self-managing?

You can call it either one or both. My personal preference is for self-organisation for two reasons:

First, that is how it was described in the first published article on Scrum, the oldest agile framework. The authors of that paper, Takeuchi and Nonaka, considered self-organisation to be one of the six characteristics needed to create a “fast, flexible process.”

Second, I find the origins of the term self-organising in chaos theory useful in thinking about team behaviour. The flocking of birds in flight is self-organising behaviour. So is an ant colony, a beehive, or the pattern of cars on a highway. These examples of self-organisation in nature often provide useful, illustrative examples of what self-organisation may mean to an agile team.

For example, living as I do in Colorado, I often see prairie dog “towns,” collections of tunnels these small animals dig. Prairie dogs don’t dig their tunnels according to some preconceived master plan. They dig, and if they hit a rock, they dig around it. A team starts in one direction. If that direction proves untenable, the team alters course around the obstacle, just like those prairie dogs.

So, self-organisation is my preference due to its history in the agile literature and the usefulness of examples of self-organisation. But self-management is equally good if you prefer it.