Wednesday Reality: Engineering Begins Where Reality Refuses to Cooperate

The Component Designed to Fail

Open an electrical cabinet and somewhere among the expensive equipment, carefully sized conductors and protective devices you may find something rather peculiar: a component whose successful operation can require its own destruction. A fuse carries current quietly for years, contributing nothing visible to the productive function of the system, until current exceeds a predetermined threshold. Then a thin piece of metal heats, melts and permanently interrupts the circuit. The failed component lies blackened inside an otherwise surviving installation. An engineer looking at it does not necessarily see a defective part. Under the right circumstances, the destroyed fuse provides evidence that the system behaved exactly as designed.

The principle appears throughout engineering in different forms. Mechanical systems use shear pins intended to break before excessive torque destroys machinery. Pressure vessels use relief devices because containing unlimited pressure would require impossible structures. Cars incorporate crumple zones that deliberately deform so that kinetic energy dissipates somewhere less consequential than the occupants. Ships divide hulls into watertight compartments because preventing every breach cannot realistically form the basis of maritime safety. Aircraft distribute critical functions across redundant systems because components, however carefully designed and maintained, eventually fail. Engineers do not celebrate any of these events. They simply refuse to make the absence of failure a prerequisite for successful operation.

This reveals something deeper about engineering than reliability:

Engineering begins with an acceptance that reality imposes conditions the designer does not control.

Materials have limits. Energy costs something. Components age. Manufacturing introduces tolerances. Information arrives late or inaccurately. Humans make mistakes. Weather changes. Loads fluctuate. Money runs out. Time remains finite. The interesting engineering problem rarely starts with a blank sheet and unlimited resources. It starts when something must work despite everything preventing the ideal solution from existing.

Engineering, viewed from this perspective, becomes the art of delivering under constraints.

Reality Is Part of the Design

Constraints do not merely make engineering harder. Without them, much of engineering would become unnecessary. If mass carried no penalty, aircraft structures could become arbitrarily strong. If energy cost nothing, efficiency would matter little. If materials never degraded, maintenance engineering would largely disappear. If components never failed, redundancy would become waste. If money and time remained unlimited, many optimisation problems could simply disappear beneath extravagant overdesign.

Real engineering instead consists of uncomfortable exchanges between desirable properties. Aircraft trade strength against weight, redundancy against complexity and performance against fuel consumption. Bridges balance material, span, loading, construction methods, maintenance and economics. Manufacturing systems negotiate precision against throughput and cost. Computer systems trade consistency, availability, latency, capacity and resilience in combinations that refuse to maximise simultaneously. Improving one property frequently worsens another because the system lives inside several constraints at once.

This is why engineering differs fundamentally from implementing an ideal specification. The engineer must determine which constraints deserve challenging, which can move at an acceptable cost, which interact with others and which reality will simply refuse to negotiate. Treating every constraint as immutable produces timid engineering. Treating every constraint as removable produces fantasy. Excellence lies partly in recognising the difference.

A fuse illustrates this distinction with almost embarrassing economy. The designer does not attempt to guarantee that excessive current will never occur. Neither does the designer accept that excessive current must therefore destroy whatever happens to lie downstream. The event itself remains possible while its consequences become bounded. The engineering achievement lies not in eliminating reality but in deciding how much of the system reality may take with it.

Drawing the Boundary

Once failure enters the design, another question immediately follows: where should it stop?

Ships provide an unusually physical answer. A hull without internal subdivision can survive perfectly while intact yet become extraordinarily vulnerable once breached. Watertight bulkheads change the topology of the failure. Water may still enter the ship, but the architecture limits how much volume it can occupy before encountering another boundary. The bulkhead does not remove the ocean, prevent collisions or make steel invulnerable. It changes the relationship between a local event and the survival of the whole vessel.

Electrical protection does something similar with current. Firebreaks do it with combustion. Pressure relief systems do it with stored energy. Network segmentation does it with traffic and faults. Aircraft architectures do it with electrical, hydraulic and control systems. The physical phenomena differ, but the systemic question remains recognisable: how far can a disturbance propagate before the architecture stops it?

Boundaries therefore do more than separate components. A useful boundary controls propagation while preserving the interactions necessary for the larger system to function. Make the boundary too porous and disturbances travel everywhere. Make it too rigid and productive interaction becomes impossible. Engineering cannot choose boundaries merely because they produce neat diagrams. Their quality appears when the system encounters variation, overload, uncertainty and failure.

This is where systems thinking becomes indispensable. It provides the mindset and intellectual apparatus for seeing constraints not as isolated inconveniences but as properties of interacting systems. Boundaries matter, but so do stocks and flows, feedback loops, delays, dependencies, accumulation and non-linear responses. The difficult part often lies not in understanding individual components but in recognising how their relationships produce behaviour that no component contains independently.

The Boundary Changes What You See

Systems thinking introduces an uncomfortable complication: some boundaries belong to the physical system, while others belong primarily to the observer.

A factory contains real machines with measurable capacities, but the analyst decides whether the system under examination consists of one machine, a production cell, an assembly line, the factory, its suppliers or the entire supply network. Every choice changes what appears efficient. A machine running continuously can display excellent utilisation while producing inventory faster than the downstream process can consume it. Inside the machine's boundary, performance improved. Expand the boundary to include the queue and the achievement becomes less impressive. Expand it again to include working capital, storage, defects and customer demand and the same optimisation may appear actively destructive.

Nothing changed physically. Only the boundary of observation changed.

Feedback loops make these mistakes particularly treacherous because interventions return through the system in altered form. Add approvals to reduce mistakes and lead time increases. Longer lead times encourage larger batches because obtaining approval becomes expensive. Larger batches increase the consequences of each mistake. More consequential mistakes strengthen the argument for additional control. Every individual decision can appear rational while the loop progressively produces the opposite of its intended outcome.

Systems thinking therefore does not merely help engineers decompose complicated problems. It determines whether decomposition remains faithful to the system in the first place. Before separating a system into manageable pieces, someone must understand enough of its interactions to know what can safely separate, what must remain connected, where feedback crosses the proposed boundaries and which properties only exist at the level of the whole.

Otherwise decomposition merely makes complexity easier to administer while leaving the underlying system untouched.

The Seduction of Smaller Boxes

Modern organisations perform decomposition constantly. They create departments, teams, squads, streams, tracks, programmes, platforms, projects and increasingly fashionable pairs or trios. The implicit assumption suggests that smaller organisational units produce smaller problems, greater autonomy and faster delivery. Yet reducing the number of people inside a box says remarkably little about the productive system surrounding it.

Three engineers can form a beautifully compact unit while depending on another team for deployment, another for data, another for infrastructure, another for customer knowledge and a committee for architectural approval. Their social group became smaller while their delivery system remained distributed across half the organisation. The decomposition changed the arrangement of people without changing the structure of the problem.

This distinction matters because genuine engineering decomposition does not primarily ask how many people fit comfortably inside each compartment. It asks what interactions must cross the boundary after the decomposition. Every new boundary creates an interface, and every interface introduces some combination of information loss, delay, coordination, negotiation and failure modes. Smaller components can make a system easier to understand, but excessive or incorrectly placed boundaries can make the whole system harder to operate.

Organisations then discover the resulting coordination burden and respond by building machinery around it. Cross-team planning appears. Dependency boards multiply. Programme management expands. Integration meetings become necessary. Roadmaps acquire coloured lines connecting initiatives. Tickets link to other tickets whose completion depends on tickets elsewhere. Eventually a substantial population spends its time reconnecting work that the organisational architecture previously separated.

Coordination has value, but persistent coordination demand can also reveal architectural debt. It may represent the tax an organisation pays for drawing boundaries around convenient groups of people rather than around coherent capabilities.

Follow the Disturbance

Physical engineering offers a useful way to inspect those boundaries: introduce a disturbance and observe how far it travels.

When excessive current appears, which circuits disappear? When a compartment floods, how much buoyancy remains? When an engine fails, which electrical and hydraulic functions become unavailable? When a bearing seizes, what else breaks before the machine stops? Engineers learn a great deal about architecture by studying propagation because propagation reveals relationships that normal operation can hide.

Organisations reveal themselves in much the same way. A customer changes an important requirement and five teams enter replanning. A senior engineer leaves and an entire technical capability becomes inaccessible. One service fails and the complete product disappears. A project slips by two weeks and several supposedly independent initiatives move with it. One executive changes a priority and work throughout the organisation stops while plans get reconstructed.

None of these events necessarily represents the original problem. People leave. Customers change their minds. Software fails. Estimates prove wrong. Priorities move. Those conditions belong to the environment in which organisations operate just as corrosion, fatigue and variable loads belong to physical engineering.

The revealing question concerns how much of the organisation must participate in absorbing the disturbance.

A system requiring global coordination to resolve local uncertainty has not eliminated uncertainty. It has amplified its propagation.

The Economics of Propagation

Propagation carries an economic cost that conventional efficiency measures often hide. A five-minute technical failure can consume hundreds of hours when its consequences cross enough organisational boundaries. A modest product decision can trigger meetings across several departments. A small change can require weeks because implementation represents only a fraction of the total work; most elapsed time accumulates while information crosses interfaces, enters queues, waits for decisions and returns with another dependency attached.

Good engineering boundaries therefore localise more than technical failure. They localise the cost of uncertainty.

An experiment should consume approximately the resources allocated to the experiment rather than destabilising an entire portfolio. A failed deployment should consume recovery capacity proportional to the deployment rather than organisational attention across several departments. A wrong decision should remain cheap enough to reverse. A local variation in demand should not automatically require global replanning.

This explains why attempts to eliminate every small failure can paradoxically create expensive systems. Every additional protection mechanism consumes something: money, capacity, latency, optionality or attention. Preventing the final fraction of risk frequently costs more than tolerating its consequences. Engineering therefore asks not whether failure sounds undesirable but whether preventing it represents a better system-level trade than containing it.

The humble fuse embodies that economic judgement. Something cheap and replaceable receives permission to die so that something expensive survives.

Organisations rarely state the equivalent decision explicitly. They seldom ask which experiments may fail, which decisions may prove wrong, which local commitments may disappear or how much capacity can deliberately remain unused to absorb variation. Instead they frequently attempt to protect every commitment simultaneously. The resulting controls increase coupling, and coupling increases the number of things affected when something eventually escapes those controls.

The pursuit of zero local loss can quietly manufacture enormous global fragility.

Constraints We Inherited

There remains another difficulty. Not every organisational constraint deserves the respect engineers give gravity.

A physical system imposes constraints that cannot disappear through persuasion. Materials have yield strengths. Networks have propagation delays. Processors have finite capacity. Time moves stubbornly in one direction. Organisations, however, contain another category of constraint: yesterday's decisions.

A six-stage approval process can eventually acquire the psychological status of a law of nature. Team boundaries inherited from an acquisition become assumptions embedded in architecture. A budgeting mechanism determines project structure, which determines team structure, which determines software boundaries, until an accounting decision made years earlier appears to describe the natural topology of the product. People then optimise brilliantly inside a constraint that nobody remembers choosing.

Systems thinking helps distinguish constraints imposed by reality from constraints produced by the system itself. Both affect behaviour, but they demand different responses. An engineer who ignores a physical constraint produces failure. An engineer who unquestioningly accepts every inherited organisational constraint may spend years solving problems that need not exist.

Sometimes the constraint deserves accommodation. Sometimes it deserves removal. Sometimes changing it would simply move the problem somewhere more expensive. Determining which case applies requires looking beyond the immediate component and tracing feedback, incentives and consequences through the wider system.

That capacity, more than the sophistication of any individual solution, marks mature systems engineering.

When the Bulkheads Are in the Wrong Place

The language of modern organisations contains an interesting contradiction. We speak constantly about autonomy while constructing systems that require extraordinary coordination. We create smaller teams while increasing the number of interfaces between them. We celebrate ownership while distributing the capabilities required to exercise that ownership. We pursue utilisation while removing the spare capacity required to absorb variability. We attempt to prevent mistakes while constructing approval systems whose delays encourage larger, riskier batches.

None of these contradictions originates primarily from incompetent individuals. Each can emerge naturally when people optimise within boundaries they inherited and metrics that make sense locally. The machine operator maximises utilisation. The manager protects the quarterly commitment. The architect protects consistency. The finance function protects predictability. The delivery organisation protects the plan. Every component behaves sensibly, and the whole system becomes progressively stranger.

Systems thinking does not magically resolve those tensions. It merely makes them harder to ignore. It asks us to observe where value actually flows, where information accumulates, where decisions wait, where feedback arrives too late and where disturbances repeatedly escape the boundaries supposedly designed to contain them. The resulting picture often looks rather different from the organisation chart.

Engineering has encountered this problem for centuries in less forgiving environments. When water repeatedly crosses compartments, naval architects eventually investigate the bulkheads. When mechanical energy destroys adjacent components, engineers reconsider where the system should break. When faults cascade through electrical networks, grid engineers examine protection zones and isolation mechanisms. Reality supplies feedback with unusual clarity.

Organisations enjoy more freedom to reinterpret the evidence. They can call propagation an alignment problem, add another coordination mechanism and continue operating the same architecture.

That freedom can last surprisingly long.

Eventually, however, enough coordination accumulates that the organisation spends an increasing proportion of its capacity compensating for its own boundaries. More planning becomes necessary because delivery has become unpredictable. More governance becomes necessary because decisions propagate widely. More communication becomes necessary because knowledge sits on the wrong side of organisational interfaces. More managers become necessary because autonomous units cannot actually act autonomously. The mechanisms introduced to control complexity gradually become part of the complexity they attempt to control.

At that point, another reorganisation often arrives. The boxes move again. The constraints remain.

Engineering Under Reality

Perhaps this explains why engineering, at its deepest level, has relatively little to do with making things perfect.

Perfection would require reality to stop participating.

Engineering instead develops ways of delivering while reality continues imposing weight, cost, uncertainty, failure, delay, scarcity and change.

Systems thinking strengthens that discipline by forcing attention beyond individual components. It makes boundaries visible, exposes feedback loops, follows disturbances, questions inherited constraints and reveals when local improvements degrade the larger system. It does not remove complexity. It helps determine which complexity belongs to reality and which complexity the system has manufactured for itself.

The distinction becomes increasingly important as technology increases local productive capacity. Faster implementation, automation and AI can reduce the effort required to change individual components, but they cannot repeal the relationships between those components. Increasing the speed inside poorly chosen boundaries can simply make queues accumulate faster elsewhere, increase the rate at which dependencies collide and amplify disturbances through the same architecture. More power does not correct a badly designed system; occasionally it merely allows the system to reach its limits sooner.

Somewhere inside an electrical cabinet, none of this appears particularly philosophical. Current exceeds a safe threshold. A thin conductor heats until it melts. The circuit opens. The disturbance stops. The expensive equipment survives.

Later, someone opens the cabinet and finds the small blackened component that failed.

An engineer looking at it may see something rather different from failure. The constraint appeared exactly as reality promised it eventually would. The boundary held. The damage remained local. The larger system continued doing what it had been built to do.

Perhaps the most revealing question about any engineered system, including an organisation, starts there: not whether something will eventually fail, but how much of the system we have designed to fail with it.