#sociotechnical — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #sociotechnical, aggregated by home.social.
-
v1.2 of Organisational Dysfunctions is out today, and it's the final release.
Twenty-two entries and essays that have been out on Mastodon since the last update are now part of the book: "Nobody wants to own this," "The org chart nobody uses," "Innovation theatre," "The talent myth," and more, spread across every chapter. One new objection has been added, along with two new perspectives.
Clocked in at 97 dysfunctions, which is a nice place to end. The material didn't run out, but I think I managed to finish saying what needed to be said.
This is the last planned update.
Get your digital copy at https://www.organisationaldysfunctions.com/ -
Organisational Dysfunction of the Day
The org chart nobody uses
Context: A new hire joins. In the first week, someone shows them the org chart. Departments, reporting lines, clear boxes. A few weeks later, a colleague pulls them aside and explains how things actually work. Which team to ask when something is needed from infrastructure. The person in finance who actually understands the product. The architect who is technically in a different division but is involved in every decision that matters. The Slack channels where the real coordination happens. The org chart is still on the intranet. They have not looked at it since that first week.
OST explains: Most organisations operating on DP1, the bureaucratic structure, are divided by function, with development, operations, finance, and product each sitting in their own department. This makes sense from a resource management perspective. It makes almost no sense for getting actual work done, which routinely requires coordination across every one of those boundaries. So people build a second structure informally, a network of relationships, shortcuts, and workarounds that lets work flow despite the formal design. This is not culture, and it is not initiative. It is what purposeful people do when the structure they are given cannot support the work they are asked to do. The result is three organisations running in parallel: the formal one on the org chart, the informal network of relationships that moves things through the system, and the actual unit of work, the project, the product team, the initiative, where value is created. None of them was designed to fit together. All three generate overhead. In a DP2 structure, the team is defined by what it delivers, so the formal structure and the working structure are the same thing. There is no gap to fill with workarounds. The org chart nobody uses is the cost of designing for function rather than for flow.
#OpenSystemsTheory #SocioTechnical #OrgDesign #networking
***
The series has become a book, available now on Leanpub.
https://www.organisationaldysfunctions.com -
Organisational Dysfunction of the Day
Nobody wants to own this
Context: There is a service that seven teams depend on. It was built three years ago by a team that no longer exists. The code lives in a repository that has eleven different people listed as contributors. When it breaks, everyone notices. When it needs updating, everyone waits. Slack messages go out asking who owns it. The answers are variations of "we use it, but we didn't build it" and "I think that was the old platform team." Someone eventually fixes the immediate problem. Nobody fixes the underlying one. The service is not on anyone's roadmap or in anyone's OKRs. It is not neglected because nobody cares. It is neglected because the structure has no place to put it.
OST explains: DP1 organises work by splitting it into owned pieces, services to teams, components to people, functions to departments. The logic works for things that fit neatly into boxes. It breaks down entirely for things that are shared, the platform everyone uses, the legacy system too expensive to replace, the cross-cutting concern that belongs to the whole organisation rather than any part of it. These things fall into the gaps between the boxes and stay there. Nobody is incentivised to invest in something that appears on nobody's performance review. In a DP2 structure, where a team owns its whole task end-to-end, the boundary location principle requires that the team controls everything it depends on to do its work. Shared dependencies are a structural signal that the boundaries are wrong, that the work has been sliced in a way that leaves essential things ownerless. The abandoned service is not a prioritisation failure. It is a design failure. The organisation drew the lines in the wrong places and then wondered why nothing fills the gaps.
#OpenSystemsTheory #SocioTechnical #OrgDesign #agile
***
The series has become a book, available now on Leanpub.
https://www.organisationaldysfunctions.com -
Organisational Dysfunction of the Day
Nobody wants to own this
Context: There is a service that seven teams depend on. It was built three years ago by a team that no longer exists. The code lives in a repository that has eleven different people listed as contributors. When it breaks, everyone notices. When it needs updating, everyone waits. Slack messages go out asking who owns it. The answers are variations of "we use it, but we didn't build it" and "I think that was the old platform team." Someone eventually fixes the immediate problem. Nobody fixes the underlying one. The service is not on anyone's roadmap or in anyone's OKRs. It is not neglected because nobody cares. It is neglected because the structure has no place to put it.
OST explains: DP1 organises work by splitting it into owned pieces, services to teams, components to people, functions to departments. The logic works for things that fit neatly into boxes. It breaks down entirely for things that are shared, the platform everyone uses, the legacy system too expensive to replace, the cross-cutting concern that belongs to the whole organisation rather than any part of it. These things fall into the gaps between the boxes and stay there. Nobody is incentivised to invest in something that appears on nobody's performance review. In a DP2 structure, where a team owns its whole task end-to-end, the boundary location principle requires that the team controls everything it depends on to do its work. Shared dependencies are a structural signal that the boundaries are wrong, that the work has been sliced in a way that leaves essential things ownerless. The abandoned service is not a prioritisation failure. It is a design failure. The organisation drew the lines in the wrong places and then wondered why nothing fills the gaps.
#OpenSystemsTheory #SocioTechnical #OrgDesign #agile
***
The series has become a book, available now on Leanpub.
https://www.organisationaldysfunctions.com