The Four Sources of Authority: Where Agile Teams Actually Authorise Each Other

Three people, three authority structures

The Scrum Master had the role, the title, and the explicit mandate from the programme manager. She had been through the certification. She facilitated the ceremonies. She had formal authority from above. And yet, when she asked the team to try a different approach to sprint planning, she was met with polite deference that changed nothing. Three days later, the senior engineer — who had no special title, no certification, and no formal mandate — mentioned in standup that the planning sessions were taking too long. By the next sprint, the format had changed.

Separately: the product owner's decisions were technically final. His formal authority over the backlog was clear in the team's working agreement and confirmed by the engineering manager. But every significant priority decision he made was relitigated in the next planning session, often with the engineering manager drawn in as an implicit adjudicator. His formal authority from above was not matched by the authority the team actually recognised. Meanwhile, the engineering manager — who was technically outside the team's daily operations — shaped every significant technical decision by the weight of her opinion in corridor conversations she was not supposed to be having. All of this was invisible in the role chart.

Obholzer and the Tavistock authority framework

Anton Obholzer, working at the Tavistock Clinic and in organisational consultation, developed an analysis of authority that distinguished four distinct sources. His context was not Agile teams. It was psychiatric hospitals, voluntary organisations, and medical institutions where formal authority was chronically misaligned with actual authority — where the person whose role gave them the right to decide was routinely not the person whose opinion determined the decision.

Obholzer's argument: we speak about authority as though it were a single thing that comes from role and is delegated downward. In reality, authority has four distinct sources, each independently variable, and each influencing behaviour in ways that formal role analysis cannot capture. The four sources are: from above, from below, from alongside, and from within.

The four sources

Authority from above is the familiar one: formal delegation, role-based, sanctioned by the hierarchy. It is what the Scrum Master's certification and the product owner's backlog mandate represent. It is necessary but not sufficient. The authority chart and the working agreement document this source. It can be assigned, revoked, and transferred.

Authority from below is the authority that followers grant, regardless of role. It is not assigned. It is recognised by the people it operates on. The team that follows the senior engineer — changes its behaviour in response to her opinion, defers to her in technical decisions, modifies its plans when she expresses discomfort — is granting her authority from below. This cannot be mandated into existence. A Scrum Master who has formal authority but not authority from below will find that the team complies without changing: they will produce the outputs the process requires and return to the behaviours the process was intended to disrupt.

Authority from alongside is peer recognition — the acknowledgement by colleagues that a person has standing to act, to speak with weight, to be taken seriously in this domain. It is different from being liked. The coach who is liked but whose observations are not weighted seriously by the team does not have authority from alongside. The coach whose observations consistently shift how the team sees its own dynamics has it. Peer recognition does not transfer between domains: the senior engineer whose technical opinion carries weight may have no authority from alongside on process questions, and vice versa.

Authority from within is self-authorisation: the internal conviction that one has the right to act, to take up a role, to speak as if one's perspective matters. It is entirely independent of the other three sources. A person can have formal authority, significant followership, and strong peer recognition — and still act as though they need permission before each significant action. This is a deficit of authority from within: they have not authorised themselves to take up the role they occupy. Conversely, a person can have minimal formal authority and limited followership and yet act with complete conviction, taking up space, shaping conversations, and influencing decisions by the sheer quality of their self-authorisation.

Why this matters in Agile teams

Agile frameworks deliberately reduce authority from above. The Scrum framework distributes formal authority across three roles — Scrum Master, Product Owner, Developers — and explicitly positions these roles as replacing traditional hierarchical authority over the work. The flat team is a structural redesign that removes one source of authority and leaves the other three unaddressed.

What happens when authority from above is reduced but the other three sources have not been redesigned: the informal authority structure — the one built from followership, peer recognition, and self-authorisation — continues to operate, now without the structural constraint that formal hierarchy provided. The person with high authority from below and high authority from within becomes the de facto decision-maker, regardless of what the role chart says. The person with high formal authority but low authority from below and low authority from within becomes a process manager who produces ceremonies but does not shape the work.

Coaches who read this pattern as a mindset problem, or a personality clash, or a resistance to the Agile roles, are reading it through the wrong lens. The pattern is structural. The informal authority structure is doing exactly what any authority structure does: determining whose voice shapes decisions, whose discomfort slows action, and whose conviction the team follows when the formal process is ambiguous.

How to use this framework diagnostically

Mapping the four sources for the key people in a team engagement takes less than a single observation session and reveals more about the actual authority structure than months of working agreement development. The diagnostic questions: Who does the team follow when they disagree with the formal process? (Authority from below.) Whose observations shift the team's understanding of its own situation? (Authority from alongside.) Who acts with conviction and who acts with hesitation, regardless of their formal role? (Authority from within.) And who has formal mandate that is not matched by any of the other three? (Authority from above, unmatched.)

The answers reveal the actual decision-making architecture. They also reveal the most common mismatches: the technically brilliant engineer who has high authority from below and within but no formal authority — whose influence the Scrum Master cannot manage because it operates below the level the Scrum Master's tools can reach. The product owner with high formal authority and good peer relationships but chronically under-authorised from within — who consistently defers on decisions that are rightfully theirs. The Scrum Master who has the formal mandate and good peer recognition but cannot get followership from the team's dominant informal leader.

Three moves

Map four-source authority before intervening on role dynamics. The team that appears to have a "Scrum Master effectiveness" problem usually has an authority structure problem. Before designing any intervention on the Scrum Master's facilitation skills or the team's compliance with the process, map all four sources for the Scrum Master, the product owner, and the dominant informal authority figure. The intervention target will change.

Develop authority from within in formally-authorised but behaviourally-deferential roles. The product owner who has the formal mandate but not the internal conviction will continue to relitigate every decision, because they are seeking the authorisation that their self-doubt is withholding. This is not a knowledge gap. It is not a confidence problem in the colloquial sense. It is a specific deficit in self-authorisation that coaching can address directly — but only if it is named as a structural phenomenon rather than a personal limitation. "You are not taking up the authority you have been given" is a structural observation. "You need to be more confident" is not.

Name mismatches between formal and informal authority as structural rather than personal. The team that follows the senior engineer rather than the Scrum Master is not being difficult or disrespectful. It is responding to an authority structure — the informal one built from followership and peer recognition — that is more real to it than the formal one. Naming this as a structural observation, rather than as the senior engineer behaving outside their role, opens a different conversation: what would it take for the Scrum Master to earn authority from below in this team, and what does the senior engineer need to do with the authority they already have?

Reading one quarter of the available information

The question "who has authority here?" has four different answers depending on which source you are asking about. The coach who only reads the role chart is reading one quarter of the available information. The team's actual authority structure — the one that determines what gets decided, by whom, and how — is built from all four sources simultaneously, and those sources are frequently misaligned.

The Scrum Master who cannot get followership is not failing at Scrum. The product owner who cannot hold a decision is not failing at product ownership. The engineer whose informal authority shapes every significant technical choice is not undermining the process. They are all operating within an authority structure that has not been diagnosed, named, or worked with. The map of all four sources is the diagnosis. Every intervention that follows should work from the map, not from the role chart.