Book Review: Agile IT Organization Design

Agile IT Organization Design


Sriram Narayan

My Rating

star star star star
"Holistic coverage of designing organisations for high-speed product development, high alignment, and high autonomy."

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.

Outcome Oriented

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.

Agile Budgeting

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.


"it is less risky to grant autonomy to outcome-oriented teams. Since outcomes (or suboutcomes) are independently valuable and achievable, local optimization is less of an issue."

"A well-oiled IT delivery setup is not enough for a successful business outcome. Continuous delivery and DevOps are irrelevant if they don’t improve business outcomes."

"Although it may be necessary to split high-level business outcomes into suboutcomes, the process can be kept in check by using the testable, valuable, independent, and negotiable (TVIN) test. Failure of the test indicates that the suboutcome is not really a business outcome but a contributory activity"

"unscripted collaboration is essential for cultivating initiative, enabling innovation, and improving responsiveness"

"Business strategy comes first. IT can be aligned with business provided that business strategy is commonly understood and accepted."

You may also like...

Turn the Ship Around

The Economist Guide to Organisation Design

Org Design for Design Orgs

My Books

Designing Autonomous Teams and Services
Patterns, Principles and Practices of Domain-Driven Design
The Strategic Practices of Domain-Driven Design