Do Craig Larman's Laws of Organizational Behavior really mean we always need to start with a structural change? What do they say about starting with Kanban?
Larman Laws say structure drives behavior — but does that mean you must always start with reorganization? The case for starting with Kanban despite the warnings.
I’ve been following Craig Larman’s work for a while now. I find the books he wrote with Bas Vodde on scaling agile to be very insightful and actionable.
I recently discovered Craig’s “Laws of Organizational Behavior”: 1. Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures. 2. As a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo.
3. As a corollary to (1), any change initiative will be derided as “purist”, “theoretical”, and “needing pragmatic customization for local concerns” — which deflects from addressing weaknesses and manager/specialist status quo.
4. Culture follows structure.
And as a practical advice Craig adds: i.e., if you want to really change culture, you have to start with changing structure, because culture does not really change otherwise. and that’s why deep systems of thought such as organizational learning are not very sticky or impactful by themselves, and why systems such as scrum (that have a strong focus on structural change at the start) tend to more quickly impact culture.
i discovered that john seddon also observed this: “Attempting to change an organization’s culture is a folly, it always fails. Peoples’ behavior (the culture) is a product of the system; when you change the system peoples’ behavior changes.” “
Structural change or not?
So do these Laws mean we always need to start with structural change? With a move to Feature teams for example like Scrum prescribes? I find the laws provide an interesting perspective about a typical challenge I see at my big enterprise clients. The structure is definitely providing a glass ceiling to improved performance. Sometimes the performance is at that glass ceiling but in many cases it is way below it.
At this point we have two choices (at least) - one is to do what Craig suggests and start with a structural change. In the cases where the organization is ripe for change that would typically be the right move. In many cases though the understanding of the need for a big change is missing. There is mistrust that the new language/approach/structure of agile/flow/feature teams will work and will address problems the organization cares about.
The Kanban alternative
An alternative is to use an understanding-focused tool such as the Kanban Method to both improve the performance w/ the current structure but also to show its limits/glass ceiling. At some point the organization will have to decide whether the performance gains it got within the current structure is enough and whether it is stable/sticky within the current structure. If not, the leaders will now need to change the structure to break the glass ceiling and enable the next jump in performance.
A pattern in the field
I see this pattern a lot in the field in various sizes of organizations - Kanban used to show the way towards a real structural change towards an Agile structure of real feature teams. It typically drives a healthy leader-led change that eventually sticks.
Improving flow means fewer bottlenecks, faster feedback, and less wasted capacity. Explore flow advisory or let’s talk.
Practical thinking on turning AI pilots, adoption, and portfolio work into business impact - by finding the constraint, changing the work, and proving value as you go.
Yuval Yeret helps product and tech leaders move from agile theater to evidence-informed delivery. Work with Yuval →
