Keeping
the whole system
in focus.
Markus Hager
I believe complex engineering programmes work best when the whole system guides decisions and work across the programme.
I work with the people involved to turn this perspective into practical action.
Why do engineering programmes often feel harder than they should?
I’ve worked on fascinating engineering projects with highly capable and motivated people. Yet again and again, bringing everything together and over the finish line proved surprisingly difficult.
Over time, I’ve come to believe that much of this difficulty comes from how we work. We organise engineering around disciplines, teams, work products and individual systems. Yet success depends on how these contributions come together into a functioning system that delivers value to the customer.
Much of the difficulty lies in between.
In developing a shared understanding of the system with customers. In aligning technical decisions and contributions. And in making sure responsibilities, decision-making and collaboration support what the work actually requires.
Making the overall system central to how we engineer, organise and lead the programme can change how everything comes together.
Helping the programme come together.
I work with the people involved to put the overall system perspective into practice. Depending on what the programme needs, I contribute to programme-wide challenges, concrete systems engineering and integration work, or improving how teams, suppliers and organisations work together.
-
01
Programme Focus & Alignment
I help you focus your programme on the work that really matters.
Typical situations
- Everyone is making progress, but it’s unclear how far the overall system has really come.
- The same problems keep coming back to you, even after they’ve supposedly been resolved.
- You spend more time coordinating between teams and resolving escalations than moving the programme forward.
Dedicated page coming soon
-
02
Systems Engineering
I help you bring the different parts of your engineering work together into a functioning system.
Typical situations
- You’re developing a complex system, and keeping the engineering work aligned is becoming difficult.
- You’re putting a lot of effort into engineering processes and documentation, but it’s not clear what you’re getting out of it.
Dedicated page coming soon
-
03
Cross-Company Integration & Collaboration
I help you make the overall system work when you depend on several companies to bring it all together.
Typical situations
- Several companies need to bring their technologies together into one working system.
- You’re having difficulty getting what you need from a supplier.
Dedicated page coming soon
Does this sound like your programme?
We can start with a conversation about what you’re working on, what’s proving difficult, and where I might be able to help.
Where this perspective comes from.
Much of my career has been in medical technology, particularly cancer treatment. There, highly sophisticated technologies, often developed by different companies, must work together reliably in a real clinical environment to treat a patient.
I’ve worked as a Systems Engineer and led larger Systems Engineering efforts, covering almost every aspect of the discipline, from working with customers to understand their needs to making sure the resulting system works as intended.
I’ve also been responsible for bringing systems together across company boundaries. Leading integration and interoperability work, I’ve worked with engineering teams, suppliers, technology partners and customers to resolve problems that no single organisation could solve alone.
This experience has shown me how closely the technical system and the organisation developing it are connected. How we divide work, assign responsibilities and make decisions directly affects whether the different contributions come together.
Today, I bring this experience to engineering programmes where making the whole system work requires more than good engineering within individual teams or disciplines.
What I pay attention to
Four principles that shape how I work in complex engineering programmes.
-
01
Keep the whole system in view
Individual areas can make progress while the overall system falls short. Keeping the whole in view helps align work and decisions with what the customer needs.
A programme is divided so that capable teams can work in parallel. That division is necessary, but it does not guarantee a capable system. Each area can meet its commitments while the behaviour the customer depends on still falls between them, in an interface nobody fully owns, an assumption two suppliers read differently, or a dependency that only appears in operation.
Following intended behaviour end to end, from customer workflow through software, hardware, suppliers and operating environment, makes those connections visible. It shows where handovers lose information, where assumptions differ, and where several conditions interact to create a problem that cannot be understood from one area alone.
Seeing the whole means making sure the system does not disappear between the parts.
-
02
Structure work so people can act together
Clear responsibilities and decision-making authority help people move work forward without constant escalation and unnecessary coordination.
When decisions repeatedly travel up the hierarchy, responsibilities need constant clarification, or experienced people spend much of their time coordinating across boundaries, it is worth looking at how the work is structured.
An effective organisational structure enables people to take responsibility and act. Responsibilities, decision authority and priorities need to fit together, so that decisions can be made close to the relevant knowledge, with clear guardrails for where broader alignment is needed.
In complex engineering programmes, the organisational structure also needs to reflect how the technical system comes together. Ownership of individual parts does not automatically cover the end-to-end outcome. A dependency between systems needs a corresponding way for the teams or companies involved to decide and act together.
Incentives matter as much as formal responsibilities. If teams or suppliers are measured and rewarded only for completing their own scope, resolving a shared problem can work against their immediate interests. Priorities, measures of success and commercial agreements need to support the overall outcome.
The aim is independent action that adds up to a coherent whole.
-
03
Make it clear where the programme really stands
Progress reports don’t necessarily show whether the system will work. Reliable evidence reveals problems early and supports better decisions and commitments.
Completed work, achieved milestones and reassuring status reports do not automatically demonstrate system maturity. An interface can be fully specified and still contain assumptions nobody has tested.
Incremental integration, prototypes and representative environments expose those assumptions while there are still options. External systems, customer workflows and real operating conditions matter because they reveal interactions that isolated tests cannot fully show.
Evidence only helps if it changes something. It needs to reach people who can interpret it and use it to change priorities, commitments and decisions. That requires clear responsibility for integration evidence, authority to act when the evidence contradicts the plan, and clear ownership of the resulting actions across teams or companies.
What matters is knowing what is reliable, what remains uncertain and what to do next.
-
04
Build the capabilities the programme depends on
Programmes need capabilities that span disciplines and functions, so recurring challenges can be handled effectively rather than repeatedly consuming scarce expertise.
Every programme needs to become good at particular things. What those are depends on what the programme needs to achieve and the challenges it faces.
Consider a medical technology programme aiming to launch a new product as soon as clinical studies and regulatory approval allow. Development, integration, verification and clinical activities need to progress together. The programme needs to understand what must be ready when, which dependencies could delay the launch, and how to organise the work accordingly.
Systems Engineering can make an important contribution. Requirements, architecture and verification help establish a sound basis, but the programme also needs to understand dependencies, make decisions across disciplines and demonstrate that the overall system works as intended.
This takes more than a Systems Engineering function. Programme management, engineering leadership, development teams and customer-facing roles all contribute. Their responsibilities, priorities and ways of working need to support the capabilities the programme depends on.
The same thinking applies to AI. Its value depends on how it strengthens those capabilities, whether by making uncertainty visible, connecting evidence or supporting decisions across boundaries.
What matters is whether the programme becomes better at the things its success actually depends on.
Practical toolExplore this in the Programme Explorer
Let’s talk about your programme.
Perhaps you are facing a difficult engineering challenge, trying to improve how development work comes together, or dealing with an issue that keeps slowing the programme down.
You can bring me into a specific programme topic, or we can start by looking at the situation together, understanding what is getting in the way and working out a useful next step.