Search
57 results for “trondhjort”
-
Dear followers and "fellow kids,"
In hopes of landing an interesting and fulfilling gig next, I just wanted to let you know that I'm ready for new assignments. Preferably helping companies with digital transformations that keep people at the centre. My 25 years of experience in the IT industry have taught me one essential thing: efficiency and quality are achieved only when happy people work closely together, within and across teams in the whole enterprise.
#SocioTechnical #OrgDesign #SystemsThinking
More on LI: https://www.linkedin.com/posts/trondhjort_gruppedynamikk-sosioteknisk-saeokkonferansen-activity-7427627571858681856-rVko -
The summer holiday slumber is a great time for some more rabbit-hole deep dives. 🤓 Like Fred Emery and Eric Trist's conceptualization of a system's environment.
https://www.linkedin.com/posts/trondhjort_the-summer-holiday-slumber-is-a-great-time-activity-7221524987285803008-BPaJ
#OpenSystems -
I blog from time to time and hope people find them useful. Watch this link https://www.linkedin.com/in/trondhjort/recent-activity/posts/ or this space for posts on #socioTechnical, #OpenSystems, #DDDesign, #SOA, #agile, #entArch, #softArch and such. ☺️
-
@trondhjort @kandddinsky you forgot to tag your post with #togaf
-
@trondhjort @newcrafts Great talk. Nobody explains #TOGAF better than you.
-
@trondhjort @marick @newcrafts @kentbeck I'm just wondering if we could use Ward's Federated Wiki for this: possibly writing this book together? #FedWiki #FederatedWiki @k9ox
We have some experience with supporting collective writing of books.
-
Join us for the "Intentional Architecture" workshop with @trondhjort and me in Milan on June 5th and 6th in collaboration with Avanscoperta.
Explore how to create a sensible organization design for self-management and technology optimization.
Get your tickets here ➡️ https://buff.ly/3vMGgsF
-
Hey folks!
Together with @trondhjort, we have a workshop that is focused on on open system thinking, how how it can be applied to set strategic goals and evolve the organisation structure.
We are looking for conferences where we can run the workshop. Do you have any suggestions?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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
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.
-
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.
-
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.
-
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.
-
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?
-
Recording, slides, chat and even meeting minutes from my session at the #STS Roundtable's Making Work Worth Doing Series are available:
"Real World Examples: Designing Workshops Using #OpenSystemsTheory
https://stsroundtable.com/webinars/making-work-worth-doing-real-world-examples-designing-workshops-using-open-systems-theory-23-april-2026/ -
Recording, slides, chat and even meeting minutes from my session at the #STS Roundtable's Making Work Worth Doing Series are available:
"Real World Examples: Designing Workshops Using #OpenSystemsTheory
https://stsroundtable.com/webinars/making-work-worth-doing-real-world-examples-designing-workshops-using-open-systems-theory-23-april-2026/ -
Recording, slides, chat and even meeting minutes from my session at the #STS Roundtable's Making Work Worth Doing Series are available:
"Real World Examples: Designing Workshops Using #OpenSystemsTheory
https://stsroundtable.com/webinars/making-work-worth-doing-real-world-examples-designing-workshops-using-open-systems-theory-23-april-2026/ -
Recording, slides, chat and even meeting minutes from my session at the #STS Roundtable's Making Work Worth Doing Series are available:
"Real World Examples: Designing Workshops Using #OpenSystemsTheory
https://stsroundtable.com/webinars/making-work-worth-doing-real-world-examples-designing-workshops-using-open-systems-theory-23-april-2026/ -
Recording, slides, chat and even meeting minutes from my session at the #STS Roundtable's Making Work Worth Doing Series are available:
"Real World Examples: Designing Workshops Using #OpenSystemsTheory
https://stsroundtable.com/webinars/making-work-worth-doing-real-world-examples-designing-workshops-using-open-systems-theory-23-april-2026/ -
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.
-
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.
-
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.
-
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.
-
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.
-
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.