Written in a personal capacity; views expressed are my own.
This post was prompted by my Bristol colleague Oliver Johnson‘s excellent 2024 piece, “The Final Cut“, which I came across again after Oliver recently reshared it on LinkedIn in response to a visual explainer on Britain’s electricity grid in The Guardian. It is well worth reading in full.
Oliver starts with the max-flow min-cut theorem, formalised by Lester Ford and Delbert Fulkerson in the 1950s: in a network, the maximum possible flow from one point to another is determined by the capacity of the smallest cut that separates them. The mathematics is elegant, but what makes Oliver’s post particularly interesting is what happens when he applies the intuition beyond the abstract network. Electricity grids, NHS pathways, military logistics, vaccine delivery and organisational management can all be viewed, with appropriate caveats, by asking where the critical constraints actually sit. His practical advice is to “focus on your cuts”.
Increasing capacity elsewhere in a system may achieve remarkably little if another part remains the binding constraint. More generation does not necessarily produce more usable electricity if the transmission capacity is not there. The timing is apt: the recent explainer in The Guardian identifies the B6 boundary between Scotland and England as a key transmission bottleneck, limiting how much excess Scottish wind generation can be carried south. Increasing activity at one stage of a healthcare pathway may simply move the queue somewhere else. What matters is how the components are connected, and where the constraint actually sits.
The min-cut framing caught my attention because it gives a mathematical shape to something I keep returning to in my own work on complex socio-technical systems. The intuition sits inside a much older tradition. Nancy Leveson’s Engineering a Safer World (2012) develops it for software-intensive systems, where failures can arise from interactions rather than simply from broken components; Donella Meadows’ Thinking in Systems (2008), which I read in 2024, is after something broader than a minimum cut in her work on leverage points, but the discipline is the same.
Systems engineering treats the architecture itself as the object of design, and much of its effort goes into the less glamorous business of eliciting requirements across organisational boundaries, defining how parts are allowed to interact, and assuring against failure modes that belong to no single component. The Royal Academy of Engineering’s Creating Systems That Work (2007) sets this out for engineers, emphasising purpose, interfaces and interdependencies over the optimisation of individual components, while its later Engineering Better Care (2017) applies the approach directly to health and social care, which is where Oliver’s NHS example lands. The same thinking has now reached public policy: the Government Office for Science’s systems thinking guidance for civil servants, developed with the Policy Profession and the Academy among others, asks policymakers to understand the wider system before choosing interventions, rather than disaggregating complex problems until the interactions that matter disappear.
David Woods on resilience engineering (2015) adds the distinction that matters most for what follows: robustness is not resilience, because a system also needs the capacity to adapt when pressures move outside the conditions it was designed for. That distinction has a practical edge. A system can look robust component by component while remaining vulnerable through its dependencies, or through apparently minor connections carrying much larger flows than their size suggests. Redundancy, alternative pathways and spare capacity earn their cost precisely there: they change how the system behaves when a particular route becomes constrained.
The interesting constraints in socio-technical systems need not be physical, and are often not technical either.
This is easiest to see when a capability arrives before the conditions for using it, which is close to the pattern I described in “Seven years of AI research“: introducing a more capable technical component does not by itself make the wider system more capable. An organisation procures a model that performs well against its benchmarks. The technical component is not the constraint. The constraint is the assurance process that has to sign the deployment off, the small number of people qualified to review its outputs, the data-sharing agreement that has not been negotiated, or the absence of anyone with the authority to accept the residual risk. Adding capability at the component does nothing for the throughput of the system, because the cut is somewhere else entirely, and it is made of people and permissions rather than bandwidth.
The mathematics makes one consequence unusually clear. If the binding constraint is the review capacity of a professional workforce, a more capable model widens the flow into that constraint without widening the constraint itself. The queue grows, or the scrutiny thins. Either way the system does not improve, and the deterioration is hard to see from the component metrics, because the component is performing exactly as specified. That is the same problem I described in “Which games not to play” from the other direction: automated systems can act faster than the humans who are supposed to retain authority over what they do.
It also suggests where the effort should go, and why it so often does not go there. Capability is procurable. Capacity, assurance and authority have to be built, staffed and maintained, which is slower, less visible and harder to announce. Those are also where a system’s ability to adapt actually lives: coping with conditions nobody designed for depends on having people with the judgement and the authority to respond, which is not a property of any component.
There are obvious limits to pushing a mathematical analogy too far. Real socio-technical systems are dynamic, adaptive and full of feedback, conflicting objectives and human behaviour; their important constraints are rarely as cleanly visible as the edges of a network diagram. Nor is maximising “flow” necessarily the objective of a public system. None of that is a reason to abandon the question, only to ask it carefully.
So the question to ask before any intervention is not what the system could do with a better component, but where it is actually constrained, and whether that constraint is one you have any means of widening. In public systems the answer is very often institutional, and institutional constraints rarely have a procurement route. For the mathematics, Oliver’s post is the place to start.
