> ## Content Index > Fetch the complete content index at: https://www.ariet.net/llms.txt > Use this file to discover other available public pages before exploring further. # The smooth organisation - URL: https://www.ariet.net/the-smooth-organisation/ - Published: 2026-07-23T07:52:37.000Z - Updated: 2026-07-23T07:52:37.000Z - Author: Richard Thackeray - Tags: People and Organisation Republished from a LinkedIn article from July 2026 I've been reading Scale by Geoffrey West. It’s a challenge, and half the time I have no idea what he is talking about, but there are moments that trigger thought, and the rest is like listening to Radio 4 at 5 am while driving alone to some distant destination. He introduces a quote from Mandelbrot that caught my attention. Mandelbrot opened 'The Fractal Geometry of Nature' by pointing out that clouds are not spheres and mountains are not cones; “smooth shapes are rare in the wild but extremely important in the ivory tower and the factory”. They dominate mathematics because they are controllable, and manufacturing because they are easy to make, but nature almost never uses them. *Real forms are rough at every scale, and the roughness has structur*e. It got me thinking about how we always rush to describe reality in simple terms and not what it is, usually because leaders want it that way. But does hiding the reality do more harm than good? Look at target operating models, they are nice smooth shapes; clean boxes, defined layers, capabilities that decompose without residue, but the organisation they describe is not smooth. Zoom into any function, and the roughness reappears: the workarounds, side channels, and informal networks doing the often essential work the diagram does not show. This is not a flaw in the model, for example, a sphere is a perfectly good model of the Earth. The trouble starts when the people holding the model forget it is an idealisation and begin treating roughness as error to be removed rather than information about what the organisation does and how it works under real conditions. Leaders have every reason to prefer the smooth version as a smooth model can be presented, costed, governed and delivered against; roughness resists all of it. So, the bias toward pretending the organisation is tidier than it is comes not from naivety but from the machinery of governance and control. Business cases, steering committees and benefit tracking only accept smooth inputs. Complexity is rarely denied outright; it is filtered out upstream by tooling that cannot represent it. In this part of Scale, the author talks of fractal dimension, and the discussion acquires a living body (in simple terms, a fractal dimension measures how rough or complex a shape is). West discusses the human heart and observes that a healthy heart does not beat like a metronome. The intervals between beats vary in a structured, scale-free way, and that variability carries a high fractal dimension, and this “roughness” is reserve and resilience rather than noise; the capacity to respond to a sprint, a shock, a change in posture. When the signal flattens and becomes regular, the loss is among the better predictors of illness and death. Regularity in the human heart looks like health and is often a sign of disease. Organisations make the same trade. Take a rough, multi-scale set of responses to demand and reduce it to a pipeline, and you have lowered the dimension of what the organisation can do. The pipeline is tuned to the expected case; it performs against the demand you modelled and has nothing spare when the demand you did not model arrives. Ashby talked of the principle decades ago. A system needs internal variety to match the variety of the disturbances it meets. Fractal dimension is one way to see how much variety a system carries, and pipelining is a machine for reducing it. The obvious objection is that we are not supposed to meet disturbance; we are supposed to prevent it; certainty of demand, execution and outcome. We can take the objection seriously as it is often right. Some disturbance should be absorbed at the boundary. You standardise the inputs you can control. You do not want scarce internal variety spent on noise you could have excluded at the door, and therefore, a good operating model protects the system. Where the objection fails is in supposing that certainty can be manufactured on the demand side and then relied upon. Ashby's law is not advice about how to build systems; it is a statement about what happens to the variety you refuse to absorb. The variety must be absorbed somewhere, and if the environment produces more variety than the system can meet, the excess does not vanish because a governance forum has declared certainty. It resurfaces as failure, as work pushed onto people below the model's resolution, as the informal roughness that was carrying the load all along. Certainty of demand is frequently just variety moved off the dashboard and onto someone's workload, and to use an AI-ism, it is quietly moved onto that workload (apart from the someone, they know it). The real question is not certainty against variety; it is where you place the buffer, and you are always choosing among three. - reduce incoming variety at the boundary, which is standardisation, and it is valuable. - hold variety as internal reserve, which is the heart rate variability; the slack, the cross-skilling, the optionality that lets you respond - push it downstream and let it land as failure and heroics. The pipeline mindset believes it is doing the first while it is in fact doing the third, because the second is the one that a throughput dashboard reads as waste and cuts. The heart makes the point better than any of this, as it does not achieve stability by beating regularly. It delivers a steady supply of blood under wildly varying demand precisely by being internally variable. I've been reading Scale by Geoffrey West. It’s a challenge, and half the time I have no idea what he is talking about, but there are moments that trigger thought, and the rest is like listening to Radio 4 at 5 am while driving alone to some distant destination. Leaders asking for certainty of outcome are right to want it, but they are reaching for the wrong instrument, because the regular beat feels like control, but it is the loss of it. The heart analogy also keeps the argument authentic, since a heart can fail in the other direction too. Fibrillation is variability without structure, and it is lethal. Health is a specific state; structured variation and neither rigidity nor chaos. Some of what a pipeline strips out is genuine waste and stripping it out is right. The failure is the indiscriminate kind, which cannot tell reserve from waste because on a dashboard both register as variance. Which leaves a question worth considering into any operating model activity. When we streamline a capability, are we removing waste, or are we removing the organisation's heart rate variability? Most programmes cannot answer, because the variability that constitutes resilience is invisible to the instruments used to justify the streamlining. This is where the architect earns their place. A smooth diagram handed over as an answer hides the roughness, but the same diagram offered as a question, “why does the organisation not look like this”, becomes the way of finding what the smoothing would have cost. The value is in knowing what the clean shape leaves out, and in refusing to mistake a flatline for efficiency.