Where should authority lie?
So, you want to become “Agile”? You have heard of “Self-Organising Teams”. The general advice is to empower these teams… but you have misgivings, the results indicate empowering the teams is not working too well. However to give the typical knee-jerk reaction and say “Self-Organisation doesn’t work” might be a bad move; you are ceding the advantage to the organisations who do get it to work well for them. The debate over where authority should lie has been running, occasionally raging, on the forums for years. Let us look at a few of the issues and get a better idea of what might work for you, in your context.
Context matters
How much do you need to understand to be able to run your business effectively? Traditional organisations that earn their living through building, making, and doing, whose ‘product’ is relatively stable and doesn’t need a lot of effort spent on development, can manage fairly well without devolving many decisions. No single person is likely to understand enough to run the business well, but a single team (often a board of directors) can make the key decisions. Where the understanding is broad enough and sufficient in other respects, and there is an effective mechanism for getting this understanding to the fore where needed, this approach can work. It has worked for centuries. However, not all organisations are chiefly doers and makers; and of those that are, the pace of change might mean that they need to expend considerable effort in product development. This shift toward higher proportions of “Knowledge Work” means that it is becoming increasingly hard to encompass all the understanding that is needed within a single team of ‘directors’.
Before addressing the question of ‘authority’ I will set the scene for ‘self-organisation’
To get the best out of the practice of “Self-Organising Teams” the teams should be ‘designed’ to do a job. As near as possible this should be an end-to-end job, “Concept to Cash” as Mary Poppendieck puts it. This is to reduce the dependencies on other teams as much as possible. Dependencies impede agility; impede the organization’s ability to respond to challenges. Within the team, the members self-organise to get the work done, ensuring the best available expertise is applied wherever it is needed. It should be clear that the team therefore needs, somewhere on the team, enough expertise to get the job done. Failure to get the correct expertise onto the team is a common cause of failure, and failure to support the team to grow expertise that is missing or in short supply is another cause of failure. Expecting this expertise to appear by magic is not very sensible, but failing to allow the team to grow the expertise is the most common form of failure; the most common reason for people to say “Self-Organisation doesn’t work”.
In particular, a team that has had all its best people promoted out of the team over the years, and has always had a leader organising the work of the team, will take quite a while to grow the expertise that has been removed or suppressed. While I do not think it is the best solution, a common approach to this specific problem is (in development work) to add a Scrum Master to the team. Unfortunately having a certificate doesn’t make a person a Scrum Master; what is needed in this specific context is 2 years or more of experience working on self-organising teams, and the ability to impart the lessons learned through this experience. This is a specific example of getting skills and experience onto the team by adding a team member who has the skills and experience. Note that this should be done with care; changing team membership is always disruptive.
Another common mistake is that people think “Independent” or “Empowered” implies “Uncoordinated”. Well, it can, but that doesn’t need to happen. For the team, the team as a whole gets feedback and any performance measurement for any work that the team does. Individual performance assessments reward individual efforts and poison self-organisation; we want the team to have incentives to work as a team. So, within the team there is coordination because there is motive to coordinate. Where coordination is needed across several teams, make it known that this is desired – either by performance measures or just by saying it is desired. And make space for that to happen. Ensure the motivation to coordinate across teams is greater than the motivation not to coordinate. To encourage coordination, measure a level up. For coordination within a team, measure the team as a whole. For coordination across teams, measure the team of teams.
There are many other possible forms of failure at the team level. Key to addressing these problems is to have at least one person who understands what is going on, close enough to what’s happening to see that problems have started. These people should know what it means to be on track, know when things have started to go off track, and know-how to get things back on track. Get those three things right all the time and it becomes very difficult to fail. But one further thing is important; they should be transferring their skills and understanding to the rest of the team. Keeping on track is everyone’s job.
So, where should “authority” lie?
In short, for the best results, “authority” should not be divorced from “doing the work”. But how important is this guidance? How much does it vary with context?
For simple work (production work, perhaps; Cynefin quadrant 1) the separation might not matter too much. Having the expertise and authority lie with the board of directors might work well, because there are few decisions that need to be made in the work where the domain is characterised by “known knowns”, the situation is stable and the relationship between cause and effect is well known. The work itself can be done by robots or relatively low-skilled workers.
For complicated work (Cynefin quadrant 2), is work characterised by “known unknowns” and can for the most part be controlled by “When Do ” rules. The expertise can be from specialists close to the work, advising the people doing the work on a daily or hourly basis. The work itself needs people who can grasp the rules and recognise where the rule set is incomplete and there is a need to consult an expert.
For complex work (Cynefin quadrant 3), the domain is characterised by “unknown unknowns”, cause and effect can often only be attributed in retrospect. To get useful the only real solution is that the people doing the work need a fair degree of expertise so they can make good decisions most of the time without help, and need immediate access to good expertise for cases where they cannot.
For chaotic work (Cynefin quadrant 4), there is no choice. The person ‘doing the work’ needs to decide on the spot how to act (or decide not to act). They necessarily must have the authority because there is no alternative. It would be mismanagement to allow somebody into a chaotic situation and then penalize them for making what turned out to be bad decisions. The only viable preparation for chaotic situations is to ensure people have broad experience, and plenty of it, so there is a chance that they have had to make similar decisions in the past.
Wherever the expertise lies; there, also, should lie the authority to apply it. Depending on the nature of the work you may get away with separating the expertise from the work, so you may get away with separating the authority from the work. But trying to separate authority from the ‘doers’ in contexts where the expertise needs to reside with the doers, would be a mistake. And if that’s where the authority should lie, your organisation structure needs to be built accordingly.
