The Only Component That Has a Theory About You

The engineer who thought problems could be solved.

For most of my career as an engineer, I was rewarded for finding the problem. Something wasn't working? Find the failure point. A process was inefficient? Find the bottleneck. Something kept going wrong? Find the root cause, fix the mechanism, move on. It was a seductive way to see the world. Complicated problems could be broken down into smaller ones. Systems had inputs, outputs, constraints and failure modes. Understand how the pieces interact, change the right variable, and, ideally, the system behaves differently. Beautiful.

AI-generated illustration. Munich taxis of this era were the subject of a long-running study of driver behaviour.

Then I came across the Munich taxi data from a german study. In the early 1980s, researchers fitted anti-lock brakes to half a Munich taxi fleet and randomly assigned drivers between the two halves. The brakes worked. Stopping distances improved as expected. Observers riding along found the ABS drivers cornering harder, following closer, holding their lanes less accurately and generating notably more near-misses. Over three years the ABS cabs crashed no less often than the others, and if anything slightly more. Handed a safety margin, the drivers spent it, which is precisely what nobody in the design meeting had budgeted for.

Nothing had failed. The engineering worked exactly as designed. The problem was that the people using the system weren't passive components waiting to be optimised. They understood what had changed, formed a new model of what was possible, and changed their behaviour accordingly. Turns out that's a pretty important distinction: a brake doesn't care why you installed it. People do.

And, to be fair, engineering was right.

Before psychology-me gets too smug about all this, engineer-me deserves a defence. Because engineer-me was right about a whole lot.

Break the complicated thing into parts you can actually examine. Separate the symptom from the cause. Ask what the constraints are before what the solution is. Look for interactions rather than isolated events. Never accept "that's just how it works" as an explanation. And design for the real world, not for the drawing.

That's not a personality type, incidentally. Frank (2006) treats engineering systems thinking as a distinguishable competency, one you can identify, describe and teach, which also means its blind spots are structural rather than personal. Those habits took me from electrical systems into engineering management, WHS, and eventually even coaching, where I was surprised by how often they still held up. If someone keeps struggling with a behaviour, "they lack discipline" is about as useful as blaming a circuit for not having enough motivation. Look at the system producing the behaviour.

The Munich drivers weren't behaving mysteriously either. They're responding to a new margin in the system, and their behaviour makes perfect sense in hindsight. Given the incentives, someone thinking about the system rather than the brakes might even have predicted it.

That's what I want to be careful about. It would be easy to say engineering handles machines and psychology handles people, but that's nonsense. If something keeps going wrong, "people are complicated" isn't an acceptable root-cause analysis. Treating a symptom while leaving the underlying system untouched is still organisational duct tape.

The engineering habits didn't become useless when I moved into the world of people. They became incomplete.

The first crack.

The engineering mindset doesn't stop working here. The problems change shape underneath it. Udwadia (1986) puts it more bluntly than I would: the mindset that solves well-structured problems isn't just inadequate for ill-structured management problems but often counterproductive, which he offers as an explanation for why capable engineers so often struggle in management.

Take WHS. Incident rates climb, and the engineering brain fires immediately. What changed? Equipment, procedure, environment, training, controls? Did the process introduce a new failure mode? Those are the right questions and I'd ask them first every time. But here's the one that took me longer to learn to ask. What do the workers believe the procedure is for?

Because a procedure that people privately think was written to protect the company from liability gets followed differently from an identical procedure they believe was written to protect them. Same document. Same constraints. Same incentives. Different behaviour. And the difference lives nowhere in the conventional engineering analysis, because it isn't a property of the physical system. It's a property of what people think the system is. That's the first real crack. The equipment's still there. The controls still matter. But somewhere inside the system are people holding a theory about it, including a theory about who wrote it and why, and they act on that theory rather than on the version in the document.

When the belief makes itself true.

If people act on their theory of the procedure, then the theory doesn't just sit between the system and the behaviour. It becomes part of what the system produces.

Watch how that plays out. A crew decides the new procedure is liability paperwork rather than safety. So they comply with it, visibly and correctly, in the way you comply with paperwork: sign the sheet, tick the box, get back to work. Compliance data comes back clean. Management sees a well-adopted control. Nobody escalates, because on paper nothing's wrong. Meanwhile the actual work's still being done the way experienced hands have always done it, and the gap between the documented system and the real one quietly widens.

The belief made itself true. The procedure became liability paperwork, because that's what it's treated as, and the measurement system confirmed the result by recording exactly what it's designed to record. This is the part that genuinely broke my model. A pressure vessel doesn't become weaker because the crew doubts it. But a procedure can become theatre because people suspect it already is, and an intervention can fail because it's expected to. The belief isn't a distortion sitting between the system and reality. On a long enough timeline, the belief is one of the forces shaping which system you end up with.

I haven't left systems thinking behind. I've had to widen what counts as part of the system. The equipment, the procedures and the constraints are all still in there. So are the stories people tell about them, and those stories have consequences.

Where engineering and psychology actually meet

For a while I assumed this was a career correction. I'd spent years learning how systems work, then discovered I'd been missing the most interesting part of them, and the honest response was to start over somewhere else. Clegg and colleagues (2017) convinced me otherwise, and not in the way I expected. Their argument isn't that organisational psychology brings a human dimension to engineering. It's that organisational psychology can work as a design science: a method for predicting how a socio-technical system will malfunction before anyone builds it. They call it PreMiSTS. You take a proposed design, work systematically through its social and organisational dimensions, and generate specific predictions about where it'll go wrong once people are inside it.

Read that again as an engineer, because it took me a while. That's not a softer discipline arriving to add nuance. That's failure mode analysis, run over the parts of the system the failure mode analysis was leaving out.

It reframes the whole problem for me. My engineering training wasn't wrong to want prediction, control and design. Those instincts were correct. What was short was the inventory. I had a rigorous method and an incomplete list of what belonged in the model, and an incomplete list produces confident predictions that are wrong in ways the method itself can't detect. The equipment mattered. The procedures mattered. The constraints mattered. So did what people believed about all three, and that's never a footnote to the analysis. It's a variable I hadn't been taught to write down. And it turned out to be the one variable that could read the rest of the model and respond to it.

What I'm learning now

So where does that leave me? Mid-crossing. Fifteen years around technical systems, WHS, management and eventually coaching, now studying the psychology underlying the human systems I spent that whole time working inside. What's changed isn't the method, it's the list. I still trace constraints and interactions. I've just added questions I wasn't taught to ask. What do people think this intervention is for? What will they believe about it once it's running, and what will that belief make true? What is the system quietly rewarding while its procedures say otherwise? I don't have the answers. I'm a third-year psychology student, not an organisational psychologist, which is exactly why the questions are the interesting part.

There's something slightly humbling in this whole thing. Roscoe and colleagues (2020) studied undergraduates learning human systems engineering, a field built deliberately around the overlap I'd spent fifteen years stumbling into. What took me a career and a career change is now a subject you can enrol in. For now, I'm learning to look at systems I've always worked in and see more of what's already there.

So what did it get wrong?

It taught me that systems are knowable. That behaviour has causes, that causes can be traced, and that "people are complicated" is where the analysis starts, not where it stops. I still believe every word of that. It's the most useful thing I own, and I'd sooner give up my degree than my suspicion that there's a mechanism in here somewhere.

What it got wrong was smaller and much harder to spot. Not that people belong in the model. Any half-baked engineer knows that. It's that the people in the model are reading it over your shoulder. They form a view about what the system is for and who it actually serves, they act on that view, and the acting quietly changes the thing they were forming a view about. The drivers spent their margin. The crew signed the sheet. Neither was a malfunction. Both were the system working exactly as the people inside it understood it, which is an entirely different sentence from the system working as designed, and I spent an embarrassing number of years not noticing the difference.

That doesn't make systems thinking less useful. It makes it more demanding, because the boundary of the diagram turns out to be a decision rather than a given. Draw it around the equipment and you'll be right about the equipment. Draw it wider and you have to account for something no component has ever done, which is hold an opinion about being part of the system. The system was never just the thing I could draw. It's also the people looking at the drawing, deciding what it meant, and then going back to work.