Balancing Autonomy With Accountability

Many organizations are embracing Agile ways of working in an attempt to build faster, more customer-focused and resilient organizations. They are redesigning themselves to create a culture where decision making is transitioned away from middle management towards those working with customers on the front lines. Ultimately, they seek engagement in order to create a culture where staff is empowered to truly delight customers. Autonomy is the critical ingredient; however, autonomy is often misunderstood. Many organizations think they just need to increase autonomy, however, they forget to include the counter-balance of accountability, often with disastrous results.

Recently, many senior leaders have shared a concern with Radically. It is happening so much that it is becoming a pattern. They are telling us, often with hushed voices, that they feel they cannot ask important business questions such as, “When do you think this will be done?” or, “How is cost tracking?” or, “Will we hit our launch date?” When they do ask these questions, they get proudly shunned and told that these questions "aren't Agile".

Perplexed, they feel stuck. Do they go back to their old ways and demand answers (which they know will be fabricated anyway)? Do they dare mess with the new Agile culture and risk being seen as "a manager", the evil conspirator who is secretly trying to stop Agile and control everyone? Or do they try to manage the business without the vital information required to make decisions? The end result is managers on tip toes.

The problem is that they have increased autonomy without increasing accountability.

One firm wanted to increase autonomy by empowering their people to put forward initiatives that would be funded based on their ability to help deliver the strategy. The “how” (the execution of initiatives) would be entirely up to the proposer, giving the teams freedom and flexibility to focus on delivering the best outcome as the work progressed.

All sounds awesome, right? Unfortunately, it wasn’t, as year after year they encountered the same problem: 9 months into the year they would run out of money and the entire organization would then go into a capital freeze for the remainder of the financial year, causing significant disruption.

Why?

Firstly, those leading the initiatives were not being held accountable for actually delivering something of value. They were given a chunk of money at the beginning, based on forecast delivery of a business outcome. The intent was to give the teams autonomy, however without the counter-balance of accountability for how the investment was being spent, the teams failed to deliver.

The root cause was that they were still running a traditional governance model that didn’t understand Agile. The teams weren’t being held to account to deliver “done” increments of value every iteration. This resulted in the illusion of progress (“We are doing iterations, therefore, we are doing Agile!”), but nothing could be shipped to the customer. The catch-up stabilization and integration required a lot more budget.

The lesson: they decentralized decision making and control to provide autonomy but failed to establish the corresponding accountability. They went from centralized accountability to no accountability at all.

Another firm wanted to embrace Agile in order to build highly autonomous teams and attract the best talent in the market. They rapidly “delayered,” removing most middle-management positions and set the teams forth on a journey of self-organization. Teams were taught new ways of communicating, sharing and collaborating. Each team had a facilitator – a servant leader who would help the teams as required.

Again – seems awesome doesn’t it? However, when the CEO asked how many more iterations would be required to deliver the release, she was shocked to find the teams had no idea. Nobody knew whether this was on track nor did they know cost to date and forecast completion cost. Again, they went from a small group of managers being accountable, to nobody being accountable in the new approach.

Sadly, we often encounter this and the frustrating thing is that this is not (in our opinion) professional Agile at all. One senior leader we talked to called it “Kindergarten Agile,” another “Cupcake Agile,” and yet another "Jazz-hands Agile." It is often the result of well-meaning people who simply lack the business acumen to understand the implications of changes they are suggesting. They recommend autonomous squads, that team have lots of fun and we will measure success by team happiness.

Agile is based on transparency. When we have transparency, we can see what is going on change course accordingly. Accountability is very specific – in Scrum the Product Owner is accountable for value, the Team is accountable for delivering done increments and the Scrum Master accountable for the process.

Governance remains vitally important. It doesn’t disappear, it just changes, typically from a classical model where the focus is on schedule, scope, budget, quality, and risk, towards a modern model that focuses on value, risk, learnings, and then the next optimal move.

Management remains important, too. It doesn’t disappear. It just changes from a role that allocates work to people and then manages their progress, to a role that focuses on growing people, providing honest feedback and coaching them.

Business questions such as “When do you think this will be done?” or, “How is cost tracking?” or, “Will we hit our launch date?” are completely fair and valid. The difference is that we are moving from a world where we pretended to be able to know all of this upfront and would lock it down in a plan and then govern to that plan regardless, to one where we accept we don’t know it all up front and instead forecast these factors and continually update the forecast as we progress, enabling regular changes in direction based on the information at hand.

Don’t accept Cupcake Agile. Yes, autonomy plays a critical role in reshaping our workplaces, but don’t forget to balance autonomy with accountability.