Let Engineers Engineer…
…and why that’s sometimes where we go wrong
I was in a seminar recently when someone said, almost as a throwaway line:
“We just need to let engineers engineer.”
It landed well. A lot of nods around the room. You could feel the agreement. (To be fair, it was a room full of engineers...)
It’s a phrase you hear everywhere, not just in engineering:
At its heart, it’s about respect. Respect for expertise, for training, for the depth of knowledge people bring to their roles. It’s often said in frustration too - usually when people feel that bureaucracy, governance, or “the corporate machine” is getting in the way of real work.
However, in almost every complex organisation I’ve worked in, the issue hasn’t been that people weren’t allowed to do their job.
It’s that everyone was doing their job… and the system still wasn’t working.
The appeal of the idea - and its hidden flaw
There’s a very real problem this phrase is trying to solve. In large organisations, particularly those operating in regulated or high-risk environments, layers of governance can build up quickly. Decision-making slows down, accountability gets blurred, and people closest to the work can feel disempowered. In that context, “let engineers engineer” becomes a rallying cry to strip things back and trust the people who know what they’re doing.
But the flaw in the idea is subtle. It assumes that value is created within functions - that if each discipline performs at its best, the organisation will perform at its best.
In reality, the opposite is often true.
Most of the performance issues I’ve seen don’t sit neatly within a single function. They exist between functions - in the gaps, the handovers, and the trade-offs that no one quite owns.
That’s where things start to unravel.
When optimisation becomes fragmentation
In technical and operational environments, each discipline is trained - quite rightly - to optimise for a particular outcome.
Engineers are taught to prioritise performance, safety, and technical integrity. Procurement teams are incentivised to reduce cost and manage commercial risk. Programme teams focus on timelines, governance, and delivery milestones. Finance brings a lens of control, predictability, and return.
Each of these perspectives is valid. In isolation, they represent good practice.
The problem is that organisations rarely operate in isolation.
When these functions are not aligned around a shared definition of value, what you get is not excellence - you get fragmentation. Likewise with the wrong structures or focus, you have the wrong ownership. Each part of the system becomes highly effective at achieving its own goals, but the collective outcome drifts away from what the organisation actually needs; and sometimes the decisions makers are not driven by the right outcomes or mindset.
I’ve seen procurement functions deliver impressive cost reductions on paper, only for engineering teams to spend months redesigning around lower-quality inputs. I’ve seen technically brilliant designs that meet every specification, but are almost impossible to manufacture at scale or maintain in the field, or assemblers using sub-par components that lead to rework and defects. I've seen plant designed for purchase cost, not through life operability. I’ve seen programme teams hitting every milestone, while the underlying product or service quietly fails to meet customer needs.
No one is underperforming in these situations. In fact, quite the opposite. The system is behaving exactly as it has been designed to behave.
The role of procurement and programmes - where tensions surface
The tension becomes particularly visible when you look at procurement and programme management, because these functions sit at the intersection of the technical and corporate worlds.
Procurement, in many organisations, is still measured primarily on its ability to reduce cost and enforce compliance. That creates a very specific behavioural pull. Decisions are made with a focus on price, contractual terms, and standardisation, often with the best of intentions around efficiency and control. But without a deep integration with engineering and operations, those decisions can have unintended consequences further downstream - increased failure rates, longer lead times, or higher lifecycle costs that dwarf the initial saving.
This is where the practices of Concurrent Engineering, Total Cost of Ownership and Cost Engineering should all compliment Procurement strategies to drive integrated solutions.
Programme management faces a similar challenge, but from a different angle. In theory, programme teams should be the integrators - the function that brings together engineering, procurement, operations, and leadership into a coherent delivery model. In practice, they often become translators instead. They spend their time converting technical complexity into status updates, reconciling conflicting priorities, and escalating issues that could have been avoided with better alignment earlier on.
Likewise, this is where Design for Manufacture / Maintenance are concepts that should support programmes beyond the normal scope of 'Go Live' focus.
The result of a system that doesn't consider these functional integrations are ones where decisions are made in silos, issues are discovered late, and programmes become reactive rather than proactive.
The deeper issue: separating thinking from doing
What sits underneath all of this is a structural issue that many organisations struggle to address.
We separate thinking from doing.
We create environments where decisions are made in one part of the organisation and executed in another, often with limited feedback loops between the two. Engineering designs in one context, procurement negotiates in another, and operations deals with the consequences in a third. Each step introduces interpretation, compromise, and sometimes distortion.
Over time, this separation creates distance - not just physically, but cognitively. People lose sight of how their decisions impact the wider system. Trade-offs become implicit rather than explicit. And accountability becomes diluted because no single function owns the end-to-end outcome.
This is why phrases like “let engineers engineer” can be misleading. They reinforce the idea that expertise should be protected within boundaries, rather than connected across them. The issues are when we don't balance the functional voices, or have metrics and organisational structures that skew focus.
What better looks like in practice
The organisations that manage to break this pattern don’t do it by reducing expertise or removing structure. They do it by reconnecting the system around outcomes.
One of the most powerful shifts is moving away from functional metrics towards shared, end-to-end measures of success. Instead of asking whether procurement has saved money or engineering has met specification, the question becomes whether the organisation has delivered value across the full lifecycle - cost, performance, reliability, and customer impact combined. This forces conversations about trade-offs to happen earlier and more transparently.
Another critical change is bringing the right people together at the point where decisions are made. Not in hindsight, not in governance forums, but in the design phase where the majority of cost, risk, and value is determined. When engineering, procurement, and operations collaborate in those moments, decisions tend to be more balanced, more informed, and ultimately more sustainable.
There’s also a capability shift required. High-performing organisations invest in developing people who can think beyond their functional lens. Engineers who understand commercial implications. Procurement professionals who appreciate technical constraints. Programme leaders who can facilitate real integration rather than just coordination. These are not easy skills to build, but they are increasingly essential.
And perhaps most importantly, there is a mindset shift. Procurement is no longer seen purely as a cost controller, but as a strategic partner in shaping supply ecosystems. Programme management is not just about tracking progress, but about creating the conditions for aligned decision-making. Engineering is not isolated from the business, but embedded within it.
A more complete way of thinking
So where does that leave the original statement?
“Let engineers engineer” isn’t wrong. It captures something important about trust and respect.
But it’s incomplete.
Because in complex, modern organisations, value is not created by individual functions operating at their best. It is created by how well those functions work together — how effectively they navigate trade-offs, share information, and align around a common goal.
A more complete version might be:
“Let engineers co-create outcomes with the system around them.”
That small shift changes the emphasis from protection to connection.
Why this matters now
If anything, this challenge is becoming more pronounced. Organisations are becoming more digital, more data-rich, and more interconnected. The potential for insight and optimisation has never been greater. But without integration, that potential often translates into noise - more dashboards, more metrics, more governance, but not necessarily better decisions.
The risk is that we become faster at doing the wrong things.
Which is why the ability to connect technical and corporate worlds is becoming a defining capability for leaders.
A simple reflection
If you wanted to test this in your own organisation, you could start with three questions:
The answers are usually quite revealing.
Final thought
In the end, this isn’t about engineers, procurement teams, or programme managers, it’s about how we design organisations to work.
Performance doesn’t come from protecting expertise within silos, it comes from connecting that expertise into a system that can think and act as one.