Post #3528708

2026-05-21 07:05 UTC

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

Replies (1)

@trondhjort@hachyderm.io 2026-05-22 07:57

Organisational Dysfunction of the Day The customer we never met Context: Context: The team is building a product. They have a backlog, a product owner, and a roadmap. A user story describes what users need. Personas represent who those users are. Analytics track what people do. Every few months, there is a user research report from the UX team. The team works hard, ships regularly, and hits their sprint goals. They have never spoken directly to a customer, though. The product owner does that, and the UX researcher. But the engineers, the people making hundreds of small decisions every day that shape the product, have not. They are building for an abstraction. A persona on a wall, a ticket in Jira, a data point in a dashboard. OST explains: An open system maintains its health by actively engaging with its environment. For a product team, the primary environment is the people using what they build. The DP1 bureaucracy is a closed system and mediates that relationship through roles: the product owner translates customer needs into requirements, the UX researcher translates behaviour into insights, and the engineer receives the output of both translations. Each translation loses something. The judgment, the context, the friction, the moment when a real person says something that changes how you understand the problem entirely. In DP2, the group owns the whole task, which includes understanding who it is for. Teams with direct customer access make qualitatively different decisions than teams working from second-hand accounts. Not because engineers are better researchers, but because unmediated contact with the environment is not a nice-to-have. For an open system, it is the condition for staying alive. #OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Open ##3528707