Organisational Dysfunction of the Day

The error factory

Context: Something goes wrong. A post-mortem is held, a root cause is identified, and a fix is put in place. A few months later, the same thing goes wrong again, in a slightly different form. The organisation responds with more process, more checklists, more training. The error rate stays stubbornly high. Leadership concludes that people are not following the processes correctly, so more oversight is added. The errors continue. Nobody questions whether the structure itself might be amplifying the mistakes rather than catching them.

OST explains: The research is mathematically precise on this. In a DP1 (bureaucratic) structure, if five people each make sound judgements eight times out of ten, the probability they give you correct unanimous advice is only one in three. The more you control through hierarchy, the deeper you move into error. In a DP2 structure with the same five people and the same fallibility, wrong unanimous advice occurs only three times in ten thousand. In DP1, errors get amplified because asymmetry and competition mean people filter information to serve their own position rather than the truth. In DP2, the same errors become learning opportunities because everyone has shared responsibility, and it is in nobody's interest to hide a mistake. The diagnosis of inadequate training and the prescription of more training will not reliably reduce error rates; that requires attention to the underlying structural cause.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

Fixing people

Context: "No matter how it looks at first, it's always a people problem." Gerald Weinberg's Second Law of Consulting is good advice. It is a reminder that the human dimension is always present, that purely technical diagnoses miss something essential, and that the people involved always matter. Most managers and HR professionals would recognise themselves in it. Someone on the team is struggling. Maybe they are disengaged, not delivering, clashing with colleagues, or just not showing up in the way they used to. The organisation's response is to fix the person: a performance improvement plan, a coaching programme, a personality assessment, or a quiet word from HR. Sometimes it works for a while. But the same problems keep reappearing, often with different people in the same role. The carousel of interventions never quite stops.

OST explains: Weinberg is right that it is always a people problem; people's experience, motivation, and well-being are always at stake. OST does not disagree; it adds the next step. When the same dysfunction shows up repeatedly across different people in the same role, the problem is not those individuals; it is what the system does to whoever occupies that position. DP1 structures (manager-led), with their competition for recognition and dependency on management for decisions, produce exactly the disengagement and avoidance that organisations then try to coach out of people. Fixing the individual while leaving the structure intact contains a deep paradox: elevating the individual as the problem, isolated from the structure shaping their behaviour, goes beyond blaming the victim; it creates them. So yes, it is always a people problem. The question OST asks is: what is the structure doing to the people?

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

Deploying AI into a broken system

Context: The organisation is deploying AI: copilots, automated pipelines, intelligent triage, and decision support. The pilots look promising; the broader rollout is patchy, with some people embracing the tools and others routing around them. A few raise concerns about deskilling, about oversight, about what happens when the AI gets it wrong. Leadership frames this as change resistance. The change management programme is expanded. Meanwhile, the tools are also being used to monitor output, flag underperformance, and justify headcount decisions. The people who were concerned start to understand why they were concerned.

OST explains: This pattern is not new. Sociotechnical systems research emerged in the 1950s precisely because organisations kept introducing new technology with enormous focus on technical capability and almost no attention to the social system. The result was that technology failed to deliver its potential, workers became alienated, and productivity gains were short-lived. The core insight applies directly to AI: you will not get the benefit by optimising the technical system alone. In DP1, the manager-led structure, people are defined by the task they perform. One person, one job, one replaceable part, so when the task can be automated, the person becomes redundant by the organisation's own logic. In DP2, the group owns the whole task, and each person brings judgment, context, and adaptability that no tool replicates; AI becomes an extension of the group's capability rather than a replacement of it. In a DP1 structure, AI is almost inevitably used as a tool of control, monitoring output, flagging underperformance, and surveilling the parts. We are in the middle of the fourth industrial revolution and making exactly the same mistake as the third.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

Built for yesterday

Context: The strategy keeps changing. The market shifted, then shifted again. A competitor emerged from an unexpected direction. AI is rewriting the economics of the industry faster than anyone predicted. The three-year plan written eighteen months ago is already obsolete. Leadership responds with more planning, tighter governance, and faster decision cycles at the top. The organisation is working harder than ever and adapting less than ever. People at the coalface can see what needs to change, but cannot get decisions made quickly enough. By the time something is approved, the situation has moved on. The organisation is not slow because people are lazy or misaligned. It is slow because it was designed for a world that no longer exists.

OST explains: Emery and Trist identified four types of organisational environment, which they called causal textures. The third, disturbed reactive, is the competitive industrial world that DP1, the bureaucratic structure, was designed for, with large, similar organisations whose moves continually disturb one another. The fourth, turbulent fields, is categorically different: the environment itself is in motion, driven by forces in the field itself, like technological disruption, social change, and ecological pressure. In turbulent fields, the variety generated by the environment exceeds the capacity of any hierarchy to process and respond to it. DP1 is actively maladaptive here, because concentrating perception and decision-making at the top creates exactly the bottleneck that makes the organisation slow when speed matters most. DP2, the self-managing-group structure, distributes that capacity across the whole organisation, with every group actively scanning its environment, adapting, and feeding learning back into the system. We have been in turbulent fields for decades. AI has just turned up the intensity several orders of magnitude. To 11.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

The agile terrarium

Context: Agile transformed how software is built. Iterative delivery, short feedback loops, cross-functional teams, and continuous improvement. These were genuine advances over the heavyweight waterfall projects they replaced. The lean movement provided much of the intellectual scaffolding: eliminate waste, optimise flow, respect the people doing the work. And yet, decades on, the research is clear that agile has not delivered the engaged, self-managing, high-performing teams it probably hoped. The process works reasonably well. The organisation around it largely does not. @einarwh described agile teams as terrariums: self-contained ecosystems that look alive and healthy from the inside but are sealed off from the real environment around them. Most people working in agile organisations will recognise that image immediately.

OST explains: The terrarium image is more precise than it might seem. A terrarium is a closed system; it regulates its own internal conditions but does not transact with its environment. That is exactly what agile teams are often designed to be: protected from the turbulence outside, given a stable backlog and told to focus. An open system survives by engaging with its environment, learning from it, and actively adapting to it. Sealing it off does not make the turbulence disappear; it just accumulates outside the glass until something breaks. The agile founders identified "structure" as the problem and removed supervision, but left coordination undefined and control in the hands of individuals. The result was not a move to self-managing groups, what we call DP2, but laissez-faire: an industry lost in the wilderness between DP1, the bureaucratic structure most people work inside, and the self-managing alternative. Research surveying the software industry found 55.7% of respondents were predominantly high laissez-faire, more than either DP1 or DP2. Agile is not failing because the process is wrong. It is failing because a closed system cannot adapt, and the industry has been trying to solve an open systems problem with a delivery methodology.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Since many of you are enjoying a day off, I’m hitting 'pause' on my Dysfunctions series. Instead, I want to address a common objection to OST: the idea that while these principles work in manufacturing, IT is 'too unique' for them to apply.

Here is my take (and the #OST perspective):

The design principles are about where responsibility for coordination and control sits. They are content-agnostic. They apply equally to stitching shoes, nursing, and writing software, because they describe the structural relationship between people and their work, not the work itself.

Knowledge work actually requires DP2 more than routine work does. The whole argument for self-management is variety: when work demands judgment, context, and adaptation, you cannot pre-specify it from above. DP1 is a worse fit for knowledge work than for assembly lines, not a better one.

Big software companies are full of DP1 patterns dressed in agile clothing: product managers who own the goals, engineering managers who own the headcount, architects who own the tech, PMOs who own the process. The product manager role itself is often a DP1 supervisor function relabeled.

My International Workers' Day speech.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

OKRs imposed from above

Context: Many organisations have adopted OKRs, but a common way of doing them is like a cascade: company OKRs are set by leadership, then broken down into department OKRs, then into team OKRs. Everyone has objectives and key results. The teams go through the quarterly ritual of setting them, reviewing them, and scoring themselves at the end. Some teams engage genuinely, while others may treat it as a compliance exercise. A common complaint is that the team-level OKRs are effectively dictated by the level above, with little to no room to define what matters to them. The framework says teams should own their goals, but the structure says otherwise.

OST explains: OKRs are a good idea applied in the wrong structure. In DP2, goal-setting is one of the core functions of the self-managing group; it is not something done to them. When goals are cascaded down from above, even with good intentions, the team is not really setting its own objectives; it is translating management's objectives into local language. That is a DP1 (bureaucratic) function dressed in DP2 clothing. The quarterly scoring ritual then becomes a performance review proxy, which is about the last thing a self-managing team needs. In a genuine DP2 structure, the team's goals emerge from its understanding of its own work, its environment, and the shared organisational purpose it has participated in defining. That is a fundamentally different starting point, and it produces fundamentally different commitment.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

Psychological safety as a patch

Context: Your organisation may have realised that psychological safety is of the essence for good collaboration. Maybe it came out of a retrospective, maybe someone read the Google re:Work study and Amy Edmondson contributions, or maybe it was a leadership initiative after too many people stopped speaking up in meetings. Either way, there are now workshops on it, a section in the onboarding, maybe even a survey to measure it. Leaders are coached to create it. Teams are encouraged to demand it. And yet, somehow, people are still not speaking up, still not taking risks, still not challenging the decisions made above them. The patch does not seem to be holding.

OST explains: Psychological safety is real, and it matters a lot, but what is often missed is that it is an emergent property of the structure people work in, not something you can install. In a DP1 organisation, people are inherently in a dependent, subordinate position, and the rational response to that is to be careful about what you say and to whom. That is not a personal failing; it is Bion's basic assumptions playing out exactly as expected: dependency, fight/flight, and factionalism are the natural human response to autocratic hierarchies. You cannot train people out of that while the structure that causes it remains intact. In a DP2 structure, on the other hand, psychological safety is not a programme or a value on the wall; it is simply what happens when people are peers designing and owning their own work. They speak up because it is their job to, and because there is no hierarchy of dominance to be careful around. Demanding psychological safety in a DP1 organisation is a bit like applying a patch to a system with a structural bug. It might cover the symptom for a while, but the underlying code has not changed.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

Fear of making decisions

Context: One issue many teams in an agile organisation face is the stalemate that frequently happens when they need to make a decision that will impact other teams or other parts of the organisation. They have been empowered and given autonomy to decide for themselves, but they still want to be good players and are afraid to do something that could negatively impact others. Some may even be worried whether the change is allowed at all, like changing their work process or tools to use for things like ticketing, or changing the technical architecture by using a different data storage platform. Good ideas and suggested improvements are often shelved or even abandoned.

OST explains: This is another predictable side effect of a partial DP2 transition to self-managing teams, where the teams are given autonomy to self-manage, but do not feel able to. Or, maybe now they are not really empowered, as they know all too well, there are DP1 (bureaucratic) structures still in place that can and will stop them. And, even if they were in a pure DP2 setup, they still need tools to coordinate. One that works well is referred to as the "advice process" and was first described by Dennis Bakke, later by Laloux and Harmel-Law. In it, anyone can make any decision provided they follow this simple rule: first seek advice from 1) everyone who will be meaningfully affected, and 2) people with expertise in the matter. So instead of drawing up everything and then getting approval from someone who cannot possibly understand it properly, or going rogue, you formulate the decision as best as you can and then seek advice on it and adjust it to your liking based on that. Not only do you make better decisions, but you also own them. No more blame game, which DP1 creates, and no chaos, which the mixed mode induces. Participative democracy in practice.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

The frozen middle

Context: Assuming you are a team member in an organisation that has gone through an agile transformation. Your team have been given more autonomy and is expected to self-organise, make decisions, and deliver value faster. Yet somehow, almost everything still takes forever. Decisions get stuck, information does not flow, and initiatives die quietly without explanation. The teams are doing their part, but something above them seems to absorb all energy and momentum like a sponge. Middle managers are busy, always in meetings, always promising to follow up. But nothing moves. A frequent excuse is Things Take Time.

OST explains: This is one of the most predictable side effects of a partial DP2 transition to self-managing teams. When teams are given more autonomy while the surrounding DP1 structure remains intact, middle management gets caught in the middle. They lose their traditional role of passing work down and status reports up, but gain no new meaningful function. The result is a layer of people who are neither coordinating in the old DP1 way nor participating as peers in a DP2 fashion. They become a dampening layer, unconsciously protecting the existing power structure while appearing to support the change. This is not a people problem; it is a structural one. In a full DP2 organisation, the coordination is managed by the self-managing teams themselves, coordination work between peers, and not through proxies. The frozen middle is not resistant to change; it is simply a DP1 organ that has lost its purpose but not yet been replaced by anything coherent. Until the whole system transitions, it will continue to insulate the top from the bottom and slow everything down. The bottleneck has shifted.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile