[T]he aim of such systems is ultimately to produce themselves: their own organization and identity is their most important product.-- Gareth Morgan, Images of Organization, p. 236.
In the early 1970s, biologists Humberto Maturana and Francisco Varela coined the term autopoiesis to define the self-maintaining nature of living cells: biological cells produce the components that maintain the structure that creates more components (in this case, more cells). This is in contrast to allopoietic systems, which use components (raw materials such as silicon and plastic) to generate something (mobile phones and computers) which are distinct from the thing that created it (the factory where they are made).
In the mid-1980s, Gareth Morgan applied the concept of autopoiesis to organizational study.
They do so by engaging in circular patterns of interaction whereby change in one element of the system is coupled with changes elsewhere, setting up continuous patterns of interaction that are always self-referential. They are self-referential because a system cannot enter into interactions that are not specified in the pattern of relations that define its organization.-- Ibid, p. 236
A few months ago, I described the organizational pathologies that we see in slow-growth, (mostly) equity funded firms: because it faces no real pressure (no credit rating to support, no competitive threats to revenue) it will suffer from operations bloat. A significant source of that bloat will be a large middle management.
Left unchecked, tech organizations will grow vertically around line activities (software products that support business functions) and horizontally around shared services (testing, infrastructure). They will also establish one or more program management offices to navigate delivery of complex business initiatives across the fractured organizational landscape. For every management expansion, there is an equal and opposite hiring spree. The host business will mirror tech's management structures, creating business product managers opposite technology line managers, and a business PMO responsible for business change management functions opposite the tech PMO responsible for delivery of tech assets. This management sprawl happens for a variety of reasons: people are promoted into management for fear they might quit, IT gets burned by a delivery failure and creates new hierarchy in response, a senior business manager doesn't want to be seen as mapping to a low level of the tech organization, a new boss prefers to delegate rather than get his hands dirty with the details, there is a low level of trust between tech and business and matching staff is how it maintains equilibrium, and so forth.
Middle management is not a value-generative function. Because they are not engineers or analysts, middle managers don't directly contribute to solution development. Instead, they negotiate on behalf of their sphere of responsibility with other middle managers. They create documentation templates, project control forms, release and implementation workflows, and program checklists to create contracts among other managers to secure the time and attention of the people who do contribute to solution development. These contracts implicitly protect every middle manager by sharing responsibility (my work was dependent on somebody else who failed to deliver) and deflecting responsibility (another initiative took priority so we had no choice but to let this other deadline slip). The web of contracts allows middle management to self-perpetuate.
[W]e can describe autopoietic systems as those producing more of their own complexity than the one produced by their environment.-- Carlos Gershenson, Requisite Variety, Autopoiesis, and Self-Organization.
It also serves as the fuel for growth: perpetual negotiation spurs middle management to expand its library of templates, forms, workflows and checklists. That, in turn, adds to the structure, because it requires more middle managers to fill out more program documentation. For example, a few years ago, the logical database storage for a legacy asset was overwhelmed when a new type of transaction was implemented; since then, the infrastructure department requires every new initiative to complete a "long-term storage analysis forecast". But, some initiatives don't generate many transactions at all and will have little impact on storage allocated to any asset. The managers in those initiatives don't have to fill out a "long-term storage analysis forecast", but must still fill out a "storage analysis forecast exemption" form to document why management concluded the forecast document wasn't necessary.
In this way, middle management is autopoietic: based on a flow of documentation, it creates components (middle managers) that maintains the structure (the bloated middle management) that creates new components (more middle managers).
[T]he brain does not process information from an environment, and does not represent the environment in memory. Rather, it establishes and assigns patterns of variation and points of reference as expressions of its own mode of organization. The system thus organizes its environment as part of itself. If one thinks about it, the idea that the brain can make representations of its environment presumes some external point of reference from which it is possible to judge the degree of correspondence between the representation and the reality. This implicitly presumes that the brain must have a capacity to see and understand its world from a point of reference outside itself. Clearly this cannot be so[.]-- Morgan, pages 237-8.
Suppose we want to introduce Agile into an organization because we want delivery to be more efficient and effective, and we want a better relationship between business and technology. One way we think we can do that is by simplifying our management processes and making them more collaborative, and Agile appears to offer us a means of doing that.
If we have a large middle management function, we can't expect that Agile will simplify our requirements, development, release, or change management activities. What we should expect is that Agile will get co-opted by the very structures that it is there to disrupt. A middle manager cannot comprehend Agile as a different means to an end, because the only end a middle manager is pursuing is successful contract negotiation with other middle managers. A release plan becomes a closed-ended project plan, Stories in an iteration become a commitment, tasks per each Story become the coin of negotiation with other managers for their "resources". Adopting Agile - everything from adaptive planning to continuous delivery - requires a level of abstract thinking about why we do the things we do and how they lead to a delivery outcome that will be well beyond that of an incumbent middle management. Any middle manager capable of abstract thinking will have left the organization long ago: survival requires concrete thinking within a very narrow scope of self-referential activity.
When we recognize that identity involves the maintenance of a recurring set of relations, we quickly see that the problem of change hinges on the way systems deal with variations that influence their current mode of operation. Our attention is thus drawn to system processes that try to maintain identity by ignoring or counteracting threatening fluctuations, and to the way variations can lead to the emergence of new modes of organization.-- Ibid, p 239.
For a large middle management, Agile is not a welcome change. If we have business and tech people working together daily rather than having a temporally shifted conversation through documentation, if we have technology generalists rather than specialists, if we capture knowledge in automated tests and ops scripts, we need far less intermediation in the delivery process. This obviates the need for an expansive middle management function.
An autopoietic system is capable of autoimmune responses. Co-opting, described above, is one. Ignoring is another: enough people refusing to change can force management to re-think its commitment to that change. Subverting is a third: creating obstacles and impediments to change to sow uncertainty and doubt on its effectiveness are behaviors intended to reinforce middle management's identity. Autoimmune forces are powerful: a function that exists solely for its own perpetuation - even when not by charter, but as a matter of social contract among its members - will become shrill in its own defense.
The policeman is not here to create disorder. The policeman is here to preserve disorder.-- Richard J. Daley, 48th Mayor of Chicago
What does change look like under these circumstances?
Clearly, it isn't willing acceptance by the incumbents. We can't expect actors in a system to accept change that results in the destruction of that system. As Upton Sinclair famously wrote, "it is difficult to get a man to understand something, when his salary depends upon his not understanding it."
By definition, change of an autopoietic system must be triggered internally, and happen as a result of randomness. Morgan argues that "random variation provides the seed of possibility that allows the emergence and evolution of new system identities." Random changes create the possibility of new relations, which, if they're not absorbed or stifled by other parts of the system, can lead to new identities. Morgan argues that "Human ideas and practices seem to develop in a similar manner, exerting a major transformational effect once they acquire a critical level of support." Nassim Taleb makes the same argument in his book, Fooled by Randomness.
The corporate change leader doesn't have the luxury of time for the forces of randomness to reform an entrenched middle management. There are two policies that can accelerate structural change: disallowing self-referential justification for middle management practices (that is, expanding its scope of reference so that every action must be justified by a delivery outcome, not a middle management negotiation), and aggressive dismantling of the middle management structures themselves. The prior, if not compromised, puts an incumbent invested in the status quo on the defensive and robs it of it's raison d'être. It also helps to identify people in middle management who are reformable and coachable. The latter reduces the need for the prior.
Bad events in organisations are generally the product of bad systems rather than bad people ... [W]e need to go on and ask what it is about modern corporate life that has made such misbehavior not only possible but appear increasingly common.-- John Kay, Organisations advance by asking "what went wrong" rather than "who is to blame
It's hopeful to believe that an incumbent middle management will "see the light" once introduced to a different set of practices, mechanics and tools. But the broader corporate reality tells us otherwise. When we introduce change, we quickly come into direct conflict with a self-referential ecosystem that, despite obvious internal contradictions and shortcomings, has an extraordinarily strong survival instinct. We also discover latent, institutionalized corporate misanthropy directed at users, customers, suppliers and business partners. A change toward Agile, and the value system it represents, is less enabling, and more threatening, than we'd like to think. To be successful as change agents, we have to dismantle the structures, processes and people behind the status quo while simultaneously replacing them with a new normal.
