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?

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.” ”

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.

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.

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.