On the Inertia of Organisational Change

Or how "every organisation is perfectly designed to get the results it’s getting" - Craig Larman

Nov 15, 2025

Tell me, what is it you plan to do / with your one wild and precious life? — Mary Oliver

It’s a Saturday so please forgive a small departure into the murky world of organisational change. A frustrating natural law we face is that everything we do as developers is part of a broader organisation, culture and society that will have a far greater impact on how we operate, how we think, and how we can build and innovate (or not) than any coding language, software library or Well Architected Framework.

Understanding the rules of hacking within that law, so that you and your organisation can make the most of your “one wild and precious life”, is the game today. The stakes are too high for us developers to pop our heads in the organisational sand.

The pain of transformation isn’t in the change, but the lack of it

A bank announces an “Agile Transformation.” Squads, tribes, and ceremonies bloom overnight. Six months later, delivery times are unchanged, and morale dips. Why? Because the same middle managers still sign off every release and performance review. The structure stayed; the names changed.

When one experimental product line moved to a cross-functional, end-to-end model—real autonomy—the difference was immediate: faster flow, clearer accountability, higher engagement.

The culture didn’t change first; the structure did.

The Smell of Organisation Transformation

There’s a peculiar smell that wafts through an organisation when someone utters the word “transformation.” Not the sweet burn of change, but the antiseptic scent of PowerPoint and panic.

Suddenly there are consultants with laminated frameworks, “agility champions” sprouting like weeds, and executives preaching empowerment while clutching control charts like rosary beads. You can almost hear the organization whispering to itself: Don’t worry, we’ll survive this too.

Craig Larman didn’t invent that smell, but he did name the rot. His laws of organisational change are less commandments than autopsies—sharp, clinical observations of how good intentions die in the middle layers of management. They describe how the great machinery of hierarchy defends itself against intrusion. Every organ, every bureaucratic sinew, is designed not to evolve, but to persist.

If this sounds cynical, it’s only because maybe I’ve has been around long enough to stop pretending. Every large organisation, when faced with the prospect of true change, responds like an old smoker told to run a marathon: it nods, buys the running shoes, and lights another cigarette.

The first law cuts to the bone: organisations are optimised to protect the status quo of their middle managers and specialists. That’s the real core system—the human middleware of control. You can bring in new frameworks, new technologies, new vocabulary; they’ll all be lovingly wrapped in the same reporting structures, budget approvals, and performance management rituals that ensured nothing actually changes.

The second law follows naturally: any attempt to change must bypass this protective membrane or be absorbed by it. The antibodies of “how we do things here” are formidable. They don’t kill ideas with argument; they drown them in meetings, dilute them in pilots, and measure them to death.

By the time you reach the third and fourth laws—culture follows structure, and therefore if you want to change culture you must first change how people are organised—you begin to see that the supposed cynicism is in fact an act of mercy. You don’t change minds and hope behaviours follow; you change the system and watch people adapt within it, sometimes in surprising ways. Sometimes beneficial, sometimes harmful.

And then there’s the coup de grâce: any change that depends on people thinking differently before acting differently will fail. That’s the death knell of every “mindset shift” workshop ever scheduled. People don’t wake up enlightened. They wake up with deadlines, politics, and fear. If you want them to act differently, build a system that makes the right thing easier—and the old thing impossible.

Larman’s laws remind us that the great sin of transformation is perhaps cowardice—the refusal to admit that what we call “culture” is just the visible residue of power and habits. If you want better collaboration, you dismantle the hierarchy that rewards hoarding. If you want learning, you remove the punishment for mistakes. If you want agility, you must stop worshipping control.

And look to the habits. What happens habitually, what is the habitat and how can it evolve to encourage other habits to emerge. Until then, you’re just rearranging the silverware on the Titanic.

True change begins when the structure that defends the past is dismantled, not when the posters start preaching the future

Larman’s laws expose the gravitational pull of status quo bias in large systems. Organisations are self-protective organisms, finely tuned to resist threats to their internal power distribution.

Transformational slogans rarely alter that physics; only structural redesign can. Because culture follows structure, any change that doesn’t alter reporting lines, funding models, incentives, and authority boundaries is performative.

Some practices to consider

Flatten decision paths. Empower autonomous teams with end-to-end ownership.
Invert the org chart. Support the value creators; make management a service, not a layer of control.
Change funding models. Shift from project budgets to product or capability funding.
Bypass bureaucracy. Create protected “pioneer teams” to model new structures safely.
Reward learning. Promote behaviours that expose risk and experiment, not merely manage it.

Some things to avoid

Cosmetic change. Rebranding “managers” as “coaches” without changing incentives.
Pilot purgatory. Containing experiments so their lessons never threaten the core.
Heroic leaders. Assuming inspiration replaces systemic redesign.
The mindset trap. Training people to believe differently before they can behave differently.

A Software Enchiridion

Discussion about this post

Ready for more?