Complexity and the Engineer’s Instinct to Simplify
My natural instinct as an engineer is to simplify.
I want to separate a complicated system into components, identify the inputs and outputs, find the governing rules and rebuild the explanation from something small enough to hold in my head — a space with famously strict capacity limits.
This is often useful. It is how we debug software, design architectures and explain unfamiliar systems. Good abstractions protect us from details that are irrelevant to the task at hand.
But simplification has a failure mode: it can quietly remove the very thing we were trying to understand.
Some problems are complicated because we have not yet found the right model. Others are complicated because reality contains genuine tensions, competing values and uncertain consequences. In those cases, a neat model may be less an explanation than a deletion.
Large public decisions provide obvious examples. A major infrastructure project — say, a new reservoir — can be reduced to cost, engineering risk, environmental impact, displaced communities, economic benefit or long-term resilience.
Each of those is real. None is the whole decision.
A person who seizes one dimension and declares it decisive may produce a clear argument, but clarity is not the same as completeness. Another person can select a different dimension and produce an equally clear argument in precisely the opposite direction.
The disagreement then appears to be about facts, when it may really be about which facts were admitted into the model in the first place.
Engineers do this too. Constantly.
We may optimise a service for latency while quietly excluding operability. We may choose the cheapest infrastructure while ignoring staff time. We may measure throughput without measuring recoverability. We may call an architecture “simple” because its complexity has merely been transferred into deployment, support or some poor human’s standard operating procedure.
Nothing has disappeared. It has simply moved outside the diagram, where it waits patiently.
The danger is greatest when the simplified explanation becomes persuasive. A model that fits in one sentence travels well. It is easy to remember, easy to repeat and easy to defend at a dinner party.
Complexity is far less portable.
This creates an uncomfortable tension. We cannot reason effectively about everything at full resolution. We need abstractions. We need summaries. We need to decide which details matter.
The answer is not to abandon simplification, but to treat it as a tool with limits.
A useful model should tell us not only what it includes, but what it leaves out.
When I explain a technical system, I can say: this is the simplified version; it ignores retries, degraded modes and operational ownership. That single warning preserves the value of the model without pretending it is the whole truth.
We should do the same with social and political explanations.
For example:
- If I frame the issue economically, what moral or cultural concerns disappear?
- If I frame it as a question of individual freedom, what collective risks vanish?
- If I frame it around efficiency, whose inconvenience becomes invisible?
- If I reduce a person’s behaviour to one motive, what circumstances have I excluded?
This is not a demand for endless qualification. Decisions cannot wait until every ambiguity has been lovingly resolved. But it is a defence against false certainty.
The most dangerous simplifications are usually the ones that flatter our existing preferences. They let us dress a value judgement up as an inevitable consequence of pure logic.
An engineer may say, “The obvious solution is to automate it.” Obvious according to which objective? Cost? Speed? Consistency? Headcount? And what becomes of judgement, exception handling and accountability?
A manager may say, “We need a process.” Perhaps. Or perhaps the process will supply the comforting appearance of control while making the real work harder.
A politician may say, “The public voted for this.” Even when true, that rarely settles what this means in practice.
A religious speaker may quote a short passage as though it closes a question that has been argued for centuries.
The common pattern is compression: a complex field squeezed until one conclusion appears unavoidable.
Sometimes that is exactly what good reasoning achieves. A mass of noise is stripped away and the essential mechanism stands revealed.
The challenge is telling that apart from simply hacking the problem to fit the model — lopping off every limb that will not fit the bed and calling the corpse elegant.
One test is whether the simplified model can survive contact with its strongest counterexample.
Another is whether people who disagree recognise their concerns within it. They need not accept the conclusion, but if they say, “That description omits the entire reason I object,” then the model is probably too thin.
A third is whether the explanation still works when circumstances change. Brittle models function only while their hidden assumptions quietly hold.
I still believe in simplification. It is one of the most valuable habits in engineering and one of the best ways to make difficult ideas accessible.
But simplification should produce a map, not a replacement for the territory.
A good map makes movement possible. A bad one gives you confidence while leaving out the cliff.
Cite this article
Byatt, S. (2026, May 11). Complexity and the Engineer’s Instinct to Simplify. Learning Out Loud. https://learningoutloud.stephenbyatt.com/blog/complexity-and-the-engineers-instinct/
@online{byatt2026-complexityandtheengineersinstinct,
author = {Stephen Byatt},
title = {Complexity and the Engineer’s Instinct to Simplify},
year = {2026},
date = {2026-05-11},
url = {https://learningoutloud.stephenbyatt.com/blog/complexity-and-the-engineers-instinct/},
urldate = {2026-05-11},
note = {Learning Out Loud}
}