← Portfolio · ← Collaboration 2.0
1.3 · Disclaimers
Where the reasoning in 1.1 rests on intuition rather than on proof, and what that costs.
1.3.1 · Reductionism
When I grouped the symptoms I was not applying a method. I was following an intuition, and it is fairer to the reader if I say what that intuition was looking for.
A group felt right when the symptoms inside it talked to each other far more than they talked to anything outside it; when I could trace at least one loop that stayed within the group, so that the group was a mechanism rather than a list of complaints; when the connections leaving it were few enough to name one by one; and when I could not picture fixing two of my groups with the same single action. Anyone who works with graphs will notice that this is close to what community detection is after, and the resemblance is real — but I got there by staring at the drawing, not by running anything on it.
The ideal is literally unachievable. We know that from our engineering background and experience. But when it comes to systems that include people and the relations between them, things get far riskier and trickier. I prefer to explain the difference like this: with an engineering problem we usually have a fair sense of how much a reduction costs us in model error. And because the objective variable can be measured, we can judge the state of the variables accurately.
If you are modelling a robotic arm and you decide to ignore friction and energy loss in the bearings and joints, the equations still give you a good sense of how that reduction affects the accuracy of your model. Speed, force, tension, temperature — these are all variables you can measure accurately and tune the model against. Now think of the opposite case. Suppose we want to judge a teamwork workshop built on gamification. How would you measure the level of skill someone learns? Let us assume they all improve from 0 to 1. The next question is what motivates them to use the skill they learnt. And how should we think about human motivation at all? It seems to have many aspects — so should we formulate it as a vector? Or as a single variable that is conditionally dependent on many other factors? We could go on asking questions like this for a thousand paragraphs and still not reach a consensus.
I can say with near certainty that no matter how much you redesign the architecture, the relations and the symptoms, it is impossible to arrive at a graph whose nodes decouple into disconnected clusters. The reason it is impossible is itself the finding. Connections run in both directions between all three of my groups, which means the mutual-reachability set is larger than any one of them — it is close to the entire graph. The division did not have three problems that happened to interact. It had one circuit with three faces. Contracting it properly would yield a single node and tell me nothing.
So clustering does not break the loop. Clustering makes the loop small enough to think about. Eighteen symptoms and thirty-two connections is an object you can only stare at. Three groups and a handful of crossings between them is an object you can hold in your head, argue about, and eventually design against. That is a real gain, and it is a different gain from the one I was tempted to claim.
1.3.2 · This is one taxonomy, not the taxonomy
The grouping I came up with in 1.1.5 · Clustering is a choice, and a reader is entitled to know that other defensible choices were available. At least three would have produced a different map:
- By mechanism. Group the symptoms by the kind of failure they are — information failures, incentive failures, capability failures. This would have placed “lack of transparency,” “no channel for communication” and “unclear macro-level goals” together, since all three are failures of information reaching where it is needed. It is arguably a sharper cut than mine, and it points at an intervention more directly.
- By organisational level. Individual, team, leadership. This groups by who would have to change, which is useful if the question is how to sequence a rollout.
- By time constant. Fast-moving symptoms (schedule slips, integration friction) against slow-moving ones (norms, reputation, accumulated grievance). This one is genuinely underrated, because fast and slow variables respond to completely different interventions and mixing them in a single cluster hides that.
I chose entanglement over these because of what I needed the map to do. A mechanism-based grouping tells you what kind of thing is broken; an entanglement-based grouping tells you where the breakages hold one another in place, and it is the second that identifies the routes. The cost is real and should be stated: my clustering separates symptoms that are plainly the same species of failure — “lack of transparency” sits in culture while “unclear macro-level goals” sits in strategy — because they are held in place by different neighbours. A reader whose interest is remediation by type will find that grouping perverse, and they are not wrong to.
The taxonomy is also falsifiable, which is the more important claim. It is wrong if a symptom’s behaviour tracks a group other than the one I placed it in — if, for example, transparency improves whenever the strategy cluster improves and is indifferent to changes in the culture cluster. That is a check anyone with access to the division could run, and I would want it run.
⟵ Up: Collaboration 2.0 · Previous: 1.2 · Clues — where the regress terminates · Next: 2.1 · A new lens — the organization as a complex system →