David James Olney
19 October, 2026
Do you work in a massive organisation, or run a tiny business? Do you know how the work gets done, or do you spend half your day trying to satisfy an opaque system that treats you like a bug to be squashed?
The scale varies, but the experience is familiar. We depend on arrangements of people, processes, technology, habits and expectations that are supposed to work together. Just as we learn our way around them, pressure from outside or ambition from within demands that they change.
I have worked through corporate restructuring, institutional mergers, the ponderous adaptation to relentless change, technological transformation, and a corporate separation that made The War of the Roses look like a conflict resolution workshop. I also left academia before the merger that created Adelaide University came into operation in 2026. One reason was that I had no desire to spend the next chapter of my working life navigating its aftermath.
Across those experiences, the difficulty was rarely a lack of people who cared. More often, leaders stretched a familiar system without fully understanding how its parts depended on one another, or what people would need to keep doing good work during the transition. The consequences appeared in the gaps between the boxes on the organisational chart.
When change goes well, someone has usually looked into those gaps. I call such a person a system builder. They can see how the work fits together, imagine a better arrangement, and help people get from one to the other without pretending that the journey will organise itself. In any workplace, that combination feels rare.
Russell Ackoff helps explain why. In his 1978 book, The Art of Problem Solving, he uses puzzles to show how an assumption we have imposed can keep us from seeing a solution. A practical problem presents choices with consequences, but first we have to understand what the problem really is. His wider work calls an interdependent collection of problems a mess. Fix one part in isolation, and you may make the whole thing worse. Sometimes the most useful move is to change the conditions producing the problem, rather than optimise a single response to it.
Consider a business that answers customer enquiries too slowly. Hiring another person might help. But if enquiries arrive through three channels, no one owns the handover, and the promised response time rewards speed over resolution, a new employee inherits the mess. A system builder asks what customers experience, where work waits, who has the authority to act, and what a change in one place will do somewhere else.
That kind of thinking is only half the job. The other half is understanding how much change people can carry. Bryan Weiner’s work on organisational readiness argues that a group needs both a reason to value a change and confidence that it can deliver it. That confidence depends, in part, on the demands of the work and the resources available. A stirring announcement cannot create hours in a day that do not exist.
Nor can a beautifully drawn process map tell a manager what people are afraid to say aloud. Amy Edmondson’s research on teams connects psychological safety with learning behaviour: people need to be able to ask questions, report errors and challenge assumptions. When the people doing the work cannot safely say, ‘This will break’, the plan loses one of its most useful sources of intelligence.
A system builder therefore works in a family business as readily as in an engineering programme, though the tools and scale differ. It might be the person who notices that an ageing owner alone knows how orders are handled, and helps the next generation learn the whole sequence before the owner retires. In a military planning team, it might be someone who revisits the definition of the problem as conditions change. NASA’s systems engineering guidance makes this responsibility explicit for large projects: users, operators, maintainers, interfaces, training and the whole life of a system have to be considered together. The role is defined by what the person attends to, not their job title.
This also explains why a builder needs maintainers. These are the people who keep the machines running and the lights on. They know which apparently redundant step prevents a failure every Friday afternoon. Their caution can be inconvenient to an impatient reformer, but a system that cannot operate reliably while it changes may never reach its promised future.
James March described a continuing organisational tension between exploiting what we already know and exploring what might work next. Maintenance is valuable because yesterday’s knowledge is often hard won. It becomes insufficient when changing demands expose the limits of yesterday’s arrangement. Builders need to protect what works, learn what no longer does, and give maintainers the time and authority to help redesign it.
Then there are system users: most of us, much of the time. We want to get on with the job and do it well. When a new process obstructs that work, we may revert to an old habit or invent a workaround. That response is sometimes called resistance, but it can also be evidence about the system. In a study of electronic prescribing in five English hospitals, researchers found that workarounds could create safety risks while also revealing problems with usability, access to equipment and the fit between a tool and professional practice. The sensible response is to investigate what the workaround is telling us.
There is a human limit here too. A study of nurses during major organisational change found high levels of change fatigue. We should be careful about generalising from hospitals to every workplace, but the question travels well: how much adaptation are we asking people to undertake while they still perform their ordinary work? If the answer is more than they can reasonably carry, repeating yesterday is a predictable response, not a character flaw.
At the opposite extreme are system utopians. They can see a future with remarkable clarity and have remarkably little interest in the route to it. A Communist central planner and a neoliberal zealot may want radically different destinations, yet each can make the same mistake: assume that removing the existing arrangement will somehow bring a coherent new one into being.
James C. Scott’s account of failed grand schemes in Seeing Like a State is a warning about this habit. Large plans can miss the local knowledge that lets people make a place or institution work. His cases are mainly about state power and the consequences can be catastrophic; an office restructure is not the Great Leap Forward. The transferable lesson is humbler and more useful: an elegant diagram is not evidence that the people living with it can make it function.
Of course, these are ways of behaving, not four permanent kinds of person. A careful maintainer may become a builder when given the chance; a builder can become a utopian when too confident in a favourite design; a user may know more about a broken handover than anyone in the executive team. The question is whether the organisation can bring that knowledge together before it acts.
So, if you are contemplating change, look for the person who asks where the effects will land, including on people who are absent from the meeting. Give them access to the users and maintainers, enough time to map the dependencies, and permission to test an idea before imposing it everywhere. Ask what must keep working during the transition, what resources the new arrangement requires, and what evidence would persuade you to change course.
You cannot remove every surprise from a complex system. You can make yourself better at noticing one early, learning from it, and adjusting without breaking the people who have to carry on. That is what system builders do. Are you one of them? More importantly, are you creating the conditions in which one can help you?
Thank you for reading to the end. If you got value from this, please share it with your network and sign up below for updates. It really helps, and it makes me smile.
Sources and further reading
Russell L. Ackoff, The Art of Problem Solving: Accompanied by Ackoff’s Fables (1978)
Russell L. Ackoff, “The Art and Science of Mess Management” (1981)
Bryan J. Weiner, “A theory of organizational readiness for change” (2009)
Amy Edmondson, “Psychological Safety and Learning Behavior in Work Teams” (1999)
NASA, Systems Engineering Handbook: System Design Processes
James G. March, “Exploration and Exploitation in Organizational Learning” (1991)
Cresswell and colleagues, “Workarounds to hospital electronic prescribing systems” (2017)
“Change fatigue: The frontline nursing experience of large-scale organisational change” (2019)