What is it?
The authority model helps understanding of necessary considerations whenever and wherever decisions are taken. This makes it an example of how to reliably decentralise decision making. Organisations and teams make better, quicker decisions when all the authorities are included, and in balance. It’s a fractal model, applicable to individuals as much as to enterprises, meaning each of the authorities could be represented by a single individual, a team, or entire departments.
It underpins most scaling frameworks, and is common in Service-based Organisations, in product thinking, and in Corporate Rebels type ‘progressive’ organisations. It is an agnostic way to scale decision making, that doesn’t need a complicated framework. By ensuring the three authorities are represented at each level, organisations can grow and develop their own ways of working without importing a mountain of process that might not suit it.
It describes three ‘Authorities’:
The Product authority - build the right thing. The product authority is eternally concerned with Value – however it’s defined in each particular context. It considers customers and users, having a deep understanding of them and their needs. This authority facilitates the conversation with competing stakeholders, synthesises and combines this into a single demand, and makes scope and priority decisions to maximise value.
The Technical authority - build the thing right. If the product authority occupies the problem space, the technical authority occupies the solution space. Ensuring the work done, or the thing that’s built is technically feasible, and is of suitable quality. This includes everything relevant in the context, such as security, Non-Functional requirements, professional standards and supportability. They will maximise value through innovation, focus and simplicity.
The Practice authority - build it fast and efficiently. Often the authority least easy to map to existing organisational functions, the practice authority considers and creates the environment in which the thing is built. Is it sustainable, efficient and repeatable. Is there consideration to continuous improvement in both the product, and the ways of working? Are impediments being systematically identified and removed, and are the other functions able to focus on their outcomes. The practice authority is the servant leader for the others.
The overlaps in the diagram show that these are not stand-alone, siloed functions - everyone and every function has some responsibility for each. This is what is really meant by the oft-overused term ‘cross functional teams’. While there will often be a ‘lead’ in each authority, it’s a whole team commitment. Any nominated leads are simply representatives for the authority, rather than holding the authority themselves. Each area bears some responsibility for the success of each of the others.
In addition to this, each of these authorities should be in a constructive tension. It’s only when there’s a balanced consideration of all the authorities do you get consistently good decisions and hence products.
What is it useful for?
The model provides a framework for good decision making, and aids the rigour, transparency, and speed of these decisions. Good products and services are based on balanced decisions that consider all aspects of the authority model, bad ones result from instances where one or more authorities eclipse the others.
For example, a common anti-pattern is seen when the representative of the Product Authority is synonymous with the boss - either a higher grade, or with some line management responsibility for the other authorities. In this case, there is a danger that the thing built is indeed exactly what the user wanted, and ought to address their need perfectly, except it doesn’t work properly, is of poor quality, and was rushed to partial completion following an unsustainable effort by the team.
Or another example is that of the all-powerful technical authority with the ‘compliance’ red card. In which case a product of quite exemplary quality is finally released, only to find it’s not really what anybody wanted and the market’s moved on anyway.
Examples where this works well abound in progressive organisations. User-focussed design and product thinking practitioners from the ‘problem space’, working hand in hand with engineers or technical experts identifying the right fit in the ‘solution space’, all facilitated and enabled by delivery leads who encourage sustainability, continuous improvement and rigour. Collaborative teams of this nature produce enough value, at an appropriate quality, in an enduring fashion.
Example implementations
Perhaps the most immediately obvious implementation of this model is within a scrum team. Here we have a Product Owner representing the Product Authority, a Scrum Master representing the Practice Authority, and the Development Team representing the Technical Authority.
Scaling mechanisms such as SAFe often then extend this model, for example in a SAFe Agile Release Train of several Scrum Teams, we have Product Management, a Release Train Engineer, and a System Architect each representing the authorities.
When you’re familiar with this model, you start to see it implemented everywhere. A Service might be thought to consist of a Product Management team, a Service Support Office (SSO) and the teams delivering the Service itself, each representing Product, Practice and Technical respectively:
But then the SSO itself would have representative of each:
And the teams collectively representing the Tech Authority would also themselves have representation of each:
So what?
As a leader at any level, this can help unlock organisational inertia by reducing decision latency. With this model as a framework for decision making, you can make better decisions, and better decentralise and empower your teams in the same way. Leaders don’t need to provide all the answers, or to come up with all the solutions. And teams don’t need to wait for decisions or approval to do amazing things. Leaders can set the vision and intent, and teams can get on with finding, building and running the solutions.