In engineering, a solution alone is never sufficient; it must also be trusted.
Across the infrastructure engineering sector, teams are working on projects of genuine national significance. Cables are being laid beneath the North Sea to deliver clean electricity to millions of homes. Substations are being built to connect offshore wind to the national grid. Water infrastructure serves millions of households. Rail and highway projects carry communities every day. The technical capability underpinning this work is extraordinary.
Yet, in meeting rooms across the infrastructure sector, the quality of communication can easily undermine the quality of engineering. Clients leave progress meetings uncertain rather than confident. Stakeholder briefings generate more questions than reassurance. Tender presentations that should win on merit lose to competitors who simply tell a better story.
In almost every technical organisation, the gap that limits careers and causes contract losses is not one of engineering capability. It is a gap in communication. The problem is not the engineering. The problem is often the distance between what engineers know and what the room hears.
What follows is not about speaking technique. It is about a fundamental shift in how an engineering mind approaches a room, and it begins with recognising that the most important thing you bring to any presentation is not merely your technical knowledge. It is your ability to make that knowledge matter to those who need to act on it.
This is not an article about becoming a different kind of engineer. It is about five specific shifts in how you present, shifts that will change what happens in the room the next time you walk in.
Stop explaining the solution. Start communicating the problem it solves.
The engineering instinct when presenting is to start at the beginning: the brief, the methodology, the design process, the technical solution. It is logical, thorough, and almost always the wrong place to begin.
In a project review meeting, a client does not experience your work as a technical solution. They experience it as a problem that keeps them up at night, a risk to their programme, a threat to their budget, a commitment they made to their own board, and the relief of knowing it is in hand. The client doesn’t need to understand how you solved it before they feel that relief. They need to feel that relief before they can properly hear how you solved it.
That is what needs to cross the table, not the methodology, the programme, or the risk register. The confidence that the problem is solved and the project is in safe hands. Nothing in your slide deck creates that feeling; only you can.
The client doesn’t experience your project as a technical solution. They experience it as a problem they need to stop worrying about. The job in the room is to give them that confidence before you’ve shown a single drawing.
The practical shift is this: before any client meeting, stakeholder briefing, or project presentation, ask yourself one question. What problem has this person been carrying, and what does it mean for them that we have solved it? Not what the technical solution is, or what the programme is, but what changes for this person because of what your team has done?
That is your opening. Not the agenda, or the technical overview, but the thing that changes for them.
ENGINEERING EXAMPLE — CLIENT PROGRESS MEETING
“Good morning. Today, we’ll cover programme progress, design status, procurement updates, and we’ll finish with the risk register. If we can go to slide two…”
↓ the same meeting, opened differently
“I want to start with the most important thing: the programme risk you raised last quarter has been resolved. The design is complete, procurement is on track, and we are currently four days ahead of the critical path. Everything I’m about to take you through is evidence of that.”
The first version opens a folder. The second version closes an anxiety. Every word that follows now lands in a room that is listening rather than waiting. The agenda is identical, but the experience is entirely different.
THE SAME SHIFT — PRESENTING A PROJECT UPDATE TO SENIOR LEADERSHIP
“I’d like to walk you through where we are on the project, the current programme status, budget position, key risks, and upcoming milestones…”
↓
“The headline is this: we committed to delivering phase one by March, and we are on track to deliver it. What I want to show you today is why I’m confident in that, and the one decision we need from you to keep it that way.”
TRY THIS
→ Before your next client meeting, write one sentence: “The problem this person has been carrying is…” Open with that before anything else.
→ Replace your standard agenda opening with a headline statement of where the project stands. Give them the answer first. The detail is evidence, not argument.
→ Ask yourself: if this person left the room after my first two minutes, what would they believe? If the answer is “not much yet”, your opening needs rebuilding.
Know what your stakeholder needs to believe — not just what they need to know.
Engineers prepare presentations the way they prepare technical reports, by assembling the relevant information and presenting it in a logical order. It is a disciplined, rigorous approach. It is also the wrong approach for a non-technical audience. A technical report is read by someone who wants the detail. A presentation is delivered to someone who needs a reason to act, and those require different structures.
A National Grid project manager doesn’t need to understand how a 400kV Gas Insulated Switchgear substation is designed. They need to believe it will be delivered on time, safely, and to specification. A community liaison officer doesn’t need the engineering drawings. They need to believe their concerns have been heard and that the project team can be trusted. A board director doesn’t need the full risk register. They need to believe the risks are understood and managed by people who know what they are doing.
Belief is never built by information alone. It is built by the right story, told to the right person, at the right moment. The engineer who understands that walks into every room with an advantage that no specification document can provide.
A room full of informed people can still leave uncertain. A room full of people who believe you will leave ready to act. Those are not the same room.
ENGINEERING EXAMPLE — STAKEHOLDER BRIEFING
“Thank you for coming. Today we’ll be covering the technical scope of the works, the construction methodology, the programme timeline, environmental mitigation measures, and the traffic management plan…”
↓ the same briefing, reframed around what the community needs to believe
“We know this project affects your daily lives. Before we go into any details, I want to tell you the three things we are committed to: keeping disruption to the absolute minimum, ensuring you can always reach someone on this team directly, and doing what we say we will do. Everything else I’m about to share is evidence of those three commitments.”
The second version doesn’t skip the detail. It reframes why the detail matters. The community doesn’t need to understand cable installation methodology. They need to believe the team respects them. Establish that belief first, and the detail lands in a completely different room.
THE SAME SHIFT — PRESENTING A TENDER TO A NEW CLIENT
“We are a leading infrastructure engineering contractor with over 50 years of experience. Our capabilities span energy, water, transport and natural resources. Today we’d like to walk you through our technical approach, our programme, and our team…”
↓
“You have a project that needs to be right the first time. It is too important, too visible, and too consequential for anything less. What we want to leave you with today is one belief: that we are the team who will make that happen. Everything we are about to show you is evidence of that single idea.”
TRY THIS
→ Write the headline of your presentation before you write anything else. Not the agenda, the single conclusion you need the room to reach. If you cannot write it in one sentence, you are not yet clear enough on what you are trying to achieve.
→ Before you map your content, map your audience. A client, a regulator, a community group, and an internal board all need to believe different things. The same presentation cannot serve all four rooms equally well.
→ Before you finalise any presentation, ask yourself: does every element here earn its place, or am I including it because it makes me feel thorough? Thoroughness is a virtue in engineering. In a presentation room, it is often the enemy of impact.
If building presentations around belief rather than information is something you want to develop, the presentation skills training at Mindful Presenter covers exactly this: how to build a case that moves people, not just informs them.
Translate complexity into clarity — not away from it.
The instinct many engineers have when presenting to a non-technical room is to simplify. Strip out the technical language, avoid the detail, make it accessible. The intention is right. The execution is where it goes wrong.
Simplifying is not the same as clarifying. When an Engineering Manager removes the technical substance from a presentation to make it easier, the room does not feel reassured. It feels the absence of something, a vagueness where confidence should be. The depth is still there in the engineer’s head. It just never made it into the room.
The goal is not to make complex things simple; it is to make them clear, and clarity, in a non-technical room, almost always comes from the same place: human consequence. Not what the engineering involves, but what it means for the people who commissioned it, depend on it, or live near it.
An engineer who can hold the full technical complexity in their mind while speaking about what it means for the room is not dumbing anything down. They are doing something harder and rarer, translating expertise into understanding without losing an ounce of the credibility that expertise earns.
Don’t make it simple. Make it matter. The non-technical room doesn’t need to understand how it works. They need to understand what it means.
The real skill is not stripping out complexity. It is making complexity clear. Not removing the technical detail, but connecting it to something the non-technical room already cares about. The difference between ‘we are installing 47 kilometres of 400kV underground cable’ and ‘we are building the infrastructure that will power 800,000 homes, and the reason it has to be underground is that it runs beneath one of the most densely populated corridors in the country’ is not one of technical depth. It is one of human clarity. Both sentences carry the same complexity, but only one of them lands.
ENGINEERING EXAMPLE — EXPLAINING TECHNICAL SCOPE TO A CLIENT BOARD
“The works involve the design, procurement and construction of a new 400kV GIS substation, modification of the existing overhead line, installation of two new 275kV connections, and associated civil, electrical and instrumentation works across the site.”
↓ same scope, translated into consequence
“What we are building is the connection point between Scotland’s offshore wind and England’s national grid. When this substation is energised, clean electricity that doesn’t currently reach southern England will start flowing. The technical complexity of what’s required to make that happen is significant, and it’s exactly what this team is built for.”
The first version describes what is being built. The second version explains why it matters and signals that technical complexity is a source of confidence, not confusion. That is the difference between a room that follows politely and a room that leans forward.
THE SAME SHIFT — EXPLAINING A TECHNICAL DELAY TO A CLIENT
“The delay to the programme is due to unforeseen ground conditions encountered during the preliminary excavation works, requiring a revised geotechnical assessment and redesign of the temporary works solution.”
↓
“We found something underground that wasn’t in the surveys. It would have been easy to push on and deal with it later, but that would have created a much larger problem at a much more critical point in the programme. We stopped, we redesigned, and we are now back on track. That decision cost us two weeks. It saved us potentially three months.”
TRY THIS
→ For every technical statement in your presentation, ask: so what does that mean for the person in this room? Write that answer down. That is what you say instead.
→ Find the human consequence of your most complex technical element. Not the simplified version, the consequential version. What does it enable? What does it protectm and what would happen without it?
→ When you need to reference technical detail, lead with the consequence and follow with the complexity: “This will power 800,000 homes, and here is what it takes to make that happen.” Never the other way around.
Let data prove the point. Never let it make it.
Engineers are comfortable with data. More than comfortable, they trust it, lead with it, and often believe that if the data is strong enough, it should be sufficient to convince any audience. This belief is one of the most consistent sources of presentation failure in technical organisations.
Data does not persuade; it confirms. This difference is crucial. When you start with data, showing a slide filled with numbers, percentages, metrics, and risk scores, you’re asking your audience to interpret raw evidence to form a belief. Most non-technical audiences find this difficult, and the effort involved causes them to tune out as they attempt to process the information.
The shift is to lead with the point, the claim, the conclusion, the belief you need the room to hold, and then use the data as proof. Not as the argument itself, but as the evidence that earns the argument. Every data point should have a job: to confirm something you have already made the room believe, not to persuade them of something they haven’t yet felt.
ENGINEERING EXAMPLE — PROJECT PERFORMANCE REVIEW
“If we look at slide four, you can see that our SPI is currently 1.04, our CPI is 1.01, we have closed 73% of open actions from the last review, and our safety leading indicators show a LTIFR of 0.0 for the past 90 days.”
↓ same data, led by the point
“This project is performing. We are ahead of programme, within budget, and have had zero lost-time injuries in the past three months. I want to show you the numbers behind each of those statements, and then I want to tell you the one area where we are watching closely.”
The first version asks the room to form a view from metrics. The second version gives them the view first and uses the metrics to confirm it. Data in service of a point is powerful. Data, instead of a point, is noise.
THE SAME SHIFT — QUARTERLY BUSINESS UPDATE
“Revenue is at £42.3m against a target of £40.1m, margin is tracking at 4.2% against a plan of 3.8%, and we have secured £18m of new work in the period against a pipeline target of £15m.”
↓
“This has been our strongest quarter in three years on revenue, margin, and new work secured. The numbers are better than planned across every measure. What I want to talk about is why, and what we need to do to make sure it continues.”
TRY THIS
→ Before any presentation, write your conclusion at the top of a blank page. That is your opening statement. Everything else, including your data, exists to support it.
→ For every data slide, ask: what is the one thing I want the room to believe because of this data? Say that thing out loud before you show the slide. Then show the slide as proof.
→ Cut any data that does not directly support the belief you are trying to create. If it is interesting but not persuasive, move it to an appendix. The room will ask for it if they want it.
If structuring presentations around clear, belief-led arguments is something you want to develop, the presentation skills training at Mindful Presenter is built around exactly that discipline.
Your credibility comes from clarity, not complexity.
There is a deeply held belief in technical organisations that complexity signals expertise. That if you speak in the language of the discipline, if you reference the right standards, use the correct terminology, and demonstrate that you understand the full technical depth of the problem, the room will trust you.
In a room of fellow engineers, this is true. In every other room, it is precisely backwards.
When a Principal Engineer presents to a non-technical client in language the client cannot follow, the client does not think, “This person is an expert.” They think I don’t understand what is happening on my project. That feeling of being excluded from understanding rather than included in confidence is one of the most corrosive things that can happen in a client relationship. It happens not because the engineer lacks expertise, but because they have confused the demonstration of expertise with its communication.
Genuine credibility in a non-technical room comes down to one thing: the calm, clear ability to make complex matters feel understood. Not simplified, understood. When an Engineering Manager can walk a board through a technically complex situation and leave the board feeling confident rather than confused, that is not a communication skill separate from engineering expertise. It is the highest expression of that expertise.
In a room of engineers, complexity signals mastery. In every other room, clarity does. The expert who can do both is the one the room remembers.
ENGINEERING EXAMPLE — EXPLAINING A TECHNICAL RISK TO A CLIENT
“The risk relates to potential interference between the new 400kV GIS installation and the existing protection and control systems at the substation, which may require additional testing under the relevant NGET Technical Specifications and could impact the IEC 61850 communication architecture.”
↓ same risk, communicated with clarity
“There is a risk we are managing carefully. The new equipment needs to communicate correctly with the existing systems on site, and until we have completed the testing, we cannot be certain it will do so without modification. We have a plan, the right people on it, and we will have a definitive answer within three weeks. I wanted you to know now rather than later.”
The first version demonstrates technical knowledge. The second version demonstrates something rarer and more valuable in that room: the judgment to know what the client needs to hear, the honesty to say it clearly, and the confidence to say it without hiding behind technical language. That is what trust is built on.
THE SAME SHIFT — PRESENTING TO A SAFETY REGULATOR
“Our SHEQ management system is aligned with ISO 45001, and our CDM compliance framework ensures all Principal Designer and Principal Contractor duties are discharged in accordance with the Construction Design and Management Regulations 2015.”
↓
“Safety is not a compliance exercise for this team. It is the first conversation we have on every project and the last thing we check before anyone goes home. I can show you our systems and our records, but what I want you to understand first is the culture that sits behind them.”
TRY THIS
→ Before any presentation to a non-technical room, identify every piece of technical language in your notes. For each one, ask: Does this help the room feel confident, or does it help me feel credible? If it is the latter, replace it.
→ Find a colleague outside your discipline and present your opening three minutes to them. Ask one question afterwards: Do you feel more confident or more confused? Their answer is your answer.
→ Practise explaining your most complex current project in two minutes to someone with no background in engineering. Not simplified, consequential. What is it for? What does it enable? Why does it matter? If you can do that, you can do it in any room.
Presence and credibility in a room are skills that can be learned and practised regardless of technical background. The public speaking courses at Mindful Presenter are built around exactly that idea.
The expertise is not the problem. It never was. What holds most engineers back in a room is not a lack of knowledge; it is the habit of leading with it before the room is ready to receive it.
Put the consequence before the process, and build belief before you build the case. Make complexity clear rather than simple, and let data confirm what you have already made the room feel. When you have said the most important thing, stop.
Do those five things, and the room changes. The client stops managing you and starts trusting you. The stakeholder stops questioning and starts believing. The board stops processing your data and starts acting on your judgment.
The gap between what you know and what the room hears is not a technical problem. It is a human one. and human problems, unlike engineering ones, rarely need more data. They need someone willing to speak plainly about what matters.
If you would like to develop these skills further, whether for a specific presentation, a client relationship you want to strengthen, or a career step that requires you to command rooms you haven’t commanded before, one-to-one public speaking coaching with Mindful Presenter might be exactly the place to start.
If this piece changed how you think about the next time you walk into a client room, pass it to a colleague who has a major presentation coming up. The engineer who reads this today and applies one idea tomorrow will walk into that room differently. That is the point.
Image courtesy of Canva.com
ABOUT THE AUTHOR
Maurice DeCastro
Maurice DeCastro is the Founder and Director of Mindful Presenter Ltd and the creator of the Mindful Presenter Method™. With more than 30 years’ experience in organisational leadership and communication, he has helped thousands of professionals, including engineers, project managers, and technical leaders, speak with clarity, calm authority and meaningful connection. Before founding Mindful Presenter, Maurice served as Commercial Director at Interflora and Regional General Manager at Direct Line Group. He is currently writing a book on the art of professional communication.
