Book Notes #001: Agile IT Organization Design by Sriram Narayan

Title: Agile IT Organization Design: For Digital Transformation and Continuous Delivery
Author: Sriram Narayan
Year: 2015
Pages: 304

What if your company’s biggest blocker to agility isn’t its tools or talent—but the way it’s designed to work?

That’s the eye-opening premise behind Agile IT Organization Design by Sriram Narayan. This isn’t another book about Agile rituals or frameworks.

It’s about how to rewire the very structure of your IT organization—so that agility isn’t just something you “do,” but something you are.

With practical stories, fresh insights, and a no-nonsense tone, this book challenges a lot of what we assume about IT, projects, teams, and even budgets. It’s a refreshingly human and deeply useful read for anyone navigating digital transformation or leading modern tech teams.

As a result, I gave this book a rating of 8.0/10.

For me, a book with a note 10 is one I consider reading again every year. Among the books I rank with 10, for example, are How to Win Friends and Influence People and Factfulness.

3 Reasons to Read Agile IT Organization Design

Book Overview

What if the real reason your digital transformation isn’t working has nothing to do with your technology—and everything to do with how your teams are structured?

That’s the quiet but radical claim at the heart of Agile IT Organization Design by Sriram Narayan.

This isn’t a book about how to do Agile ceremonies better.

It doesn’t walk you through sprints or Kanban boards. Instead, it zooms out to ask a much bigger question: how should your entire IT organization be designed if you actually want agility to work?

The answer starts with one key insight—software development isn’t a production process; it’s a design process. That might sound academic, but it changes everything. In manufacturing, predictability is king.

But when you’re building digital products or transforming legacy systems, the terrain is uncertain. You’re experimenting, learning, and iterating.

If your organization is built to prioritize predictability, it’s probably crushing the very responsiveness you need most.

Narayan challenges the traditional project-based model, where temporary teams are spun up to deliver fixed-scope initiatives, then disbanded once the job is done.

This, he argues, is one of the main reasons digital efforts stall. Knowledge gets lost, responsibility is fragmented, and teams never stay together long enough to actually improve.

His alternative? Long-lived, cross-functional capability teams that are responsible not just for delivering a product, but for running it, evolving it, and learning from its users.

That shift—from activity-oriented structures to outcome-oriented ones—is the foundation for everything else in the book. It’s what allows autonomy to flourish without chaos, because everyone knows what they’re accountable for.

But autonomy, Narayan warns, isn’t enough. It has to be balanced with alignment. Teams can’t just run in different directions.

They need a shared sense of purpose, clear strategic guidance, and visibility into how their work fits into the bigger picture.

Some of the most refreshing parts of the book come when it steps outside the usual Agile conversations. Narayan talks about things like budgeting models, HR practices, office layout, and even microaggressions in communication—all through the lens of agility.

For example, he critiques how traditional finance systems, with their obsession over CapEx vs. OpEx, actually force organizations to separate development from operations—completely undermining DevOps in the process.

His solution? Tag user stories as CapEx or OpEx at the team level, ditch the timesheets, and let teams stay whole.

Staffing gets a similar rethink. Instead of hiring by role—tester, developer, analyst—he argues for staffing by skill.

Agile teams, he explains, thrive when people are T-shaped: deep in one skill, broad in others. Job titles, siloed tools, and old-school hierarchies all get in the way. Even office design gets a makeover.

Rather than endless cubicles or noisy open plans, he recommends flexible, team-based layouts with the right balance of visibility and privacy.

And when it comes to remote work? He’s not dogmatic—just practical. Sometimes it helps, sometimes it hurts, and the key is to stay intentional.

What makes this book stand out is how grounded it feels. There’s no hype, no buzzwords, and no silver bullets.

Just real talk from someone who’s been inside enough messy organizations to know what slows them down.

He uses vivid examples—a failed healthcare website launch, a testing team hoarding bugs for bonuses, a company debating remote work policy online—to show how culture, structure, and systems interact in surprising ways.

By the time you reach the final chapter, it’s clear this isn’t just about IT anymore. It’s about how organizations can be reimagined to support trust, purpose, and adaptability—whether you’re building software or shaping strategy. Narayan doesn’t promise transformation will be easy.

But he makes a compelling case that it’s not Agile that’s failing us—it’s the way we’ve wrapped Agile inside outdated organizational thinking.

If your teams are stuck in coordination hell, if your Agile feels like theater, or if your digital transformation is dragging despite all the right tools, this book might just have the perspective shift you’ve been missing.

Not a manual, but a mirror. And maybe that’s exactly what we need.

Chapter by Chapter

Chapter 1 – Context

This opening chapter lays the foundation for the entire book. Sriram Narayan starts by pointing out that while Agile practices have spread widely in the software development world, scaling Agile across the entire IT organization—and aligning it with business goals—is still a major challenge.

He argues that achieving true agility isn’t just about faster delivery or better engineering practices.

What’s really needed is organizational agility: the internal ability to adapt, collaborate, and respond to change across departments and functions. This kind of agility supports not only IT but also the business as a whole.

One of the key distinctions introduced here is between IT-B (Build and operate) and IT-I (Infrastructure and operations).

The book focuses on IT-B—teams responsible for building and running internal systems, product platforms, and digital services. Narayan explains that in most large organizations, IT still sits apart from the business, and despite the rise of DevOps and the dream of embedding IT in business teams, structural and cultural differences make that hard to achieve.

He also discusses shadow IT, where business units bypass central IT by adopting their own SaaS tools and cloud platforms.

Rather than treating this trend purely as a problem, Narayan sees it as a signal that business-IT collaboration needs to improve.

What makes this chapter especially interesting is how it connects digital transformation efforts with the idea of organizational agility.

The author emphasizes that creating a mobile app or launching digital marketing isn’t enough. True digital transformation involves rethinking the entire customer journey—and that demands cross-functional collaboration, shared goals, and adaptive structures.

He also critiques the popular bimodal IT model (slow-and-safe vs. fast-and-agile) by Gartner and Kotter’s dual operating system, explaining that this book is about making the “high-speed” IT organization real.

The chapter ends by previewing the structure of the book, which will explore organization design from different angles—structural, cultural, operational, political, and physical—to help leaders build truly Agile IT organizations.

Chapter 2 – The Agile Credo

This chapter dives into what Agile truly means—and why it’s much more than just a development methodology.

The author starts by reminding us of the Agile Manifesto, pointing out that only one of its value statements even mentions software.

In fact, the ideas in the manifesto—like valuing individuals and interactions, working solutions, customer collaboration, and responsiveness—apply well beyond development teams.

That’s why, if an organization’s structure and culture clash with Agile principles, it will struggle to achieve IT agility.

In other words, Agile isn’t just something for developers; it needs to influence how the entire IT organization is designed and operates.

Agile values in action

To make these values more concrete, the chapter gives simple examples. One shows how a developer and tester collaborating in real time to fix a bug—without logging it in a system—demonstrates Agile thinking: favoring working software and real human interaction over formal processes.

Another example explains how product feedback during regular demos allows scope changes to be welcomed rather than resisted, reflecting the principle of customer collaboration over rigid contracts.

These aren’t just process tweaks—they’re cultural shifts. Agile, as described here, is a mindset that shows up in how people work together, how they solve problems, and how they make decisions across IT.

Continuous delivery, DevOps, and culture

The chapter then explores how Agile principles must extend to the delivery pipeline. Continuous delivery ensures software is always in a release-ready state. But it’s DevOps that makes this realistic, by blending development and operations into shared responsibilities. Instead of separate teams pushing their own priorities, they collaborate from the start.

This shift relies on culture—something the author emphasizes through the CAMS model: culture, automation, measurement, and sharing. It’s not about perks or relaxed dress codes; it’s about how work really gets done and how people treat one another.

Foundational Agile concepts

Several foundational ideas are also introduced, like fail-fast, short feedback loops, and the distinction between iterative and incremental development. Iterative means learning and adjusting as you go, while incremental alone can become just a smaller waterfall. Another important point is value stream optimization—focusing on the whole flow from idea to value, rather than optimizing isolated parts.

And there’s a big nod to information radiators, like Kanban boards and burnup charts, that make key insights visible and spark conversations. They’re not just for teams—they can support organization-wide alignment too.

The danger of fake Agile

Finally, the author addresses a growing problem: companies claiming to “do Agile” while violating its spirit. Common anti-patterns include fragmented teams working in silos or product owners who are barely involved.

These setups may follow Agile rituals, but without the mindset, they miss the point. Agile isn’t about being flexible for the sake of convenience; it’s about disciplined collaboration, transparency, and continuous improvement.

And if organizations forget that, they risk dismissing Agile before they’ve ever really tried it.

Chapter 3 – Key Themes

This chapter lays out the three big ideas that shape the rest of the book. Think of them as guiding principles for designing an Agile IT organization. The first is to govern for value over predictability.

The second is to organize for responsiveness over cost-efficiency. And the third is to design for intrinsic motivation. These themes come up again and again, and everything the author recommends later ties back to them.

Governing for value over predictability

One of the boldest arguments here is that software development is not a production process—it’s a design process. This flips a lot of traditional thinking on its head. We’re used to treating software projects like manufacturing lines, expecting fixed timelines and predictable outputs. But the author makes a strong case that this approach just doesn’t work.

Source code isn’t the product—it’s the design. The actual product is what users experience in real time. So trying to manage software like a factory process leads us to chase predictability where it doesn’t belong. Instead, we should focus on value: solving real problems in useful ways, even if we can’t lock everything down upfront. That means adapting plans, embracing learning, and measuring success based on outcomes, not adherence to schedules.

Organizing for responsiveness over cost-efficiency

The second theme challenges another big assumption: that we should always optimize for efficiency. The author argues that in IT-B (build and operate), the bigger priority should be responsiveness. Customers care more about how fast and well you respond than about how lean your internal processes are.

A great example is Zappos, which chose to run its warehouse 24/7—not because it was cheaper, but because it wowed customers. Similarly, IT teams may need to sacrifice some delivery throughput to be more responsive to user needs. Fragmented capacity and multitasking aren’t ideal for efficiency, but they might be necessary for agility. In the world of digital transformation, responsiveness often wins the game.

Designing for intrinsic motivation

The third theme brings it back to people. Agile organizations rely heavily on collaboration—not just the scheduled kind, but the spontaneous, unscripted kind that happens when people care and take initiative. That only happens when people are intrinsically motivated. Drawing from Dan Pink’s work, the author highlights three drivers of intrinsic motivation: autonomy, mastery, and purpose. He argues that organization design must support these drivers.

Teams need enough autonomy to make decisions. They need opportunities to get better at what they do. And they need to feel connected to a larger purpose. Without this, collaboration becomes forced, and agility remains surface-level. The chapters ahead will explore how to build structures and cultures that truly support these values.

Chapter 4 – Superstructure

This chapter takes a big-picture look at how organizations are structured—and how those structures either help or hurt agility. The key idea is that teams should be built around business outcomes, not just activities. That’s a subtle but powerful distinction. An outcome is something independently valuable, like increasing product sales or improving customer satisfaction.

Activities, on the other hand, are just pieces of work that support outcomes—like writing marketing content or testing software. When teams are organized around activities, they often lose sight of the bigger picture. But when teams are responsible for outcomes, they tend to work with more autonomy, motivation, and purpose.

Why outcomes matter

The author shows that breaking down outcomes into sub-outcomes is fine, as long as they remain independently valuable and achievable. This is similar to how we split features into user stories in Agile. There’s even a test for this—TVIN: testable, valuable, independent, and negotiable. Teams that pass this test can be trusted with more autonomy because their success actually contributes to the business.

The book emphasizes that giving a team ownership of an outcome also gives them purpose, which feeds intrinsic motivation.

On the flip side, when teams are built around narrow activities—like a testing team or a content team—they become siloed, focused only on their own work, not on the broader impact.

Autonomy and decentralization

The chapter then digs into the balance between centralization and decentralization. It’s not about picking one and sticking with it forever. As Jim Highsmith puts it, this is a “resolution,” not a solution—it evolves over time. Early-stage products may benefit from decentralized autonomy, but as they mature, some functions might need centralization to scale or create consistency.

The main idea is that decentralization should follow business outcomes, not functions.

So it’s better to decentralize by product lines or regions, rather than by departments like sales or marketing. That helps avoid silos—the dreaded structures where teams guard their turf and don’t collaborate well.

Understanding silos

Silos, in this book, are described as the result of autonomy gone wrong. They show up when teams are so focused on their own success that they block collaboration, slow things down, and miss the bigger business goal. Silos can be functional (like sales vs. marketing), regional, or product-based.

But the worst ones are inside IT—when development, testing, QA, and operations all live in separate worlds. These silos increase handoffs, reduce speed, and make teams defensive instead of collaborative.

The author explains that not all silos are equally bad—some at higher levels can be tolerated temporarily—but the focus should be on eliminating the ones that block first-order success: delivering actual business value.

Outcome ownership and structure

One important practice the chapter introduces is having a clear outcome owner—someone who is fully responsible for the result and can make decisions quickly. This isn’t a new title but a role someone takes on, like a product manager or project lead.

The outcome owner prevents internal gridlock and helps the team stay aligned. Finally, the chapter cautions against trying to design for large-scale synergies (like cross-product integration) before you’ve even achieved basic product success. First, make sure individual product lines or teams are thriving. Then, and only then, tackle the higher-order coordination.

Chapter 5 – Team Design

This is the first deep dive of the book, and it really sets the tone for how organizations should rethink their team structures if they want to deliver software quickly and effectively.

The chapter starts by pointing out a common problem: too many teams are collectively responsible for the same business outcome.

This often happens because of historical structures, regional splits, outsourcing, or specialized functions. But here’s the issue: collaboration within a team is fluid and constant.

Between teams? It’s slow, formal, and full of friction. Continuous delivery needs continuous collaboration—and team design plays a huge role in making that possible.

The problem with activity-oriented teams

The chapter calls out a traditional setup where teams are built around specialized activities—like testing, operations, marketing, or UX—rather than business outcomes. These activity-oriented teams create lots of handoffs. Each handoff introduces delay, forces larger batch sizes, and makes the overall cycle time painfully long.

For example, if testers sit apart from developers, they won’t take new builds continuously. Instead, they wait for big drops, which leads to slower feedback and more defects. To be Agile, teams need to shrink batch sizes and work in smaller chunks—but that’s only possible if handoffs are cheap and quick, which doesn’t happen with functionally split teams.

Why cross-functional teams work better

Cross-functional teams solve this by putting all the necessary skills for delivering an outcome into one group. The author goes beyond the typical dev-tester mix and includes roles like product owners, operations, support, and even sales and marketing when needed. This setup cuts delays, increases autonomy, and lets teams respond to change faster.

Real-life examples like Spotify’s squads and Apple’s product teams show how this works in practice. These teams are aligned around clear missions and include the necessary capabilities to act fast. They’re also more fun and motivating to work in—because people see the impact of their work.

The hidden costs of shared services and silos

The chapter also critiques shared services—teams like centralized testing or support that serve multiple products. They may seem efficient on paper, but they often lack purpose and slow down progress. Because they’re not responsible for any one outcome, their interactions feel transactional, not collaborative. The same goes for separate maintenance teams, which the book describes as a relic from the past. Today, with DevOps and continuous delivery, the same team should build, run, and improve a product. Splitting that responsibility just creates unnecessary handoffs and delays.

Killing the matrix

Finally, the author takes aim at the matrix organization—a setup where team members report to both a functional lead (like a head of development) and a project manager.

In IT, this creates a “function within a function” mess that slows everything down. It leads to competing priorities, unclear ownership, and long cycle times.

The recommendation is clear: dissolve the matrix and move toward fully accountable, outcome-oriented teams. If a team gets too big, it’s better to split by sub-outcome (like product modules) than by function. That way, you maintain focus and autonomy.

In short, this chapter argues that responsiveness matters more than cost-efficiency. Cross-functional teams, organized around outcomes, are the best way to make that happen. It’s not about eliminating specialization—but about designing teams where specialization serves agility, not silos.

Chapter 6 – Accountability

If the last chapters felt like a celebration of autonomy, this one reminds us that autonomy without accountability is a recipe for chaos. Accountability is what balances the freedom to act with the responsibility to make smart decisions. Without it, we risk power struggles, decision delays, and endless meetings with no clear ownership.

The author opens by pointing out a truth many organizations avoid: power still exists. Influence is nice in theory, but in practice, people with formal authority tend to make the calls. That’s why organizations need to acknowledge power, not pretend it doesn’t exist—and then design systems to use it wisely.

Power, hierarchy, and clarity

Narayan isn’t against hierarchy. He actually argues that some is necessary to avoid dysfunction. But it needs to be designed with care. Too much hierarchy leads to silos and politics; too little leads to confusion and hidden power games.

One example he uses is the idea of power vacuums—when no one is clearly in charge, decisions get stuck or made behind closed doors. The answer isn’t to remove hierarchy, but to clarify authority and accountability, so people know who’s responsible for what, and who can make which decisions.

Delegation and alignment

A big point here is that autonomy isn’t just about giving people space. It’s also about giving them the authority to act—and being clear on when a boss can step in.

The book outlines different delegation styles and shows how, in Agile cultures, a delegating style works best: the subordinate has decision rights, but the manager can override if needed. This style supports responsiveness and autonomy while keeping alignment with business goals.

Assigning clear outcome owners

The chapter brings in a powerful real-world example: the failed launch of HealthCare.gov. One of the biggest issues? No one knew who was ultimately responsible.

That’s the danger of shared ownership with no clear accountability. To fix this, Narayan introduces the idea of outcome owners—a single person, full-time, with both authority and responsibility for a business outcome. Without this, you get finger-pointing, blame games, and stalled progress.

Accountability mapping and decision clarity

One practical tool the author introduces is accountability mapping. Imagine a visual map showing who owns which outcomes. It’s a way to expose and fix overlapping or missing ownership.

Without this kind of clarity, you get what he calls “collective disowning of accountability.” People attend endless meetings and CC everyone on emails just to stay in the loop—not because they know what they’re responsible for. A clear accountability map helps cut through the noise and avoid unnecessary escalation.

Avoiding power struggles with structure

Narayan critiques both matrix organizations and absolute hierarchies. The first creates territorial power struggles, where functional leads guard resources and clash with outcome owners. The second gives all power to outcome owners, which can demotivate function leads. His proposed alternative is the professor-entrepreneur model.

In this setup, outcome owners (entrepreneurs) have authority and are accountable for results, while function leads (professors) guide their specialties but don’t control people or budgets. This way, you get influence without power struggles—and everyone stays focused on outcomes.

Decision records and transparency

To avoid HiPPO (highest-paid person’s opinion) decision-making and prevent mistakes from being buried, the chapter suggests using decision records.

This idea, borrowed from software engineering, creates a transparent log of decisions, inputs, and rationale. It helps avoid finger-pointing and promotes learning from mistakes. Narayan even suggests tools like Loomio to support this process. Importantly, this isn’t about turning every decision into a democratic vote—it’s about inviting input while keeping accountability clear.

Planning vs. execution—and why overlap matters

A major problem in many organizations is the separation of planning and execution. Managers plan; others execute. This not only kills autonomy and credibility, but also leads to poor decisions.

Narayan argues that planners should stay hands-on, at least 20% of the time. Whether it’s testing, coding, or working with customers, staying connected to execution keeps leaders grounded. It earns respect and improves decision-making. Planners who lose touch risk making decisions that don’t reflect reality—and then blaming executors when things go wrong.

Org chart debt and the need for rethinking structure

The chapter ends with a smart analogy: just as software teams must repay technical debt, organizations need to repay org chart debt—the misalignments, silos, and power imbalances that build up over time.

This means periodically revisiting roles, responsibilities, and structures to make sure they still serve the goal of agility. It’s not about constant reorgs, but about intentional redesign when things drift off course.

Chapter 7 – Alignment

After making a strong case for giving teams autonomy, this chapter answers an important question: how do we keep everything aligned? Autonomy without alignment can lead to silos and confusion, so this chapter offers practical ways to make sure IT and business stay connected, even as teams gain more independence.

The message is clear—alignment doesn’t require tight control. It requires clarity, shared understanding, and constant communication.

Clarifying strategy through day-to-day tradeoffs

Strategy, the author says, is only useful if it helps guide real-world decisions. Saying “design for high availability” is vague—but saying “favor availability over consistency” offers a clear tradeoff. This kind of guidance helps teams make decisions that align with company goals.

The book introduces the idea of value disciplines—operational excellence, product leadership, and customer intimacy. A company needs to pick one and use it to inform priorities.

For example, a team focused on product leadership will value responsiveness more than cost-efficiency. A practical example is Koparati Inc., which runs both services and product businesses.

Their services team is aligned to customer intimacy, while the product team focuses on innovation and product leadership. Recognizing this difference helps orient employees toward the right decisions and behaviors.

Bridging the IT-business gap

The author points out a real problem: in many companies, IT tries to align with business, but business strategy itself is either not well-articulated or not shared clearly. Sometimes it’s not written down at all. In other cases, IT assumes it co-owns the strategy, funding initiatives the business doesn’t support. This disconnect leads to wasted resources and poor collaboration.

The book emphasizes that business leaders must clearly articulate and share the strategy before expecting alignment from IT. Without this foundation, alignment is impossible.

Tools for alignment

To make alignment visible and actionable, the book introduces several frameworks. One is the MIT Operating Model, which helps organizations understand whether their business units require high integration, high standardization, both, or neither.

Another is Gartner’s pace-layered application strategy, which classifies IT systems into systems of record, differentiation, and innovation. These layers help teams decide where to invest, how fast to move, and what level of control is appropriate.

A more hands-on tool is the alignment map. It connects business imperatives to areas of architecture and technical stories. It’s a visual tool that teams can use to show how their current work contributes to business goals. For example, one team might be working on auto-deploying to test environments to improve cycle time.

Another might be extracting a customer database to support product unbundling. Seeing this mapped out helps both IT and business stay on the same page.

Structural and mutual alignment

The chapter also emphasizes structural alignment—organizing IT-B teams around business units, like customer acquisition or claims management. This structure helps IT teams stay close to business goals, rather than being treated as a resource pool assigned to projects at random. But alignment is a two-way street. Business leaders also need to align with IT’s way of working. If they want Agile results, they need to engage in the Agile process. That means making time for collaboration and embracing iterative development.

The role of the IT Business Partner

To bridge these gaps, the book recommends creating a formal role: the IT Business Partner. This person doesn’t just translate business needs to IT—they also help business understand IT’s methods, priorities, and constraints.

They make sure both sides speak the same language and stay aligned. It’s a high-level role that’s different from a traditional business analyst. It’s about building the relationship between business and IT so both can succeed together.

Chapter 8 – Projects

This chapter is one of the most important shifts in the book. It challenges the entire traditional approach of managing IT work through projects, and instead makes a strong case for moving toward value-driven execution organized around long-lived capabilities.

If you’ve ever been stuck in a project that delivered late, burned everyone out, and had to be handed off awkwardly to another team, this chapter explains exactly why that keeps happening—and what to do about it.

Why traditional projects don’t work

The author starts by explaining what’s wrong with plan-driven projects. The standard definition—something with fixed scope, fixed timeline, and a temporary team—is deeply rooted in the idea of predictability. But software development, he reminds us, is a design process, not a production process.

So trying to plan everything up front rarely works. Instead of asking, “When will it be done?” we should be asking, “What valuable outcomes can we deliver by this date?” The focus should be on solving problems, not ticking off a predefined checklist.

The pressure to deliver “on time and on budget” often pushes teams to prioritize predictability over value—which makes no sense when predictability was never realistic in the first place.

From projects to capabilities

A major shift the book proposes is moving from temporary project teams to permanent capability teams. These teams are organized around business capabilities like “order management” or “claims processing,” not just around technologies or phases of work. Capability teams are stable, cross-functional, and responsible for both building and running their systems.

They don’t disband when a project ends because their mission continues. This stability means they build real understanding of the business they support—something that’s hard to do with rotating project teams. New work just becomes items on the team’s roadmap instead of spinning up a new project every time.

Budgeting for capacity instead of projects

This new model requires a different way of budgeting. Instead of funding individual projects, organizations should fund team capacity based on strategic business needs. This aligns better with how software actually gets built. It avoids the awkward and wasteful situation where a project team gets disbanded, and then a maintenance team struggles to keep things running.

With capacity-based funding, outcome owners decide how to spend the team’s time, and teams stay focused on continuous delivery and improvement. This also makes the budgeting process simpler and more responsive.

The truth about business cases

Another eye-opener in this chapter is the critique of financial business cases. They’re often full of assumptions and inflated benefits, just used to get funding. Real benefits usually aren’t tracked after delivery, and when things go off-track, numbers just get tweaked to make the case look viable again. Instead, the author suggests using continuous delivery and usage analytics to validate benefits as you go. Small, incremental releases let you measure impact and adapt quickly.

When you can actually track whether a new feature improved user behavior or not, you don’t need a 30-page forecast upfront—you just need the freedom to learn and adjust.

Rethinking the role of project managers

In this new model, project managers aren’t eliminated—but they need to evolve. Instead of just tracking plans and managing admin work, they should be helping deliver value. Many traditional PMs are stuck in content-free roles, focusing on charts, checklists, and coordination without understanding the actual product.

The book suggests freeing up their time by introducing project assistants—junior roles that handle logistical tasks—so managers can focus more on real execution and leadership.

Handling change programs and digital transformation

The chapter also critiques large-scale change programs that build separate “transformation units” disconnected from the rest of the organization. These often fail because they bypass existing systems and teams.

The solution? Don’t isolate change—embed it into existing capability teams. That’s especially important in digital transformation, where success depends on deep integration between new and old systems. Organizing by capability, not by channel (like mobile vs. web), avoids fragmentation and supports better customer experiences.

Limiting work in progress

Lastly, the book brings in a simple but powerful concept: limit work in progress (WIP). When too many projects are active at once, progress slows, value delivery drops, and teams get overwhelmed. Instead of starting everything, it’s better to finish fewer, more valuable things. Portfolio-level Kanban boards can help visualize this and keep everyone focused on what really matters.

This chapter isn’t just a critique of traditional projects—it’s a blueprint for how modern IT organizations can finally get off the treadmill of fake predictability and start delivering continuous, meaningful value.

Chapter 9 – Finance

This chapter uncovers one of the quietest yet strongest barriers to Agile IT: traditional finance and budgeting practices. While it might seem odd to discuss accounting in a book about Agile organization design, the author argues that finance has become a hidden bottleneck, just like siloed teams or rigid governance once were. Using the theory of constraints, he shows that once you clear one bottleneck, another appears—and today, budgeting is often where agility breaks down.

The cost center mindset

A big part of the problem comes from how IT is labeled. Most enterprise IT departments are treated as cost centers, not profit centers. That means they’re seen as overhead—something to be minimized.

This mindset leads to a project-based funding model where IT is treated like a job shop, assigned projects with fixed scope, time, and cost.

The issue? Software development isn’t a predictable, repeatable process—it’s a design process, full of learning and iteration. Treating it like manufacturing is a mismatch that hinders collaboration, value delivery, and long-term team health.

CapEx, OpEx, and DevOps complications

Finance also influences how teams are structured through capital (CapEx) and operating (OpEx) expenses. Traditionally, development is CapEx and operations is OpEx. That creates friction when teams try to adopt DevOps, because now one team is doing both and accounting doesn’t know how to categorize the costs. Splitting teams to match accounting categories is common—but it’s the wrong optimization.

The book offers a practical solution: tag stories as asset-creating or operational in Agile tools. This lets companies report CapEx vs. OpEx accurately without timesheets, which nobody likes filling out anyway.

Rethinking conventional budgeting

Conventional budgeting focuses heavily on control—plans are made once a year, deviations are frowned upon, and incentives are tied to staying within plan. But this is the opposite of Agile, where change is expected and welcomed.

The result is a mismatch: IT is told to be Agile but held to rigid financial constraints. Managers are forced to overplan, inflate benefits to secure funding, and rush to spend budgets before year-end—all symptoms of what the author calls “budgeteering.”

Agile and collaborative budgeting

The chapter proposes a shift to Agile budgeting, where outcome owners are given pre-approved funds and autonomy to adjust their plans. This is less about tracking every dollar and more about delivering value. It’s like replacing traffic lights with roundabouts: there’s still structure, but it relies on cooperation and accountability, not rigid rules.

Some companies are already doing this. For example, Svenska Handelsbanken, a 140-year-old Swedish bank, has worked without budgets or central sales targets for decades—giving branch managers high autonomy.

Another example is Enspiral, a collective using collaborative budgeting through a tool called Cobudget. They pool funds, allocate them together, and focus on big-picture goals rather than personal interests. It’s not perfect, but it creates transparency and shared ownership.

Venture funding as a model

Finally, the book introduces the idea of applying venture funding logic to enterprise IT. In this model, portfolio managers act like VCs, releasing funds in stages based on performance. Outcome owners are like entrepreneurs, and capability teams are startups. This allows more experimentation, faster decisions, and the ability to stop or scale work based on value, not plans.

The key message? Agile finance is possible—and necessary. Without it, even the best Agile teams will be stuck in old patterns, blocked by a system designed for control instead of learning. If we want responsiveness, we need to fund it that way.

Chapter 10 – Staffing

This chapter zooms in on a crucial but often overlooked part of Agile transformation: who’s on the team and how they’re staffed. While previous chapters covered finance and governance, this one focuses on the people—their skills, structure, roles, and what keeps them engaged.

The central idea is simple but powerful: long-term agility depends on long-lived, well-composed teams of motivated, multi-skilled people. You can’t deliver great results with teams that keep getting formed and disbanded like project-based temp squads.

The talent crunch and how to handle it

There’s no getting around it: good IT talent is hard to find and even harder to keep. The industry has grown so fast that demand far outpaces supply. While training and outsourcing can help, both have limitations. Training takes time, and outsourcing often leads to teams overloaded with rookies under a few experienced leads—what the author calls “leverage.” It’s risky, especially when the leverage is driven by planning instead of actual team leads.

To ease the pressure, organizations should favor buy over build for non-strategic systems and keep custom development focused on true differentiators. And when building is required, limit the scope and sophistication to what can be realistically delivered with available talent.

Long-lived teams vs. project teams

One of the most important points in the chapter is the shift from project teams to long-lived capability teams. Project teams often disappear right after delivery, leaving behind systems no one fully understands. This leads to unmanageable legacy software. The solution is stable, cross-functional teams that stay with a system long enough to maintain and evolve it. These teams grow together, learn together, and retain critical knowledge. As Tuckman’s group development theory explains, it takes months for teams to really gel—disbanding them just as they hit their stride is wasteful.

These long-lived teams don’t cost more than project teams. In fact, when you plan work based on fixed team capacity, costs stabilize and you avoid the churn and stress of constant ramp-ups and ramp-downs. And even concerns like team boredom or lack of innovation are manageable—with a healthy mix of personalities, some natural turnover, and a roadmap of evolving capabilities, the team stays sharp.

Staffing by skills, not roles

In traditional setups, people are staffed by roles: developer, tester, analyst. But in high-performing Agile teams, that model starts to break down. As team members grow, they often become T-shaped people—strong in one skill, capable in several others. That’s why the book pushes for skill-based staffing instead of role-based.

This allows more flexibility, better collaboration, and stronger responsiveness. People aren’t boxed in by job titles—they shift hats as needed. For this to work well, teams and organizations need to keep an updated skills inventory, showing both primary and secondary strengths.

The same logic applies to job titles. Narrow, specialty-based titles like “QA Engineer” or “Business Analyst” can unintentionally limit how people contribute—or are perceived. Someone labeled as a tester may have great product ideas, but those can get ignored. The author suggests using broad, specialty-agnostic titles or internally focusing on pay grades and skills rather than labels.

Building poly-skilled teams and reducing part-timers

Staffing isn’t just about finding talent—it’s also about growing it internally. One effective practice is pairing, where a scarce specialist works with a less experienced team member. This helps build capability while increasing accountability and responsiveness. It also reduces over-reliance on part-time specialists, who often become bottlenecks due to divided focus and low context.

The chapter also covers team personality mix and gender balance. These may seem soft, but they make a big difference in team cohesion, creativity, and resilience. Using tools like confidential surveys and assessments can help teams understand and appreciate different working styles and strengths.

In short, staffing isn’t just about filling seats. It’s about designing teams for the long haul, nurturing versatility, and removing the barriers that keep people stuck in narrow roles. Agile delivery is only possible with Agile people—and that means building the right environment for them to thrive.

Chapter 11 – Tooling

This chapter brings our attention to something that often flies under the radar in conversations about Agile: tools.

Sriram Narayan argues that while we often blame people or processes for collaboration issues, the tooling and access landscape plays a silent but significant role in shaping how people work together.

Tools aren’t just passive helpers—they influence behaviors, shape habits, and can even cause or prevent silos.

Access control and collaboration

The chapter starts with a challenge to the traditional “need-to-know” access model. Most organizations restrict access to tools and information unless an employee can prove they need it.

But Narayan flips this around: instead of asking “why should this person have access?”, ask “why shouldn’t they?” He calls for a “need-to-restrict” approach—only block access when absolutely necessary (e.g., for compliance), and otherwise let people explore freely.

Tools like wikis embody this mindset. Everyone can read, and often edit, everything. The openness encourages sharing and autonomy while keeping bad behavior in check through traceability and reversibility.

The subtle effects of siloed toolchains

Even in cross-functional teams, silos can form when different roles rely on different tools—what the author calls silos of tool access. For instance, if developers can’t access sales dashboards or monitoring tools, they miss valuable context. Likewise, if product analysts can’t see customer data in Salesforce, they have to rely on intermediaries. This separation slows teams down and weakens insight.

The problem gets worse when tools don’t offer tiered licenses (e.g., read-only access at a lower cost), making it too expensive to grant access broadly. Organizations must start thinking about universal access to information radiators, not just specialized tools.

There’s also a behavioral layer—silos of tool usage. People form emotional attachments to their favorite tools. They become part of a “tool tribe” (like vi vs. Emacs or Windows vs. Mac) and end up defending their tools, even if it creates friction. This may seem like friendly rivalry, but it can divide teams and hinder collaboration.

The same goes for tool specialties—when one team uses one set of tools and another uses a completely different stack, even for similar tasks. Tools that blur boundaries and are shared across roles make collaboration easier and reduce handoffs.

Technology isn’t neutral

Narayan leans on Marshall McLuhan’s idea that “we shape our tools, and thereafter our tools shape us.” Just like language influences how we think, tools influence how we act. And while some believe tools are neutral and it’s the people who misuse them, the book disagrees. Tools have embedded values.

Email, for example, has completely changed how we communicate—it’s become the inbox, the file cabinet, the notice board, and the social feed all in one. It encourages constant checking, scattered attention, and over-documentation. So, when designing an organization’s tooling landscape, we have to ask not just what tools do, but how they shape behavior.

Tool evaluation and adoption

Choosing the right tools isn’t just about feature comparisons. Narayan emphasizes best fit over best tool. A technically superior tool might still fail if it doesn’t fit the team’s way of working or if adoption is too difficult.

Tool evaluations should include end users, consider training needs, and avoid over-customization unless it brings a clear competitive advantage. Importantly, every tooling decision needs a clear outcome owner and a transparent decision record, so there’s accountability—not just for selection, but for adoption and success.

A call for intentional design

The big message here is that tools either support or sabotage collaboration. If we want unscripted, cross-functional teamwork, we must choose tools and access models that enable it.

That means rethinking access control, procurement policies, and tool standardization—not for bureaucracy’s sake, but to create a digital workspace that actually supports the way Agile teams are supposed to work.

Chapter 12 – Metrics

This final chapter tackles a sneaky but powerful blocker to agility: the way we measure things. On the surface, metrics seem like a good thing—they give us data to guide decisions. But Sriram Narayan warns that metrics, if misused, can do more harm than good.

They can create illusions of control, promote the wrong behaviors, and actually reduce performance, especially when tied to targets and incentives. He isn’t anti-metric. He’s just pro-context, pro-conversation, and deeply skeptical of managing software work like it’s a factory line.

Metrics don’t tell the whole story

The core argument is that software development is a design activity, not a production process. This means we’re dealing with constant learning, change, and unpredictability—so no set of metrics can fully capture reality.

We often track what’s easy to measure, not what’s truly meaningful. Take velocity, for example. It can be helpful—but only if the definition of “done” includes everything from functional testing to performance and security. Otherwise, we’re just fooling ourselves. Worse, when teams water down “done” or report progress at the task level instead of story level, velocity becomes a vanity metric.

Dashboards and the illusion of insight

Dashboards are meant to give a high-level view, like an executive summary. But they often promote superficial understanding. A dashboard might show “green” status based on dozens of tracked metrics, while hiding bigger problems not being measured.

This creates a false sense of security. People stop asking hard questions and start trusting the dashboard too much. And because managers don’t want to report “red” or “amber,” teams game the system to keep everything green—even when it’s not the right thing to do.

The trouble with targets and incentives

This part hits hard. When we say, “Do this and you’ll get that,” people chase the reward—not the real goal. Targets distort behavior. Teams optimize for what’s measured, not what matters. One story shows how a testing team refused to share their test cases because their performance was measured by the number of bugs found.

Another example shows a sales rep giving a huge discount just to hit a quarterly target—losing long-term revenue in the process. These are classic local optimizations that hurt the bigger picture. Targets also lead to micromanagement, kill intrinsic motivation, and turn learning organizations into compliance-driven machines.

Gaming and Goodhart’s Law

Narayan brings in Goodhart’s Law: “When a measure becomes a target, it ceases to be a good measure.” People start gaming metrics, intentionally or not. Recruiters flood interviewers with low-quality candidates to hit hiring targets. Operations teams create uptime hacks that fool monitoring tools but frustrate users. Even well-meaning targets become problematic because people shift their energy toward hitting the number, not solving the problem.

Reforming the metrics regime

So what’s the alternative? The book doesn’t just critique—it offers a better way. First, get rid of incentives. Straight salaries work better in Agile cultures. Then, ease targets gradually, moving toward metrics that are discussed—not imposed.

Support human assessments over mechanical reporting. Use RAG indicators (Red, Amber, Green) with high-low watermarks instead of chasing exact numbers. And most importantly, use metrics maps to show how each metric links to a business outcome. This makes metrics purposeful, not random.

Designing better metrics

The chapter closes with a guide for smarter metric design:

• Favor outcome-oriented over activity-oriented metrics.
• Use aggregates like value velocity or code toxicity instead of micromanaging details.
• Prefer adaptability metrics (like cycle time) over fake predictability (like projected completion dates).
• Get comfortable with lagging indicators. If your feedback loop is short, they’ll still be useful.
• Introduce compensating metrics to balance out the blind spots of other metrics.

Finally, the chapter acknowledges objections: “But my team needs carrots and sticks.” Or “This won’t scale.” But Narayan argues that what scales is autonomy with accountability, not control through numbers. Metrics should support meaningful conversations—not replace them.

Chapter 13 – Norms

This chapter marks a shift in the book’s tone. After focusing heavily on structure, processes, and accountability, it now zooms in on organizational culture—specifically the informal, unwritten rules that shape everyday behavior. Narayan argues that while much of culture change is a side effect of leadership, structure, and policies, deliberate reinforcement of a few key norms can significantly support agility. These norms aren’t policies. They’re more like shared beliefs about “how things are done here.” And if chosen wisely and reinforced consistently, they help decentralize decision-making without losing coherence.

What norms do, and how to reinforce them

The chapter starts by explaining what norms are through a relatable story. A new hire at Edgy Inc. is shocked to find she has full admin access to her laptop—total trust, unlike her previous job, which treated employees like risks to be managed. The message is clear: norms can either empower people or cage them. To strengthen useful norms, Narayan suggests storytelling—sharing real examples that reflect the desired culture. For instance, stories of trust, initiative, or smart risk-taking become signals for others to act similarly. He proposes creating internal blogs for each norm, crowdsourcing stories, and letting employees engage with them naturally. Leaders should comment more than post, and incentives should be avoided to keep it authentic.

Cooperation over competition

One powerful norm Narayan encourages is cooperation instead of internal competition. While competition is healthy in the market, inside organizations it often leads to envy, local optimization, and dysfunctional behavior. He gives examples of how rewards like “most innovative employee” or gamified bug hunts can cause people to hoard information or game the system. The better approach? Recognize multiple contributors instead of naming a single winner. Avoid scarcity-based contests and create an environment where people support each other instead of undermining one another.

Living policies and consistency

Narayan introduces the idea of “living policies”—policies that evolve openly with feedback from employees. Instead of being locked in PDFs no one reads, they live on collaborative platforms, open to comments and regularly revised. This encourages transparency, responsiveness, and adaptability. Alongside this, he makes a nuanced point about consistency versus uniformity. True consistency means aligning with intent and context—not enforcing sameness everywhere. He uses the example of UI design or loan policies to show how rigid uniformity can frustrate users or employees, while thoughtful consistency builds trust.

Permission culture and trust

Another standout idea is the norm of “ask for forgiveness, not permission.” It’s about empowering people to act in the interest of the business, without getting stuck waiting for approvals. Yes, this norm can be abused, but when used wisely, it signals trust and invites initiative. Narayan suggests that organizations should not advertise this norm too loudly, but should treat smart, ethical rule-breaking for the greater good as acceptable—even praiseworthy—rather than punishable by default.

Using confidential surveys wisely

The chapter also introduces confidential surveys as a way to balance transparency with psychological safety. They allow teams to gather honest feedback without turning everything into a popularity contest or a battleground of anonymous attacks. It’s a middle ground that supports continuous improvement while avoiding extremes.

Valuing theory-informed practice

Finally, the chapter calls for a shift in mindset: don’t just act—think while acting. Many organizations pride themselves on being “doers” who dismiss theory. But in a fast-changing world, blind action isn’t enough. Narayan argues for embracing theory-informed practice—learning from books, talks, and models while staying grounded in reality. This norm encourages thoughtful experimentation and decision-making rooted in understanding, not just instinct.

In essence, this chapter shows how culture isn’t just a by-product—it can be shaped, one norm and one story at a time. When done well, norms support autonomy, strengthen collaboration, and keep people aligned even in a decentralized system.

Chapter 14 – Communications

This final chapter explores how communication shapes an organization’s culture—and ultimately, its agility. Sriram Narayan argues that beyond all the org charts and roles, it’s the everyday communication habits that reflect (and sometimes sabotage) agility. He takes a hard look at hierarchy, tone, tools, and even metaphors, showing how small behaviors can have a huge impact on collaboration, trust, and decision-making.

Communication culture and motivation

A healthy communication culture boosts intrinsic motivation. If people feel safe, heard, and respected, they’re more likely to be engaged and creative. But when communication is shaped by rigid hierarchies or unspoken protocols (like needing permission to speak to your boss’s boss), collaboration suffers. The chapter calls for purposeful and egalitarian communication—not just open in theory, but actively designed to break down unnecessary formality and foster shared understanding.

Microaggressions and subtle hierarchy

Narayan devotes a large section to microaggressions, both verbal and nonverbal. These are the subtle (and not-so-subtle) ways power is exercised in routine interactions. Think: the boss who always calls, never answers; who expects calendar invites but ignores them; who mocks ideas but won’t tolerate disagreement. These behaviors, though small in isolation, chip away at trust and purpose. The chapter doesn’t excuse them as quirks of “high performers”—instead, it calls them out as corrosive to Agile culture. Addressing these patterns starts with awareness, training (like including them in new hire orientation), and visual tools like pulse charts to reflect a team’s emotional climate.

Two-way communication at scale

Scaling communication beyond small teams is tricky. One-on-one conversations don’t scale, and big meetings often become one-way broadcasts. Narayan critiques typical channels like all-hands, internal blogs, and surveys as too shallow for real engagement. The best option? Online forums—asynchronous, searchable spaces where employees can contribute meaningfully. He offers a great example of how a company handled a controversial policy change (ending work-from-home) by opening up a 10-day discussion, acknowledging feedback, and transparently explaining the final decision. It didn’t make everyone happy, but it did build trust.

Written deliberation for better decisions

One of the boldest suggestions in the chapter is to deliberate in writing. Meetings often favor the fast talkers, the fluent English speakers, or those with more seniority. Written forums level the playing field. They allow time for reflection, reduce emotional reactions, and leave a trail of decisions and arguments. It’s not just about inclusion—it’s about better thinking. Narayan compares it to software: spoken arguments are like deploying to production with no testing. Writing slows things down, yes—but in the best possible way.

Visual aids and the pitch culture

The chapter takes aim at slide decks and visual-first communication, especially when used without narrative context. Slide decks can mislead, oversimplify, and prioritize aesthetics over clarity. Narayan encourages a return to written memos, citing Amazon’s famous six-page narrative format.

He criticizes the rising pitch culture, where slick presentations outweigh substance and decision makers act like investors waiting to be impressed. In Agile organizations, leaders should be listeners, not just gatekeepers. The goal is thoughtful decisions, not theatrical pitches.

Templates and documentation

Finally, the chapter touches on documents and templates. Narayan challenges the belief that standard templates ensure consistency. Instead, they often enforce uniformity and bloat. Agile organizations do better with guidelines and optional checklists, allowing teams to communicate clearly without rigid formatting.

In closing, this chapter is a powerful reminder that how we talk, listen, write, and share is just as important as any Agile framework or team structure. Culture isn’t just what we say in town halls—it’s how we treat each other in hallways, inboxes, and Zoom calls.

Chapter 15 – The Office

In this final chapter, Sriram Narayan brings the focus to a space we all inhabit daily but rarely consider as a strategic tool: the office itself.

While physical layout might seem like a side note in Agile transformation, the author argues that office design directly influences collaboration, autonomy, communication, and even organizational culture.

The goal is to create an environment that supports unscripted, purposeful interaction—without sacrificing privacy, comfort, or focus.

Open-plan layouts and team proximity

Open-plan offices are preferred for fostering face-to-face collaboration. But this doesn’t mean randomly placing big tables across a floor. The layout should align with business outcomes: teams working toward the same goals should sit together, without being split by functions like development or testing.

Movable partitions can be used to reduce distractions and reclaim wall space for information radiators—physical boards, posters, and whiteboards that support visual thinking and shared awareness. Meeting rooms placed centrally help break up the floor naturally while maximizing window access for team workspaces.

Privacy, solitude, and ergonomic needs

Open layouts have downsides too. People need quiet spaces for focused work—writing, thinking, or private calls. That’s why the book recommends offering private rooms for individual use, silent zones, and screen privacy tools. Removing cubicles means losing personal storage, so lockers can be a helpful addition.

Ergonomically, laptops alone aren’t ideal. External monitors, pull-out trays, standing desks, and carpeted floors all contribute to healthier, more functional workspaces.

Criticism of open layouts and balanced perspectives

Narayan doesn’t ignore the growing criticism of open-plan offices. He cites studies and authors like Susan Cain, who argue that such layouts reduce productivity and well-being.

But the author also points out that distractions exist in all settings—social media, emails, and messages are constant. The real solution isn’t about walls, but about designing thoughtfully to balance interaction and focus.

Remote work: between flexibility and face time

The final section explores remote working, presenting a fair take on both pros and cons. Benefits include fewer interruptions, better talent recruitment, and output-based evaluation.

But challenges arise in IT-B contexts, where rapid feedback, iterative learning, and co-creation are critical. Narayan suggests a hybrid approach: allow occasional work-from-home, but encourage at least two days a week when the whole team is in the office.

He also shares practical tips for effective remote work, like using team chat rooms, screen sharing, and VPN access. Interestingly, he shares his own shift in mindset—from opposing remote work to seeing its value once strong relationships are built.

In short, the physical workspace isn’t just a backdrop—it’s a powerful enabler (or barrier) to Agile behaviors. When designed with intention, the office can reflect and reinforce the values of collaboration, equality, and adaptability.

Chapter 16 – Wrap-Up

The final chapter ties everything together and offers both a summary and a reality check. Sriram Narayan revisits the core purpose of the book: helping organizations design for agility, not just adopt Agile methods.

The big idea has been consistent throughout—optimize for value over predictability, responsiveness over cost-efficiency, and intrinsic over extrinsic motivation.

These aren’t just slogans—they’re the guiding themes that shaped the entire conversation about how IT organizations can work better, faster, and more humanely.

Summarizing the problems and solutions

The chapter begins with a table that neatly organizes common organizational problems and how to address them, categorized by the three main themes from Chapter 3. For example, if you’re stuck in plan-driven projects that prioritize predictability, the solution is to move toward value-driven capability teams.

If shared services or permission-based tooling are slowing responsiveness, shift to cross-functional teams and default-to-open access. And when autonomy is being crushed by centralization or targets, you need outcome-oriented teams, living policies, and clear operating norms.

How to adopt the changes

Transformation is hard, and the author doesn’t sugarcoat that. Instead, he offers a realistic guide on what to tackle first. Some changes are easier—like publishing business strategy or clarifying decision rights. Others, like moving to skill-based staffing or eliminating shared services, are more difficult but have high payoff. The idea is to start where you can make a meaningful difference without overwhelming the system.

IT services and Global In-House Centers (GICs)

A big chunk of the wrap-up addresses IT services companies and GICs, acknowledging the special challenges they face. Services firms often operate under tight contracts, rely on utilization metrics, and follow project-centric models—all of which run counter to Agile principles.

The author argues that unless these firms evolve—toward capability teams, better client collaboration, and support for intrinsic motivation—they’ll be left behind. Similarly, GICs are often trapped in outdated models shaped by legacy mindsets, hierarchical cultures, and overly prescriptive processes from CMMI days. Change is possible, but it requires leadership, humility, and a willingness to unlearn.

Beyond IT

Interestingly, the book’s insights aren’t limited to software or tech. Narayan admits that while the book focused on IT, many of its principles—like cross-functional teams, value-driven planning, and purpose-centered work—apply across sectors. He gives examples from healthcare, education, banking, and more, showing that agility is a mindset and a system design challenge, not just a software thing.

A human-centered shift

The closing message is both practical and optimistic. Agile isn’t the only way to build an organization, but it’s a people-first approach, and that’s where the world seems to be headed. Companies that once thrived on internal competition and rigid predictability are beginning to shift—toward collaboration, trust, and flexibility. It’s a long journey, often uncomfortable, but worth it.

And that’s the big takeaway: design your organization around people—not just processes, structures, or metrics—and agility will follow.

4 Key Ideas from Agile IT Organization Design

6 Main Lessons from Agile IT Organization Design

My Book Highlights & Quotes

Digital transformation is a lot more dependent on Agile transformation than is apparent from high altitudes.

Simply doing sprints or iterations doesn’t make it iterative development if feedback is not sought in between or is ignored in deference to a release plan.

Handoffs are mostly a result of specialization. Organization design cannot reduce these handoffs, but it can make them faster and cheaper by making them occur inside a single team.

Tools that blur boundaries between specialists are better than those that reinforce them.

Expensive handoffs encourage large batch sizes to reduce the total number of handoffs.

Lean product discovery techniques (for start-ups and enterprises) help with the first mile. Continuous delivery and DevOps help with the last mile. Agile software development has become mainstream for the miles in between.

How do we go about reinforcement? Here is one way to do it for some organizational norms: Create an internal blog for each norm. Explain the value of the norm in an introductory post from leadership. Use subsequent posts to narrate supporting stories. Employees subscribe to the blog, vote up or like stories, and comment on posts.

Recognize that a permission culture is a risk-averse culture. Embrace (perhaps tacitly) the norm of asking for forgiveness rather than permission. It encourages people to take initiative without being too fearful of breaking rules.

In enterprise IT, a capability team owns all systems relevant to the capability. They may be systems of record, differentiation, or innovation. In the spirit of DevOps, they are built and run by the capability team.

Systems of record (e.g., payroll and HR) are like utilities (electricity, water, etc.). Although they are essential, they need to be cost-efficient. Systems of differentiation (e.g., a commercial SaaS offering) provide competitive advantage. Systems of innovation are built to try new ideas and graduate the ones that perform well to systems of differentiation.

Product lines (or LOBs) need to be individually successful. This is success of the first order. Exploiting cross-product synergies, offering bundles, and achieving cross-product standardization for marketing are examples of higher-order success. Do not organize for higher-order success before first-order success is achieved. Doing so puts the cart before the horse.

Cross-functional teams fold the entire software delivery value stream into a single team, rather than let it span across multiple activity-oriented teams. This reduces the cost of handoffs, allows reduction in batch size, and thereby decreases cycle time (improving responsiveness).

To bridge the divide between planning and execution, overlap them. It is possible to design an organization where planners are required to spend, say, 20% of their time in execution.

The adaptability of a process correlates inversely with the length of its feedback loops. In order to fail-fast (and learn quickly) rather than slowly, we need short feedback loops.

Whole value stream optimization is far more important than optimizing activities that constitute the stream.

Conclusion

Agile IT Organization Design is the kind of book you’ll want to highlight, scribble in, and quietly recommend to your peers when no one else is watching. It’s not flashy, but it’s packed with clarity.

It makes you question the way your organization runs—and gives you a better way forward. Whether you’re a tech leader, a transformation coach, or just someone tired of pretending Agile is working when it’s not, this book might just shift how you see your entire workplace.

And that’s a pretty good reason to read it.

I am incredibly grateful that you have taken the time to read this post.

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support and appreciation tangibly?

Creating these posts takes time, effort, and lots of coffee—but it’s totally worth it!

If you’d like to show some support and help keep me stay energized for the next one, buying me a virtual coffee is a simple (and friendly!) way to do it.

Do you want to get new content in your Email?

Do you want to explore more?

Check my main categories of content below:

• Book Notes
• Career Development
• Essays
• Explaining
• Leadership
• Lean and Agile
• Management
• Personal Development
• Project Management
• Reading Insights
• Technology

Navigate between the many topics covered in this website:

Agile Agile Coaching Agile Transformation Art Artificial Intelligence Blockchain Books Business Business Tales C-Suite Career Coaching Communication Creativity Culture Cybersecurity Decision Making Design DevOps Digital Transformation Economy Emotional Intelligence ESG Feedback Finance Flow Focus Gaming Generative AI Goals GPT Habits Harvard Health History Innovation Kanban Large Language Models Leadership Lean Learning LeSS Machine Learning Magazine Management Marketing McKinsey Mentorship Metaverse Metrics Mindset Minimalism MIT Motivation Negotiation Networking Neuroscience NFT Ownership Paper Parenting Planning PMBOK PMI PMO Politics Portfolio Management Productivity Products Program Management Project Management Readings Remote Work Risk Management Routines Scrum Self-Improvement Self-Management Sleep Social Media Startups Strategy Team Building Technology Time Management Volunteering Web3 Work

Do you want to check previous Book Notes? Check these from the last couple of weeks:

• Book Notes #127: The Laws of Simplicity by John Maeda2025-04-04
• Book Notes #126: Inevitable by Mike Colias2025-03-24
• Book Notes #125: Revenge of the Tipping Point by Malcolm Gladwell2025-03-21
• Book Notes #124: Radical Candor by Kim Scott2024-09-04
• Book Notes #123: The Personal MBA by Josh Kaufman2024-05-09

Support my work by sharing my content with your network using the sharing buttons below.

Want to show your support tangibly? A virtual coffee is a small but nice way to show your appreciation and give me the extra energy to keep crafting valuable content! Pay me a coffee: