Organisational Dysfunction of the Day

The collaboration that isn't

Context: Two teams decide to work together. A shared initiative, a joint project, a problem neither can solve alone. There is enthusiasm on both sides, and a genuine excitement about what they might build together. Everyone has a picture in their head of what that looks like and what they want to get out of it, and everyone assumes the others have the same one. Who owns what, and what success looks like for each of them, is left open. Good intentions and regular syncs will be enough. For a while, they are. Then something goes wrong. Credit lands unevenly. Decisions get made by the louder team. One side feels their contribution has been absorbed rather than shared. Trust erodes quietly. The collaboration continues in name but not in spirit.

OST explains: Two teams are two social systems, each with its own purpose, its own design principle, its own internal logic. The shared purpose is assumed rather than agreed upon. There are two clean ways to work across that boundary. A clear transactional relationship: a contract, explicit deliverables, arm's length. Or deliberately create a new, shared system with a common purpose both sides have actually agreed to, a structure for how the collaboration works and is coordinated, and a design principle governing the joint work. What tends to happen instead is neither. The teams proceed as if goodwill substitutes for structure. The result is laissez-faire more often than not. No clear location of responsibility, no purpose anyone has committed to, no shared system. DP1 (bureaucracy) fills the vacuum, as it always does: the team with more power, more visibility, or a stronger brand quietly starts setting the terms. The other finds itself inside someone else's system without ever agreeing to join it. The same dynamic plays out between companies, just with invoices adding a harder edge to the same underlying confusion. The collaboration was real. The shared system never was.

#OpenSystemsTheory #SocioTechnical #OrgDesign #systemsThinking

Organisational Dysfunction of the Day

People resist change

Context: The transformation programme has stalled. Change management consultants are brought in. Their diagnosis is familiar: the organisation has a change resistance problem. People are comfortable with the status quo, risk-averse, and slow to adopt new ways of working. The solution involves communication campaigns, stakeholder management, and training to help people become more comfortable with uncertainty. Leadership frames the resistance as a cultural issue — the organisation needs to become more adaptive. The change programme continues to stall.

OST explains: A survey of the software industry found that 82.6% of people who had not experienced any organisational change were dissatisfied with the lack of it. They wanted change. What people consistently object to is not change itself but having change imposed on them — a completely different thing. When people are invited to participate in designing the change they need to make, the resistance largely disappears because there is nothing to resist; the change is theirs. OST's methods, i.e. the Search Conference and the Participative Design Workshop, are built entirely on this insight. The change management industry, with its stakeholder maps and communication cascades, often reflects a reluctance to involve people in designing their own work. It is treating the symptom of DP1 with more DP1.

#OpenSystemsTheory #SocioTechnical #OrgDesign #changeManagement

Organisational Dysfunction of the Day

The project in product clothing

Context: The organisation has committed to product thinking, where teams own their domains end-to-end, work iteratively, and adapt based on what they learn. Then a new initiative arrives. It has a defined scope, a delivery date, a budget, and even a steering committee. It is a classic project, but it is run inside the product structure. The product team is asked to deliver specific functionality by a fixed date. The iterative process continues in form — sprints, retros, demos — but the scope is locked, and the deadline is real. When the team discovers mid-way that the problem is more complex than the brief suggested, they do not have the option to redefine it. They have a contract to fulfil. The project ends on time, more or less. The product it leaves behind carries the weight of every decision made under deadline pressure. The team that owns it lives with that weight long after the steering committee has moved on.

OST explains: Projects and products are not different delivery methods; they are different theories of what a problem is. A project assumes the problem is known, the solution is specifiable, and the work is simply execution. It is a closed system: scope goes in, deliverable comes out. A product assumes the problem is partially known at best, the solution emerges through contact with the environment, and the work is continuous learning. It is an open system, transacting with users, the market, and technology throughout its life. Emery and Trist's causal textures framework explains why mixing them fails. Projects are a Type III response; competitive, industrial, bureaucratic, and designed for predictable environments. Product development in a turbulent Type IV environment cannot be governed by Type III instruments without losing exactly the adaptive capacity that product thinking was meant to create. The steering committee, the fixed scope, and the delivery date are not compatible with an open system. They close it because they have to. The project does not just constrain the product. It temporarily turns it into something else and leaves it changed when it departs.


#OpenSystemsTheory #SocioTechnical #OrgDesign #ProductOrientation