Engineering meets Management

Technical systems rarely succeed simply because each of their individual components has been engineered exceptionally well. Sound engineering is, of course, essential: software must operate reliably, networks must be robust, interfaces need to be clearly defined and requirements must be implemented correctly. Without technical understanding and sufficient depth of expertise, there is no solid foundation for a dependable solution.

As complexity increases, however, the nature of the challenge begins to change. It is no longer enough for individual components to function correctly in isolation. What becomes equally important is whether requirements are understood consistently, technical dependencies become visible early enough, decisions can be made when they are needed, and different disciplines are able to work towards a coherent overall result.

Technical quality therefore does not emerge only from code, hardware or system architecture. It is also shaped by the interaction between technology, people, processes and decisions. This is where engineering and management begin to meet.

When a technical task becomes a systems problem

As long as a technical task is clearly bounded, it can often be solved within a single discipline. As systems grow, however, it is not only the number of components that increases. More importantly, the number of relationships and dependencies between those components grows as well.

Software communicates with hardware, functions depend on communication networks, mechanical constraints influence electrical solutions, and requirements often affect several subsystems simultaneously. A change that appears both reasonable and local within one discipline may therefore have unexpected consequences somewhere else in the system.

In complex environments, complexity is often created less by the individual elements than by the relationships between them. For engineering, this means that optimising one component is eventually no longer sufficient. It becomes equally important to understand the role that component plays within the wider system, what information and assumptions it depends on, and how changes may affect neighbouring disciplines or subsystems.

What initially appears to be a technical task gradually becomes a systems problem. Systems problems, by their nature, can only be optimised to a limited extent within individual disciplinary boundaries.

Good engineering needs the right conditions

Engineering never takes place in isolation. Technical teams work within projects, organisations, schedules, processes and decision structures, all of which have a direct influence on the quality of their work.

A capable team can compensate for ambiguity and organisational weaknesses for a certain amount of time. Persistently conflicting requirements, missing decisions, changing priorities or unclear responsibilities, however, cannot be offset indefinitely by adding more technical competence. Eventually, organisational weaknesses become technical problems.

This leads to what I consider one of the central responsibilities of management in a technical organisation. Management should not attempt to prescribe the technical solution. Its role is to create the conditions under which qualified people can make sound technical decisions. This includes clear objectives and responsibilities, but also transparent decision paths, stable priorities and processes that reduce uncertainty rather than introduce additional friction.

The quality of a technical result therefore depends not only on how well engineering is performed, but also on the conditions under which engineering takes place. Management is no longer merely an administrative layer surrounding engineering; it becomes a factor that can either enable technical quality or make it significantly harder to achieve.

Requirements Engineering connects needs with technical reality

This relationship becomes particularly visible when dealing with requirements. At first glance, a requirement may appear to be a purely technical artefact describing a desired behaviour or characteristic. In a complex development process, however, it fulfils a much broader role.

A requirement connects an underlying need with a later technical solution. It creates a shared point of reference across different disciplines, provides a basis for specifications and decisions, and ultimately defines what needs to be verified in order to demonstrate that the developed system actually fulfils its intended purpose.

This creates a continuous chain:

Need → Requirement → Specification → Implementation → Verification

The earlier ambiguity enters this chain, the further it can propagate through the development process. A requirement that allows multiple interpretations may, for example, be understood differently by separate disciplines. This can result in several solutions that are individually technically plausible but incompatible when integrated into the overall system.

The difficulty is that such inconsistencies often become visible only much later, during integration or verification. By then, the observable problem may be far removed from its original cause, making correction significantly more expensive.

For me, good Requirements Engineering is therefore much more than clear wording or documentation. It is a means of structuring complexity early and establishing a shared understanding. Clear requirements provide orientation, traceability makes dependencies transparent, and verification closes the loop between the original expectation and the resulting system.

Requirements therefore sit directly at the interface between technical precision and organisational clarity.

Decisions shape technical systems

Another factor that is often underestimated is the role of decisions. Technical development constantly involves trade-offs: architectures are selected, constraints are prioritised, risks are assessed, assumptions are accepted and proposed changes are evaluated.

These decisions are not separate from the technical solution. They actively shape it.

Problems arise when sufficient technical information is available, yet it remains unclear who is authorised or expected to make the necessary decision. The result may be waiting time, parallel solutions or local decisions that later have to be reversed.

A functioning decision structure does not necessarily mean additional hierarchy or more approval stages. What matters is clarity about which decision is required, what information is necessary to support it, who prepares the technical basis, who carries responsibility for the decision and how the outcome is documented in a traceable way.

Seen from this perspective, governance becomes highly practical. Its purpose is not to place another organisational layer above engineering, but to ensure that technical work remains capable of progressing when several interests, disciplines or responsibilities intersect.

Processes should support engineering

The same principle applies to processes. Within technical organisations, processes often have an ambiguous reputation. On the one hand, there is an expectation that clearly defined processes will automatically produce better results. On the other, processes are frequently perceived as bureaucracy that prevents specialists from concentrating on their actual work.

Both views are incomplete.

A useful engineering process should not create activities merely because they appear in a process model. Its purpose should be to reduce uncertainty and risk at the points where doing so creates value. A good process clarifies when a work product is mature enough to move forward, which information must be available, how reviews are performed, how changes are handled and how it is demonstrated that an implemented solution actually fulfils its original requirements.

This changes how process quality should be evaluated. The relevant measure is not the number of steps or documents, but the contribution those steps make to the quality of technical decisions and outcomes.

For that reason, I find a different question far more useful than asking how much process an organisation needs:

Which process helps us make better technical decisions?

If a process creates clarity, exposes errors earlier or prevents unnecessary iterations, it supports engineering. If it mainly generates additional work without reducing uncertainty or risk, the answer should not be to force the team to adapt more rigidly to the process. The process itself should become a subject of improvement.

Management needs technical proximity

The relationship between engineering and management also works in the opposite direction. Just as technical teams require appropriate organisational conditions, management in a technical environment needs sufficient proximity to technical reality.

Anyone setting priorities, assessing risks, defining schedules or allocating resources does not need to solve every technical detail personally. They do, however, need enough understanding of the underlying relationships to assess the consequences of their decisions realistically.

A technical dependency does not disappear because a schedule has been changed. A risk does not become smaller simply because it has been categorised differently. And an unresolved technical interface does not become clear merely because a responsible role has been assigned to it on paper.

Managing technical work therefore requires the ability to recognise relationships and ask the right questions. The objective is not to replace engineering, but to make decisions on a technically credible foundation.

Technical depth and management perspective are therefore not opposites to me. They are different views of the same system, and together they provide a more complete understanding of it.

Systems Thinking broadens the perspective

As systems and organisations become more complex, it becomes increasingly difficult to understand problems by looking only at their immediate location. Causes and visible effects may be far apart, and an optimisation within one area may even have negative consequences for the system as a whole.

An organisational decision may produce technical side effects. At the same time, a technical architecture can influence how teams need to collaborate, which information must be exchanged and where decisions have to be made.

Systems Thinking helps place these relationships at the centre of the analysis. Instead of looking only at individual elements, attention shifts towards dependencies, interfaces, feedback loops, information flows and the consequences of change.

This perspective applies to technical systems just as much as it does to organisations. A communication network is not simply a collection of devices, but a set of relationships and information flows between them. A development process is not only a sequence of activities, but also a network of transitions, decisions and information. An organisation consists not merely of roles and departments, but also of responsibility, communication and collaboration.

Once those relationships are considered more deliberately, the distinction between a purely technical problem and a purely organisational one often becomes less clear. Many difficulties emerge precisely because a problem has been examined from only one of these perspectives.

Turning technical experience into organisational learning

This way of thinking also raises the question of what happens after a problem has been identified and solved.

Technical projects constantly generate new knowledge. A test may reveal an unexpected interaction, integration may expose an unclear interface, a review may uncover an ambiguous requirement, or a project may show that a defined process creates unnecessary iterations in practice.

The immediate problem obviously needs to be solved. The greater value, however, comes from asking what the wider system can learn from it.

If the same type of issue occurs repeatedly, the cause may no longer lie with a single person or isolated implementation. Perhaps an important quality check is missing, a responsibility is unclear, or a relevant piece of information becomes available too late. A formal process may not reflect the actual way work is performed, or an interface may not be sufficiently clear from an organisational perspective.

Continuous Improvement therefore means more to me than making processes progressively faster or more efficient. It means feeding operational and technical experience back into requirements, processes, tools and collaboration.

In this way, technical experience becomes organisational learning, and this feedback loop is one of the strongest connections between engineering and management.

The questions begin to change

With this perspective, the questions we ask about technical problems also begin to change.

Alongside the question of how a function should be implemented, we need to ask how we ensure that everyone involved understands that function in the same way.

Alongside the question of which technical solution is possible, we need to consider which solution can remain manageable under the actual constraints of the system and organisation.

When discussing responsibility, the relevant question is not only who performs a task, but who can make and own a decision at a cross-disciplinary interface.

And when investigating a defect, identifying its immediate technical cause may not always be sufficient. It may be equally important to understand which structure, process or flow of information allowed that defect to emerge in the first place.

These are the questions that interest me most because they connect technical depth with a view of the wider system.

Engineering meets Management

For me, “Engineering meets Management” does not mean placing two separate disciplines side by side. It describes the space in which technical reality and organisational design directly influence one another.

Engineering provides an understanding of functions, architectures, dependencies and technical risks. Management provides orientation, priorities, responsibility and the ability to make decisions. Requirements Engineering connects expectations with concrete technical solutions, processes structure collaboration and information flows, and Systems Thinking helps us understand effects that cross disciplinary and organisational boundaries.

Continuous Improvement ultimately ensures that experience does not remain isolated within a single problem or project, but is fed back into the system.

Only through this interaction can an environment emerge in which complex technical systems are not merely developed, but can also be understood, operated and continuously improved over time.

For me, this connection can ultimately be reduced to four ideas:

Understand technology.
Recognise relationships.
Create structure.
Learn from experience.

That is where I see the connection between engineering and industrial management.