Software product development has idealized approaches to working firmly planted in mission command, independent teams etc.
However, there is no established vocabulary for when things go wrong.
We are capable of more systematic approaches to responding to complex events, although with normal operations, cause and effect may be difficult to tease out.
Visibility of the shop floor is not visible in the same way as it is in other industries, and even in synchronous, in-person work, all you see is a group of people sitting at computer screens.
The idealised view of independence and small teams is largely mythologised in software development. It is surprisingly fragile when something goes wrong.
There is not yet an accepted vocabulary for addressing incoherence between processes and people.
Designing software development organisations based on the premise of uncertainty would benefit safety in challenging assumptions.
Organisational structure boundaries need to be flexible, ensuring that systematic introspection and adaptation is supported to prosper under exceptional conditions.
The discussion proposes that maximum team sizes should be able to challenge its assumptions under difficult conditions.
Idealistic structures in software development lead to fragility under challenging conditions.