The structure of a system explains more than the people in it
💎CORE ARGUMENT
Put different people into the same structure and they tend to produce the same results. That is the claim, and it is an empirical one, not a generous one. When a release goes wrong and I ask who did it, I get a name and learn nothing I can use, because the next person in that seat, with the same queue, the same incentives and the same missing information, will do the same thing.
A blameless review is therefore not kindness. It is accuracy. Blame is a poor model of cause. It stops the search at the last hand to touch the thing, which is almost never where the fault was made possible.
The launch gave me the test case. On the night of 11 March the Exceptions Inbox began producing duplicates at 23:40, and auto-triage was rolled back at 02:40. It would have been easy to find the last hand on the code and leave it there. The retro asked something else: what made this easy to ship? The answers were about a load test we had agreed to make gentler, about where testing sat in the flow, about a date treated as fixed. Five changes came out of ninety minutes, and none of them was a person.
The reorganisation in April was the same lesson at a larger scale. People who had been excellent became slow for a month, because the reporting lines and the queues had moved under them. They had not changed.
So my first question is now about shape: who waits for whom, who knows what and when, and what is rewarded.
Where I might be wrong. Sometimes it is a person, and reaching for structure then is its own cowardice: it spares me a hard conversation and calls the avoidance systems thinking.
The claim is also convenient for someone in my seat. A product manager who says it was the structure is never the one at fault. I should be most suspicious of it when it lets me off.
🧱BUILT FROM
🌍WHY IT MATTERS
- In a review I ban the question who for the first half hour.
- When someone underperforms after a change, I look at what the change did to their queue before I look at them.
- I describe problems to Katarina as arrangements, with the names left out, and add names only if the arrangement cannot explain it.
Still open. How long do I give a structural explanation before I accept that it is the person? I have no rule, only a feeling that it is longer than most managers wait and shorter than I would like.
☑️NEXT STEPS
- Open the retro with the timeline, not the cause
- Draw who waits for whom in the merged team
- Write down one case this year where it really was a person
People decide well with what they can see, and the system decides what they can see. Policy resistance and drift to low performance are structural, not moral.
💎 Local efficiency can lower the output of the whole is one structure doing this to good people. 💎 Changing a parameter is the weakest way to change a system says where in the structure to push.
People act reasonably on the information, incentives and constraints in front of them. Those are set by the structure. Replace the person and keep the structure, and the same reasonable response produces the same result.
Structure explains the average and not the exception. Somebody chose to work on the problem that mattered when the structure rewarded something else, and 💎 Important problems are chosen and not assigned is about that person.
A belief I hold with its counter-argument attached, the shape of the March retro, and a carefully worded issue about a reorganisation.