A look into the science behind autonomy
What if I told you that you could give everyone in your org all the autonomy they want, and not increase risk to organisational continuity.
We start our ponderings by thinking about what autonomy means. What does it mean to be truly autonomous?
If we pop ourselves into a Utopian alternative universe, where there is no friction on any given decision, collaboration rules supreme, and everyone is skilled at everything. In this universe (and in our own) on each decision, there are three classes of individuals needed. Those that are responsible for implementation, those that are accountable for failure, and those that have the authority to sign off.
To be responsible for a decision, individuals need to know what the organisation expects from them. If they are delivering software, they need to know what the performance should be. If they are delivering car parts, they need to know the dimensions the parts need to conform to. Responsibility should be based on a shared, preagreed, collaboratively derived list of requirements, that must be met by any decision made.
In the example of cars, the team producing bolts, and the team that needs them, both agreed on what a bolt does, and what it looks like. Other than that only the bolt team cares about the production.
Having accountability means that each individual’s decisions are open for review by any other individual in the organisation. If the bolt team wants to hand cast the bolts using Lego dies, they are free to make that choice. However, they are the ones that will be held accountable if the Lego dies are not durable enough to meet demand quotas. In order for a team to be enabled to be accountable, they need to operate within a system of predictable metrics. For the Lego die example, perhaps, they would need to have prepared for die failure. It would be impossible for an individual or team to be accountable for (in the case of car bolts), service interruptions, if these were never part of the design in the first place. So having a robust operating model of service ownership and documented runbooks for failure, that articulates what problems could occur and what actions should be taken, would afford autonomy.
The final part of the triforce of autonomy is authority. I’ve often found that authority is often confused with autonomy. Authority without the other supporting members of the trinity would potentially just be an element of chaos (which we shall discuss a little later). Authority strives to allow individuals freedom of expression. In the case of the bolt producing department, the mere fact that they were able to use Lego dies, stems from the authority that had been placed with them. For a team to really have the authority, they will need a set of tooling that allows them to measure the impact of their choices. Say for example with the Lego dies compared the 3d printed dies. The lego dies may be cheaper, and the technical skill is bountiful in the market, yet the 3d printed productions are brand new, and only a select few have the skills to manage that process. Articulating this and accepting the risk completes our story.
What if the triplet is incomplete?
The diagram helps us visualise how the three roles are intertwined. It also helps highlight what could potentially be missing if we were to make a team autonomous with an incomplete set.
Autonomy without responsibility would manifest itself in teams not taking ownership of the changes that they are implementing. The standards to which each team is delivering to are not predictable. An environment where individuals or teams not motivated by responsibility would bread a “pass the buck” mindset.
Autonomy without accountability would lead us to a model where business processes are not managed or well supported. This would impact business continuity, as lacking accountability removes the impetus from individuals to create well designed and architected solutions. Lacking accountability could lead to relying on best efforts to resolve continuity issues.
Autonomy without authority potentially is the only type of autonomy that might work. However removing the authority would impact the pace at which teams are able to deliver. As evidence still needs analysing, and decisions still need to be made. This now falls outside the control of those trying to make the changes. In-turn this would increase the feedback loop of change.
We’ve discussed what autonomy means, what good autonomy looks like, and even how bad autonomy might manifest. What do we do with this information? How can we breed autonomy, and not increase risk?
Much like the autonomous cars built by Tesla, the design of the autonomous system needs to include failovers that allow for external auditors to ensure the process is being adhered to, without causing friction. This could be implemented in a push style model, where flaws in the interconnected autonomous units would be radiated to other units. The members of the autonomous units need to be held to account when there are issues, so as to breed that ownership mentality. With maturity auditability is less important. Moving towards an optimisation maturity level, design changes may include an element of decentralisation of the organisational level requirements.
Again, like the Tesla automobiles, the autonomous teams or individuals need to help the overarching framework mature. This is by improving the governance, guidance, and policies that inform other autonomous units within the organisation. After all, they are on the front line.
This loop of learning from autonomy and refinement of process is a symbiotic relationship that allows the teams to build autonomy.
Similar to two trees sharing the same roots this symbiotic relationship needs to develop over time.
The Author Harjit Sandhu is a Software Engineer with experience in strategy, delivery, and education.
