5 min read

Wednesday Reality: We Did Not Lose Engineers. We Stopped Engineering.

Software proudly adopted the language of engineering, but somewhere along the journey it quietly abandoned many of its defining characteristics. The transformation was gradual enough to appear natural.
Wednesday Reality: We Did Not Lose Engineers. We Stopped Engineering.

The Merlin Engine

In 1933, Rolls-Royce began developing what would become one of the most remarkable engineering achievements of the twentieth century. The Merlin engine would eventually power the Spitfire, the Hurricane, the Lancaster and later the P-51 Mustang. More than 150,000 would be built during the Second World War, each containing thousands of precisely manufactured components operating under enormous thermal and mechanical stresses. It became a symbol not simply of British engineering, but of what engineering itself once meant.

The Merlin was never the product of isolated expertise. Metallurgists understood that a microscopic imperfection could shorten the life of a valve. Machinists challenged drawings that ignored the realities of manufacturing. Designers spent time on the shop floor because steel often exposed assumptions that paper concealed. Test engineers questioned decisions made months earlier because the engine ultimately answered only to physics. There were specialists, but there were no spectators. Every discipline understood that its own work existed only in relation to the whole machine.

Reality offered no comfort to those wishing to remain inside the boundaries of a job description. The Merlin did not distinguish between a design defect, a manufacturing error or a maintenance oversight. It either produced power at altitude or it failed. Engineering has always lived in close proximity to consequences because consequences refuse to recognise organisational boundaries.

The Slow Separation from Reality

Software proudly adopted the language of engineering, but somewhere along the journey it quietly abandoned many of its defining characteristics. The transformation was gradual enough to appear natural.

Organisations became larger. Teams became more specialised. Responsibilities became clearer. Governance became more sophisticated. Every individual change appeared rational, yet together they created something few people anticipated. Engineers became increasingly distant from the systems they supposedly owned.

Customers moved into Product. Reliability moved into SRE. Infrastructure became the responsibility of Platform teams. Security became a specialised function. Architecture migrated towards review boards and committees.

Operations became somebody else's concern. The engineer's world slowly contracted until it comfortably fitted inside a backlog item, a sprint commitment and a narrowly defined area of ownership.

The vocabulary changed with the organisation. Expressions that would once have sounded like admissions of failure gradually became signs of professionalism. It became perfectly acceptable to explain that a production issue belonged to another team, that investigating customer behaviour was outside one's responsibilities or that a problem had not been addressed because it was not part of the sprint objective. These statements rarely provoke concern because the organisation itself has normalised them.

Traditional engineering would have struggled to recognise such behaviour. A bridge does not partially collapse because structural integrity belonged to another department. An aircraft engine does not lose power according to the organisation chart. Complex systems remain stubbornly indifferent to the way organisations divide responsibility.

When Curiosity Becomes Irrational

The most profound change has not been technological. It has been psychological.

Engineers rarely begin their careers disengaged. Most arrive with a natural desire to understand how systems behave, why failures occur and how seemingly unrelated components influence one another. They explore unfamiliar code because curiosity is part of learning. They investigate production incidents because understanding the system feels intrinsically valuable. They ask questions that extend beyond their immediate assignment because engineering has always rewarded those who understand more than the task directly in front of them.

Modern organisations gradually teach different instincts.

Understanding another team's system often means inheriting another team's problems. Investigating production increases expectations that one will support it in the future. Helping outside the boundaries of a sprint damages local delivery metrics. Challenging architectural decisions slows feature delivery. Looking beyond one's immediate responsibilities generates remarkably little organisational reward while frequently increasing personal accountability.

People adapt exactly as any rational system predicts they will. Curiosity slowly becomes expensive. Ownership becomes risky.

And remaining inside the boundaries of the ticket becomes efficient.

Disengagement is therefore not introduced through laziness or a lack of ambition. It emerges naturally from an environment that consistently rewards local optimisation over systemic understanding.

The New Reward System

Engineering has always offered a particular kind of satisfaction. A bridge opening to traffic, an engine completing endurance testing or a spacecraft reaching orbit represented the culmination of thousands of interconnected decisions finally validated by reality. The reward came from witnessing a complete system behave as intended.

Software organisations increasingly reward something quite different.

Backlog items move across boards. Stories are accepted. Sprint goals are achieved. Velocity improves. Dashboards remain green. Every administrative milestone produces a small psychological reward, even when the customer's experience remains largely unchanged. Progress through the delivery process gradually becomes more visible than progress within the product itself.

This matters because human beings optimise for the feedback they receive.

When organisations celebrate ticket completion more consistently than customer outcomes, engineers naturally become experts at completing tickets. When individual throughput receives greater recognition than collective understanding, curiosity becomes progressively less valuable. The profession slowly exchanges craftsmanship for workflow optimisation without anybody consciously deciding that such a trade has taken place.

The danger is not that engineers become less capable.

The danger is that capable engineers become disconnected from the very systems they once sought to understand.

The Illusion of Professionalism

Perhaps the most revealing symptom of this transformation is the growing belief that professionalism means remaining inside the boundaries of one's formal role.

Many organisations now consider it entirely reasonable for engineers to avoid production because operations belongs elsewhere, to avoid customers because Product owns the relationship, to avoid architecture because governance committees exist or to avoid challenging requirements because implementation is considered sufficient. Respecting boundaries has gradually become synonymous with respecting the organisation.

Yet engineering has never worked that way.

The Merlin engine succeeded precisely because people crossed boundaries continuously. Manufacturing challenged design. Testing challenged manufacturing. Maintenance influenced future engineering decisions. Expertise remained specialised, but responsibility remained collective because the machine itself demanded it.

Modern software systems are no less interconnected. Only our organisational models increasingly pretend otherwise.

Artificial Intelligence Will Magnify the Problem

Artificial intelligence has become the latest explanation for the changing nature of software engineering. Some predict unprecedented productivity while others fear widespread replacement. Both discussions overlook a more fundamental observation.

Technology rarely changes human intent. It amplifies it.

An engaged engineer uses AI to investigate unfamiliar domains, understand complex behaviour and accelerate learning. A disengaged engineer uses precisely the same tools to avoid developing understanding altogether. One treats AI as a partner in exploration. The other treats it as a substitute for curiosity.

The technology does not determine which outcome prevails. The surrounding culture does.

If organisations already reward superficial completion over deep understanding, AI will simply make superficial completion even faster.

The Generation We Created

It has become fashionable to describe younger engineers as less resilient, less committed or less willing to take ownership than previous generations. Such arguments are attractive because they shift responsibility away from the systems in which those engineers have developed.

A more uncomfortable explanation deserves consideration.

No previous generation has enjoyed greater access to knowledge, more sophisticated development tools or more powerful technology. Engineers can inspect the source code of world-class systems, learn from leading practitioners, simulate complex architectures and now collaborate with artificial intelligence capable of explaining concepts that once required years of experience to acquire.

Knowledge has never been more accessible. What has become scarce is proximity to consequences.

We have created organisations where understanding the whole system is optional, where curiosity often carries penalties, where ownership increases personal risk, where the shortest path to recognition is compliance with process rather than mastery of the product. We have surrounded engineers with coordination mechanisms while steadily removing opportunities to experience engineering itself.

Perhaps this explains why so many talented people appear disillusioned rather than inspired. They did not enter the profession dreaming of optimising workflows, protecting role boundaries or progressing tickets through digital boards. They entered because they wanted to build machines, even if those machines happened to be made of software.

The Rolls-Royce Merlin became legendary because thousands of engineers accepted responsibility for a system that refused to recognise organisational boundaries. Modern software systems remain every bit as complex, every bit as interconnected and every bit as unforgiving.

The difference is not the technology. The difference is that we have spent decades building organisations that progressively separate engineers from the consequences that once defined their profession.

Perhaps we should stop asking why so many engineers appear disengaged.

The more uncomfortable question is whether we have spent the last thirty years designing organisations that could scarcely have produced any other outcome.