There are few people who have truly deep expertise in agile transformation, comprehensive understanding of business agility, and an ability to articulate complex concepts effortlessly. After reading Agile IT Organization Design, I conclude that its author Sriram Narayan is one of those people.
Sriram demonstrates everything I aspire to. He has complete understanding of organisations - code, architecture, process, leadership, finance. And he knows how all of the pieces need to fit together in complex systems to form high peforming organisations.
I'll try and summarise how I came to this conclusion by sharing a couple of my favourite highlights from the book.
This will be hard reading for many, even those who consider themselves agile veterans.
Sriram argues that autonomy is the foundation of high performance organisations. Teams must have high autonomy over what they work on, not just how they implement it. But there's a catch.
If teams are all super autonomous, they will all go off in different directions. Sriram terms this runaway autonomy, and it's a genuine concern. So is the answer more management and control? Nope.
The answer is to align teams with business outcomes. If the goal of a team is to improve a business outcome, then it will be oriented toward system level benefits.
Outcome orientation is enabled by forming truly cross-functional teams, carefully analysing business outcomes, and appointing outcome owners.
Along with examples, Sriram goes into detail talking about many of the nuances and challenges of enabling outcome orientation. He also introduces tools like alignment maps.
So why will this be hard reading for many? Well, if you're a function lead - a head of engineering, testing etc. - then in Sriram's model you no longer have direct reports. You have influence but not control. Everyone reports along outcome oriented, not functional, lines.
Budgeting is crazy. I've seen people leave companies because they asked for a payrise at the wrong time of year when all the money had gone. I've seen teams with too many developers and not enough product managers because dev and product are different budgets, so developers end up building half baked ideas just so they're busy.
I know contractors who were hired on huge day rates onto projects they weren't needed at. Why on earth would that happen? Because management need to spend all the budget so they can ask for more at the next annual budgeting cycle.
Sriram explains these perverse phenomena are common because modern budgeting has origins in classic hierarchical managment. If you want a truly agile organization and not just a few dev teams churning out code every 2 weeks you need agile budgeting.
So what would that actually look like? According to Sriram, feedback cycles must include budgeting. Your budgeting cycles should be monthly and they should be collaborative. If your organisation acquires feedback but cannot act upon it due to budgeting constraints, finance is the bottleneck.
Equally, CapEx and OpEx are no excuse for organising people around functional silos. Sriram demonstrates how it's possible, with a bit of effort, to approximate the volume of each variety of work in cross functional teams.