Post #3528702

2026-05-29 07:25 UTC

Organisational Dysfunction of the Day Outsourcing the future Context: The organisation wants a new strategy. Leadership does not have the bandwidth, or perhaps the confidence, to lead the process internally. A consulting firm is brought in. They are smart, experienced, and methodologically rigorous. They interview the leadership team, benchmark against competitors, analyse market trends, and run workshops with selected stakeholders. A few months later, a strategy document arrives. It is well-structured and credible. The organisation begins implementing it. Some things work. Others do not land the way the consultants predicted. The people doing the implementation have questions that the document does not answer. The consultants are gone. Two years later, a new consulting firm is brought in to develop the next strategy. OST explains: Strategy is not a document. It is a shared understanding of where a system is, where it needs to go, and why. That understanding cannot be imported from outside because it depends on knowledge that only exists inside the system, distributed across the people who operate it, the relationships they hold, and the environment they transact with daily. A consulting firm can bring analytical frameworks, comparative data, and an external perspective. What they cannot do is replace the participative process through which an organisation develops genuine strategic ownership. The Search Conference exists because Emery understood this. An effective strategy requires the whole system in the room, not a representative sample interviewed by outsiders. A strategy people helped build is one they will adapt when reality diverges from the plan. A strategy handed down, however well-researched, will be executed literally until it fails and then replaced by the next one. The cycle is not a strategy problem. It is a participation problem. #OpenSystemsTheory #SocioTechnical #OrgDesign #strategy

Replies (1)

@trondhjort@hachyderm.io 2026-06-01 07:10

Organisational Dysfunction of the Day The product owner trap Context: The team has a product owner. She sits with the team, attends the standups, writes the user stories, and manages the backlog. She is good at her job, but she is not really making product decisions. She is translating decisions made by a business stakeholder who sits outside the team and controls the budget. The team builds what she tells them to build, being the proxy for the business which tells her to tell them. She does not really have the mandate to decide much. When the team raises a concern about direction, it goes to the PO, who raises it with the business, who considers it and comes back three weeks later with a modified brief. The team is a feature factory. Everyone knows it. Nobody knows what to do about it. OST explains: The product owner role, as conceived in Scrum, places a single person in charge of deciding what the team builds. That person is formally part of the team but functionally a conduit for management, the ordering-supplier divide between business and IT given a new job title. In OST terms, this is pure bureaucracy (DP1): responsibility for goal-setting sits above the work, even if it sits only one step above rather than many. A genuinely self-managing group in DP2 owns its whole task, not just how the work is done, but what work is done and why. That means the team has a genuine relationship with the customer and the business context, not a mediated one through a proxy. Marty Cagan's distinction between feature teams and empowered product teams maps almost exactly onto DP1 and DP2: in the former, the team is handed a solution to build, in the latter, it is given a problem to solve. The difference is not about process or methodology. It is about whether goal-setting lives inside or outside the group. Until that changes, the product owner is not empowering the team; she is the most visible evidence that it is not empowered. #OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Open ##3528701