+353 1 901 4177 info@mind-digger.com
Select Page

When we talk about working in self-organising teams, we often don’t pay enough attention to the topic of authority or we say that “the team has authority”. Unfortunately, this vagueness results in various problems, such as: poor decisions, decisions not made, decisions delayed, conflicting communication with external stakeholders, usurpation of authority by a product owner or scrum master or the most experienced person (in Scrum teams), important aspects of work being ignored (“engineers don’t care about business”), and more.

In this article I would like to take a look at what is authority, why is it important, and what can a team do about it to keep things simple and efficient.

We know that there are three sides to leadership:

  • Authority – the right to make decisions, give orders or to act in a specified way.
  • Power – the ability to do something.
  • Influence – capacity to have an effect on other people’s actions.

For example, a manager has an authority to give order to workers to put one left and one right shoe into a box, an experienced colleague has influence on how that work is done (by teaching and serving as a role model), and worker has the power to carry out the action (or to put two right shoes into a box if they decide so).

So when we talk about authority, we talk about the right to make decisions, which is also necessary when a team needs to be represented in negotiations. To be useful, authority should be legitimate – the decisions should be recognised and abided by the people with the power to carry out actions. There is no point to having this right if decisions will not be implemented. So, to have a working system, people with power should recognise authority as legitimate, to the extent that they will follow through even with decisions they personally disagree with.

Authority can be implemented in two ways – as a procedure of making a decision (referendum for example) and be granted to an individual. A mix of two approaches is also possible when a particular process needs to be followed by an individual or a group of individuals (committee) to make a decision.

To make work as effective and as efficient as possible, we want to make good decisions as fast as possible. To make sure that we work in a robust way, we need to ensure that this process doesn’t break easily.

To achieve that we might want that our system of decision making is:

  • Smart: Decisions are made by people with knowledge and experience in the topic. For example, technical decisions to be made by a person with the highest level of expertise.
  • Aligned: Decisions are made in correspondence with the team’s agreed principles or criteria.
  • Fast: Decisions can be made by a small number of people – to speed them up.
  • Reliable: Decision flow doesn’t stop when one person is absent (in larger teams – when two or three persons are absent)
  • Explicit: It is clear which decisions are made in which way and who has authority to make what kind of decisions
  • Adaptable: We have a way to change our approach to decision-making and distribution of authority

So, to satisfy these requirements and also to have a representative for negotiations, here is the structure which was successfully used in the teams I worked with.

  • Principles we follow and the way of working are decided by the whole team. A “retrospective” is used for this.
  • All the areas of responsibility (things we care about) have a single individual who has full authority to make decisions regarding that area and a second person who provides advice and takes over this authority when the first person is absent.
  • The same individual is responsible for ensuring that the area of responsibility properly attended to – i.e. that necessary work is done for it.
  • Authority is distributed by team members volunteering for each area of responsibility (as a main/second).
    The way we usually do that is by writing each area of responsibility on stickies of a different colour for primary and second and letting people pick the ones they like. Unless there are objections from other team members, then this person gets the appropriate authority. Any disagreements are discussed and adjustments made based on the outcome of the discussion.
    The final distribution is recorded and made available to team members and external stakeholders as necessary.
  • Authority can be redistributed as necessary if a need arises or the team decides that current distribution is not working well.

I found that this kind of distribution helps to make the decision-making process much smoother, while pairing helps to keep teamwork robust and distribute the knowledge of each of the areas.

At the same time, authority to some decisions can be distributed among the members of the team, so they have the right to make these decisions autonomously. For example, all the developers have the authority to write the code in the way they believe is right as long as it corresponds to the agreed code style.

How do you clarify and distribute authority in your team?