Organisational Dysfunction of the Day

Passing the buck

Context: Have you experienced situations at work where you and your team want to decide on something of concern to you, and someone points out that you need to check with the grown-ups first? Passing the buck to someone else, for them to make the decision and, with that, take responsibility.

OST explains: The team is not self-managing, which is fine if they know that and act accordingly (in DP1), but in this situation, they act as if they can, but are unable to commit. If they were truly self-managing, this would not have been relevant even, as they would gladly take the responsibility for the decision and its outcome, as it is what needs to be done to reach their goals (in DP2). Instead, they are confused and uncertain, and afraid, which is a clear signal of laissez-faire, of missing a clear organisational structure. For most, this is even worse than DP1, because at least command & control is predictable and structured.

Organisational Dysfunction of the Day

The powerless retrospective

Context: You and your team have decided it's time to do a retrospective prescribed by the Agile methodology you are using. You all see the use of it and contribute with a lot of ideas and concerns about your work. You record them all and have a vote on the most important ones, but soon realise almost all of them are outside of your mandate to change. You note them down and hope the department lead can do something about it, but know that probably nothing will change, and the whole exercise feels like a complete waste.

OST explains: The members of the team come into this believing they are self-managing, at least to a level where they are able to adjust the work to make it better. Even the Agile methodology says so by incorporating the retospective as a recommended element. An essential element in learning is both looking back and improving going forward. The issue here is that the team is not self-managing, in a DP2 structure, as they are not able to change what really matters to them. Most likely, they are in an agile setup where the teams have been given some control, but most still reside in management outside, in the existing bureaucratic DP1 organisation. The retrospective and the learning it ought to provide are mostly ineffective.

#OpenSystemsTheory #SocioTechnical #agile

Organisational Dysfunction of the Day

Passivity in team workshops

Context: Workshops are for many a unique opportunity for people to get together and collaboratively work on a problem or a design of something they care about, be it EventStorming, Retrospectives, Design Sprints and such sessions. In larger groups, involving the whole team or even people from different teams, you frequently see people with more formal power join in, be it a team leader, department head, or even a intervening and controlling facilitator, and that often creates an unfortunate dynamic where the participants feel limited and restricted, so much so that many become inactive and passive, and not contributing in a way a way that they could have. Even though they probably really wanted to.

OST explains: This dynamic is very common in autocratic hierarchies, where power over something, be it people directly or even a certain subject like architecture, creates a dynamic where people often submit themselves to that person simply because of their position in the hierarchy. And not because of their expertise or good arguments. These emotional anxieties, often unconscious, can take different forms, in this case a dependency on the leader, but can also be a fight/flight reaction or subgroups forming. These are referred to as Bion's basic assumptions, "bas", and the only way to get rid of them and replace it with real productive work is not having an appointed leader present. Always go for DP2 in workshops, regardless of how you are organised otherwise.

#OpenSystemsTheory #SocioTechnical #OrgDesign

Organisational Dysfunction of the Day

Forming–storming–norming–performing

Context: When putting together a new team or making big changes to an existing one, many recommend using Tuckman's "forming–storming–norming–performing" model to turn the team into a coherent and well-oiled unit. It begins with Forming (orientation), moves to Storming (conflict), progresses to Norming (cohesion), and ends with Performing (high productivity). Leaders are advised to manage this process closely as progress is not linear; teams may slip back to previous stages if new members join or goals shift. And conflict is regarded as necessary, as the "Storming" phase is essential to growth.

OST explains: Tuckman's model only makes sense in an autocratic bureaucracy, especially those of the Theory X type, and aligns with Taylor's view that people must be managed to perform properly. This is classic DP1 thinking, whereas in the DP2 style, McGregor's Theory Y is the model, which assumes employees are self-motivated, enjoy work, and thrive under trust, empowerment, and autonomy. Grouped into self-managing groups that have designed themselves using Participative Design. No need for either storming or norming; the teams jump right to performing after forming.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

Analysis paralysis

Context: An agile team is working on a rewrite of an existing legacy solution and feels that its success depends on the function parity it must have with the old one. They therefore end up doing a detailed and extensive analysis to account for as much as possible, even tracking down former developers to get details on some of the more obscure parts. And, even more problematic, they have to figure out which business people own which parts and who all their users are. This drags out in time, and although they have started the work, the extensible analysis prevents them from releasing anything. They are stuck.

OST explains: Agile as a concept is pretty much designed to handle these kinds of situations; at least that is what many may think. It focuses on small increments and puts things in front of the users as soon as possible to tighten the feedback loop, so it makes sense. The thing, though, is that this is not product discovery, as it is an existing product with external product owners and users, both internal and external, and the team has no real product ownership of the app apart from the technical bits. They are not a self-managing product team as a DP2 style should be. Only when they have end-to-end ownership of the whole product, not just a part, can they take full responsibility and accountability so that they can manage it as they please.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

Individualism

Context: Often, there is a large disproportion in how much people are celebrated for their achievements and when blame is placed for accountability when something goes wrong. This feels natural in most parts of the world, as we want to take care of the people and make them feel as good as possible so that they'll feel well and stick around. Being human, as we say. Even toward the people who clearly take on the accountability, and are even paid good money to do so, often leading to few or no consequences. We value the individual when celebrations are due, when heroes are praised, but hide them when there is not. Typically, hero cultures are also a power play, as the ones praised become stretch goals for the rest, showing what lengths they have to go to feel respected and truly valued.

OST explains: This focus on the individual is almost anathema in OST, not because the individual is not valued, but it realises that the group is the basic unit of life, be it your family, your friends or your colleagues. It's founded on the belief that people have both the need for autonomy and homonomy; be able to self-govern and fit in with the group. Actually, valuing individuality as an acontextual thing hides a vital paradox, as it inevitably isolates people as the problem because there is nothing else to blame. It even goes beyond blaming the victim; it creates them. By instead focusing on the group, and having it take responsibility and accountability, it can take both the praise AND the blame. The individual is protected in the group, and it can jointly grow and learn from successes and failures. As it takes them to their shared goals.

 #OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

Quiet quitting

Context: During the COVID-19 pandemic, many things were exacerbated in the population, including how people feel about work. A major trend in America was referred to as the Great Resignation, in which many cited the quality of work as a reason for leaving. Another trend that surfaced about the same time was Quiet Quitting, where employees who are fulfilling their job requirements, but not taking initiative, working overtime or volunteering for extra projects or responsibilities. In short, people are not engaged at work, something the Gallup's State of the Global Workplace report confirms, saying that only 20% of are engaged and 16% are actively disengaged. So not only are sick leaves and absenteeism a problem; when people are at work, just a small minority are actually enjoying it.

OST explains: The reason for these dreadful numbers drops right out of OST and all the research it builds on since the 1950s. Given that the extrinsic motivators for work are satisfactory, such as security, work hours, and pay, the defining reasons for people enjoying work are how well their intrinsic motivators are being fulfilled. A minimal set of six psychological job requirements is the basis and they measure how well a job design works, be it the processes, the technology, the organisation, or the colleagues. If people score well on things like ownership, learning on the job, variety, support and respect, meaningfulness, and career path, they will not only enjoy work, be engaged and produce better results; they will also get a better quality of life.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

Team leads

Context: Most teams in modern agile organisations may not formally have a manager in the same sense as before. Many still have someone they report to as an employee, dealing with yearly reviews, career development, and any job issues, but they are not formally involved in the daily work. It should therefore be possible to have leaderless teams, where all members are peers and have the same say in everything. No ranking. Still, many teams end up being appointed a team lead, often because the organisation wants one contact point and one person in charge of the work done. Many in this position try to deal with this dissonance by taking on a coaching type role, seeing themselves as a "servant leader," giving space to the team and protecting them from the outside. Some even try to switch, being directive sometimes, supportive at other times (aka situational leadership). Not only is this a tricky job to have, but it also creates so much confusion in the team about who really decides and is in charge.

OST explains: DP1-type organisations require personal leadership positions, as that is how control, coordination and alignment are managed. Agile tries to counter that for efficiency, having teams take more control of the work, in an attempt to shorten the feedback loop and the learning. This is similar to DP2, with self-organising teams, while adding team leaders is not and is an attempt to adapt them to the existing bureaucratic DP1 model. The problem with this is that DP1 and DP2 fit together like oil and water; they are fundamentally so different that no matter how good the adapters are, they will lead to confusion and operational problems. You can remove the need for this adapter by ditching DP1, having teams everywhere and letting them take responsibility for their own goals and the integration needed to work with other teams. Teams may decide to appoint a leader, though, for their own needs, either permanently or when needed, but it is not a formal position of power. It is a participative democracy through and through.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

The company's strategy is unclear

Context: "What we've got here is failure to communicate." A common quote used to describe a lack of understanding of and commitment to the company's strategy. Top management is frustrated by the lack of alignment, projects and departments not seeing the bigger picture clearly drawn up in the strategy document. At the same time, the people at the coalface constantly report back that they miss a clear and concise direction to follow when making decisions. All attempts to hold town hall meetings, clearly visible pages on their intranet, middle management sharing it frequently in their weekly status meetings, and even motivational phrases posted on the office walls seem to help.

OST explains: There are many explanations for this dynamic, like a strategy not really being a strategy but rather a lofty goal that provides no clear guidance, or poor communication lines between the top and the bottom. Let's focus on something often missed instead. A strategy must make operational sense to people; it should give them a clear, relevant purpose for their work, feel relevant and relatable in a way that inspires and motivates. Cool and fancy wording is not the point, not even how and how often it is communicated, but how engaging it is. The best way is for people to take part in its creation, but that is not feasible in large organisations, so at least it must have agents in all parts of the organisation who do, someone the people trust and can relate to. This is what middle management ought to be doing: making the company strategy relevant and actionable for people.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

Workshops not working

Context: You have probably seen and even experienced being invited to workshops that you may or may not have that much interest in, but still obligated to join, and although it was carefully planned and executed by the facilitator, it still felt forced, unengaging and maybe even like a waste of time. This is an unfortunate situation as workshops are really the place where important and constructive work ought to happen, where people really feel energised and collaborate at the top of their game. Is it the participants that's the issue, or could it be something else?

OST explains: It is rarely the participants who cause this issue, even when workforce engagement has reached rock bottom. Systemic problems like this have different causes, ranging from the larger structural issues of autocratic hierarchies that inhibit collaboration and put people up against each other to simply bad facilitation. Let's focus on the latter now, as that is an easier adjustment to make. Make sure the facilitators are only in charge of managing the process; they should not own the decision to run the workshop, the technique or process to use, or be involved in the content. The reason for this is that the point of a workshop is for people to own the content and the output, and any attempt to lead will result in Bion's basic assumptions: dependency on the facilitator, just doing what they're told; fight/flight, opposing the whole thing or just not participating; or creating factions that do their own thing instead. Suspect many have experienced these, and they can only be avoided by removing the leader and letting the facilitator serve the group, not the other way around. DP2 instead of DP1.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

Communication problems

Context: A common trope in larger organisations is that the root cause of so many problems and dysfunctions is bad communication. That people are not talking to each other and conveying information properly and promptly. Things are taking too long because of all the people that have to be involved and such. People are therefore often seen as the cause of this problem, and a common way of attempting to deal with these problems involves giving people additional communication skills. Something that fuels a huge training industry. Another is to simply limit the communication needed, for example, by setting a cap on team size (often citing Metcalfe's law) or by putting up human adapters/bottlenecks as the team leads mentioned in another post.

OST explains: OST states that these types of communication problems are endemic in DP1 structures and that it has nothing to do with people's ability to communicate. It is not even the primary human property, so why try to fix that first? Many situations can be observed where communication channels exist but are not used at all. What is a determining factor is the organisational structure, having one that is motivated to use the skills and where the number of channels is as few as possible. In DP1, each person is connected with the policy makers through intermediaries, in a non-reciprocal manner, while in DP2, this is reduced to real reciprocal connections between teams that do productive work. Not only is the number of connections fewer, but so is the quality of communication, as all relations are negotiations between peers, far from the asymmetrical relations between the superior and subordinate found in DP1. Think async vs. sync communication; the former is chatty, the latter is not. Also, Metcalfe's does not fit, as people communicate well and efficiently with peers who share the same goals and purpose as themselves.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

HiPPOs and dungeon masters

Context: In bureaucratic organisations, the formal ranking of people is usually well known and clear, where people higher up in the hierarchy have certain mandates over people they manage and/or that reports to them. Anything else would be chaos in that world. Still, there is also a lot of informal power, ranging from age difference and gender to more subtle things like years of experience and size of salary, regardless of formal power. This is problematic when decisions are to be made, as these informal power structures end up trumping data and expertise.

OST Explains: Facilitators especially try to counter these tendencies in workshops, for example, by using different types of techniques. A common one is sometimes called Silent Writing, where people are asked to work on the problem alone first, at the start of the workshop, so that all voices are heard. Sometimes this is taken a step further, as in 11-2-4-all, where the next step is joining a colleague to draw up a joint design, before joining up with another pair to create one they all agree on, and so on, before all get together and decide. This works well to get input from everyone, but does not silence the one with rank, as they will dominate regardless. And potentially lead to failure. In the techniques developed in OST, the focus is instead to create a community from the start of the session, instead of fortifying the differences, as these techniques do focus on the individuals. The Search Conference does this by focusing first on the shared goals and wishes for the future, showing that they all agree on more than they disagree on. And, if they do agree on something, put that to the side immediately and focus on what joins them instead of what separates them. The assumption is that we share the we all share the values that lead to the desirable future.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

Local optimisations

Context: Any work group of people want to improve their way of working if they could, removing unnecessary work, resources or waste, as Lean calls it. Agile gave the teams that ability, at least to a large extent. Some may only be able to adjust technical issues, while others may even be empowered to decide how they want to do work. For example, one team decides they want to move to an event-driven architecture, while another wants to replace Scrum with Kanban. All great local optimisations that they should be able to do, but often are prevented from doing so, as they need to interact with other teams and are not able to get them to adjust. Or management may not let them because of the impact it has. Again, teams are stuck.

OST explains: This issue is not directly related to OST necessarily, but more to the parts-to-whole relation that comes out of systems thinking, which OST clearly is. Local optimisations in a part are perfect if it does not affect anyone else, which is rarely the case as parts are interconnected with other parts, often even through the shared relation they have to the whole. In a purposeful social system, even more so, as not only must the changes physically fit, but they must also align with the shared purpose of the system as a whole. Most organisations deal with this paradox, the interest of the parts vs. the whole, by designing top down, creating guardrails for the parts to operate within, giving them limited freedom. OST, on the other hand, replaces this centralisation of command and control by distributing it to the parts, where they can design their own work as long as they make sure it aligns with the goals of the system as a whole, like business goals and strategic plans, and, just as importantly, coordinate with all the affected parties. This enables local optimisations for the benefit of the whole.

#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

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

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

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 #strategy

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

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 #strategy

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

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

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 #management

Organisational Dysfunction of the Day

DORA, the wrong way round

Context: The DORA metrics have become the gold standard for measuring engineering performance. Deployment frequency, lead time for changes, change failure rate, and time to restore service. The four key metrics. Teams build dashboards around them, set quarterly targets, and run improvement initiatives to move the numbers in the right direction. Some teams genuinely improve, while others find the numbers are stubborn or that improvements one quarter quietly reverse the next. Leadership concludes that the teams need more discipline, better tooling, or another round of training. What gets called cargo culting (for lack of a better term) in the industry, copying the visible practices without the underlying conditions, is exactly this pattern.

OST explains: DORA was designed as a research instrument, not as a target system. The metrics are downstream signals of healthy delivery, not the drivers of it. Healthy delivery is when self-managing teams own the whole product, make decisions without escalation, and have tight feedback loops with the people they serve. Take those structural conditions away, and the numbers regress, no matter how many dashboards you build. Treating DORA as a goal in DP1 (bureaucratic) is exactly the goal displacement Goodhart warned about: the moment a measure becomes a target, it stops being a good measure. In DP2, the self-managing-group structure, the same numbers emerge naturally as side effects of work well done. You do not need to chase them. You need to build the conditions that produce them.

#OpenSystemsTheory #SocioTechnical #OrgDesign #DevOps

Organisational Dysfunction of the Day

Burned by design

Context: People are burning out. Not one or two, but a pattern across the organisation. The response is usually more support: capacity planning, better prioritisation, blocking time for work, reduced meeting loads, encouragement to take time off, and reminders that it is okay to set boundaries. Some people recover. Others leave. New people arrive and, after a while, show the same signs. The organisation is aware that this is not sustainable but frames it as a consequence of a demanding industry or a difficult period. It will get better soon; we just need to pass this hurdle.

OST explains: Burnout is not primarily a capacity or resilience problem; it is a job design problem. The conditions most strongly associated with burnout, like lack of control, unclear demands, and absence of meaningful feedback, are structural features of the bureaucratic DP1; not unfortunate side effects. Many do not burn out immediately; they switch off first. Presenteeism, being physically present but mentally absent, is the earlier stage of the same structural problem, and burnout is what happens when even the switching off stops working. The numbers are striking. The WHO projected that by 2020 depression would be the second leading cause of disability globally. Gallup reports that 20% of employees experience daily loneliness, in a setting where people actively come together to produce something. One documented DP1 to DP2 transition showed a 28% decrease in absenteeism and an 81% increase in engagement in the first year, with no major technical changes. Adding support resources helps individuals cope with a system that is harming them, but does not change the system. The tree was planted in the wrong soil; repotting is not optional.

#OpenSystemsTheory #SocioTechnical #OrgDesign #health

Organisational Dysfunction of the Day

Professional leadership

Context: The organisation has invested heavily in leadership development. There are programmes, frameworks, coaching, 360-degree feedback, and a clear leadership model on the intranet. The managers are well-intentioned, many of them genuinely skilled, and they take their responsibility seriously. However, the teams below them are still not performing as hoped. Engagement is middling, decisions are slow, and the best people keep leaving. Some even because of their manager. Leadership quality is clearly not the bottleneck, so what is? In many industries, supervisors are expected to know the craft they oversee. Not so in most IT organisations, where the manager's job is people and process, not technology. That gap has been growing.

OST explains: The problem is not the leaders; it is the existence of the role itself. DP1 as bureaucracy requires leaders because control and coordination are handled by a layer above the real productive work, be it managers in the line, project managers, product managers, or even architects. You therefore need good ones, and training them makes sense within that logic. But no amount of leadership quality fixes the structural problem that the people doing the work are not in control of it. In DP2, the need for professional leadership largely disappears because coordination and control are handled by the group itself. The resources currently spent on developing leaders should instead be invested in developing the team's self-managing capacity. That is not a small shift; it is a fundamentally different theory of how organisations work. A DNA swap.

#OpenSystemsTheory #SocioTechnical #OrgDesign #leadership

Organisational Dysfunction of the Day

Tyranny of the majority

Context: The workshop is wrapping up. There are too many ideas on the wall, and a decision needs to be made, so dot voting is introduced. Everyone gets three dots and places them on their favourites. The tallied results are clear, and the facilitator announces the winners. Most people seem satisfied. A few do not. Their priorities were lost, their concerns were not addressed, and the vote moved on before the reasoning behind the minority view was ever really heard. They leave with a decision they had no real part in making. In meetings, the same pattern plays out through a show of hands, anonymous polls, or simply the loudest voices drowning out the quieter ones. It feels democratic. It is not.

OST explains: Dot voting and majority voting are representative democracy mechanisms, which really are DP1 in disguise. They produce a winner and, by definition, a loser, and the minority does not just lose the vote; they lose the ability to influence the outcome, making them unlikely to commit to implementing something they actively disagreed with. Fred Emery called the alternative rationalisation of conflict: instead of forcing a resolution through voting, the group stays with the disagreement long enough to understand it. The goal is not the most popular option, but the option nobody has a reasoned objection to. A higher bar that takes longer, but produces genuine shared ownership that majority voting never can. A decision reached that way does not need to be enforced; people carry it forward because they helped make it.

#OpenSystemsTheory #SocioTechnical #OrgDesign #collaboration

Organisational Dysfunction of the Day

Involvement theatre

Context: Some architects, project leads, or managers want to do things properly. They genuinely believe in collaboration and know the teams have valuable knowledge. So they organise workshops, like EventStorming sessions, design sprints, or other types of collaborative design workshops. People are invited, post-its go up, discussions happen, and there is real energy in the room. Then the session ends, the outputs are photographed, the facilitator disappears with the material, and a few weeks later, a design document or architecture proposal lands in the team's inbox. It looks nothing like what people thought they were building together. When questions are raised, the answer is that the workshop inputs were "taken into account." The teams learn quickly that the workshops are not really about designing together. They are about being consulted. Next time, fewer people will engage seriously. The post-its get sparser. The energy in the room is noticeably lower, even hostile.

OST explains: This is one of the most common misapplications of participative techniques in DP1 organisations: design authority is retained above, while the appearance of participation is layered on top to legitimise decisions already made or soon to be made elsewhere. OST explains why it fails on two levels. First, Bion's basic assumptions: the moment a person with authority enters the room, even a well-meaning independent facilitator, people shift into dependency or fight/flight, so the workshop never produces genuine collaborative design, regardless of how it is facilitated. Second, Fred and Merrelyn Emery were explicit that it is only when people design their own work that they develop the motivation, responsibility, and commitment to implement it effectively. A design imposed on a group, even one consulted, will never have the ownership that a design created by the group has. Involvement theatre does not just fail to produce good design; it actively corrodes trust in the collaborative process, making genuine participation harder to achieve each time. As Kurt Lewin warned, people cannot be trained for democracy by autocratic means.

#OpenSystemsTheory #SocioTechnical #OrgDesign #leadership

Organisational Dysfunction of the Day

Team Topologies, the wrong way round

Context: Leadership has read Team Topologies. The insights are compelling: stream-aligned teams owning end-to-end delivery, platform teams reducing cognitive load, enabling teams building capability. A reorganisation is planned. Teams are renamed and restructured. The new topology is announced. People find themselves in stream-aligned teams that still wait for approval from the same architects, report to the same managers, and receive priorities from the same product managers who held the backlog before. The platform team is the old infrastructure team with a new name and a mandate to serve internal customers, though nobody agreed on what that means. The enabling team runs workshops that nobody has time to attend. Six months in, the cognitive load has not decreased. Delivery has not improved. Leadership concludes that the teams need to embrace the new model more fully. Another round of communication is planned, and product coaches are hired en masse to fix people.

OST explains: Team Topologies describes structural patterns that emerge from healthy organisations. Like DORA, it is a map of what good looks like, not a recipe for getting there. The patterns only function as intended when the teams operating them are genuinely self-managing, owning their work, coordinating among themselves, and making decisions without constant escalation. Imposing the topology from above while leaving the underlying design principle unchanged is a bureaucratic (DP1) move applied to a self-managing (DP2) framework. Stream-aligned teams become delivery units with a new name. Platform teams become service departments, and their internal customer model quietly recreates the same dependency it was meant to dissolve. Goodhart's law applies here as much as it does to DORA: the moment the topology becomes a target, it stops being a good topology. The book is right. The reorganisation missed the point.

#OpenSystemsTheory #SocioTechnical #OrgDesign #TeamTopologies

Organisational Dysfunction of the Day

The external verdict

Context: The organisation wants an independent assessment of the codebase. An external firm is brought in, given access to the repositories, and asked to produce a report. Sometimes the teams are interviewed individually beforehand. Sometimes they are not involved at all until the findings land. Either way, the result is a document that describes their work from the outside, written by people who were not there when the decisions were made, did not carry the constraints, and will not be there when the changes need to happen. The teams read the report. Some findings are fair. Others miss the context entirely. A few are simply wrong. The usual response is a mix of defensiveness, resignation, and quiet relief that at least some things were not noticed. Nobody feels ownership of the conclusions. The report goes into a folder. Most of it stays there.

OST explains: Bringing in external experts to evaluate a team's work is a bureaucratic DP1 move, even when done with good intentions. Control and judgement sit outside the group, and the group receives a verdict rather than participating in an enquiry. The knowledge needed to assess a codebase well is distributed across the people who built it. An external reviewer can spot patterns and bring a comparative perspective, but cannot access the reasoning, the tradeoffs, or the organisational pressures that shaped every decision. Individual interviews are better than no involvement, but they reinforce exactly the individualisation that DP1 already produces, and in teams with existing tensions, they can surface conflicts that the interview format has no mechanism to resolve. What works is treating the review as a collective sense-making exercise. The team leads the process, names what it already knows is wrong, and uses external input as one source of perspective rather than as the source of judgment. In DP2 (self-managing teams), the group owns the quality of its own work. That ownership cannot be outsourced. An external consultant can be a useful mirror and a driver for change. They should never be the judge.

#OpenSystemsTheory #SocioTechnical #OrgDesign #review

Organisational Dysfunction of the Day

Working alone together

Context: The pandemic forced a global experiment nobody had planned. Offices emptied overnight, and something unexpected happened. People managed. Many thrived. The commute nobody missed, the open-plan office nobody pined for, the meetings that turned out to work fine as calls. When offices reopened, a significant number of people simply did not want to come back, at least not every day. The debate that followed framed this as a question of productivity, collaboration, or work-life balance. It missed the more uncomfortable signal. When given the choice, a large number of people revealed they prefer to work alone. That is not a statement about remote work. That is a statement about what going to the office actually felt like.

OST explains: In DP1, the bureaucratic structure, work is individualised by design. Tasks are broken into minimal parts, each assigned to one person, with coordination handled above. The office under DP1 is not a place of genuine collaboration; it is a place of proximity without connection. People sit near each other, manage their own tasks, protect their own position, and attend meetings where decisions have usually already been made. The six psychological requirements for productive work include mutual support and respect, and continual learning through real feedback from people you work with as peers. DP1 delivers neither. Of course, people prefer to stay home. Home is quieter, the coffee is better, and nobody is watching. In DP2, the group is the unit of work. Coordination, learning, and support all happen in the group, not above it. People in genuine DP2 structures report wanting to be with their colleagues because the group is where the work actually lives. The WFH debate is really a DP1 debate. The office stopped being worth the commute long before the pandemic. The pandemic just made it impossible to pretend otherwise.

#OpenSystemsTheory #SocioTechnical #OrgDesign #teams

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

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

Organisational Dysfunction of the Day

The Sunday email

Context: The organisation has a genuine commitment to work-life balance. It is in the values mentioned in onboarding, and comes up regularly in all-hands meetings. Flexible working is encouraged. Mental health is taken seriously. And then the email arrives. Sunday evening, 21:47, from the director. Not urgent. Just something they wanted to get out of their head. No response expected, of course. Nobody says that, though. By Monday morning, three people have replied. Others noticed and said nothing. Over time, the pattern becomes clear. The people who get ahead are the ones who are always available. The policy says one thing. The calendar says another.

OST explains: In the bureaucratic DP1, the person at the top carries personal responsibility for outcomes they do not fully control. The higher the position, the larger the gap between accountability and agency. That gap produces anxiety, and anxiety produces overwork. Not because leaders are workaholics by nature, but because the structure places an unreasonable individual burden at every level of the hierarchy. The Sunday email is not a character flaw. It is a structural symptom. The deeper problem is that modelled behaviour always outcompetes stated values. People read the environment, not the handbook. What the boss does on Sunday communicates more about what is expected than any well-being policy. In DP2, responsibility is distributed across the group. No single person carries the weight of outcomes alone, so the chronic anxiety that drives performative overwork largely disappears. Work-life balance stops being a value that needs defending and becomes a natural consequence of a structure that does not place impossible individual burdens on anyone. The Sunday email stops because nobody needs to send it.

#OpenSystemsTheory #SocioTechnical #OrgDesign #leadership

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

Empowerment

Context: Leadership has announced that teams are now empowered. There are communications about it, a new set of principles, perhaps even a manifesto. The manager has been rebranded as a coach or a servant leader. Controls have been loosened, warm and friendly communication is encouraged, and people are told they have more autonomy. For a brief moment, there is energy. Then people try to actually use this empowerment, run into the existing approval processes, budget controls, and management expectations, and quietly conclude that nothing has really changed. The word starts to feel like a joke. And then something goes wrong — a missed deadline, a budget overrun, a production incident — and the coach suddenly starts acting a lot more like a manager. The mask slips, and everyone realises it was always there.

OST explains: Research on organisations that have adopted agile and similar approaches identified a specific and common structural form: the trainer, leader, or coach (TLC) model, where controls are loosened and warm communication encouraged, but the design principle has not actually changed. Workers often prefer this form as it can provide greater autonomy, until things go wrong, at which point the legal DP1 bureaucracy structure kicks back into life. This is not bad faith on the part of the manager; it is the structure asserting itself. The design principle was never changed, so in a crisis, it reasserts the only legitimate authority available. Empowerment in OST terms is not a communication style or a management philosophy; it means the team genuinely controls the coordination and the goals of its own work. That is a structural change, not a cultural one. Announcing empowerment without changing the structure does not create DP2; it creates laissez-faire. The confusion of appearing to have freedom while the real constraints remain exactly where they were, waiting for the next thing to go wrong.

#OpenSystemsTheory #SocioTechnical #OrgDesign #leadership