#124 - Simplifying complexity!

24 Sep 26

I've watched senior people walk out of briefings before the Engineer got to the point. Not out of rudeness but simply to protect their programme. Time is precious for the people you most need to influence, and most Engineers have never been taught how to respect that.

Trial Brief

Being down in the detail is home territory for an Engineer. It's also exactly what a non-engineering line manager, a senior officer, a Government minister or a C-suite executive rarely has the appetite for. When the brief runs on for too long or is too detailed, you can watch the person receiving it shut down in real time. Once that happens, the substance of what you were trying to say is lost, however technically sound it was.

Trial Execution

I've seen this play out in more settings than I can count. Someone with a small, genuine window of opportunity to raise something important to a senior person wastes it on detail the audience never asked for and doesn't have time to absorb. The senior person doesn't stay just to be polite. They leave, because their own programme doesn't allow otherwise, and the issue that needed raising goes unraised.

The military are masters of briefing because operational necessity and urgency leave no room to be anything else. During my service in the Royal Navy I was taught a framework for exactly this situation, and I've used it since in diplomatic and commercial settings with the same result: it keeps you on track and keeps the listener with you. It's built around four elements, PEST.

Problem - what is the issue you need them to be aware of, stated plainly.

Effect - what is the impact? What could you do before that you can't do now?

Solution - what is your intended course of action? You never take a problem to your line manager without one; you take a problem with a solution attached.

Timeframe - how long until things are back to normal and the issue is resolved?

Trial Findings

What makes PEST work isn't that it compresses information. It's that it forces a decision about what actually matters before you open your mouth, rather than leaving the audience to sort the signal from the noise themselves in real time.

Most technical briefings fail not because the content is wrong, but because the structure asks the listener to do work they don't have the time or inclination to do: to sift through background information, to follow a technical chain of reasoning and to extract the actual ask themselves. Senior audiences, whoever they are, are almost always short on one resource above all others - time. A brief that doesn't respect that gets switched off long before it reaches the point.

PEST solves this by putting the decision-relevant information first and in a fixed order the listener can anticipate. Once someone recognises the pattern, they know a Problem is coming, then an Effect, then critically a Solution, then a Timeframe. They can track the whole thing without effort. The discipline of 'never take a problem without a solution' does double duty here. It forces the Engineer to think through the answer before the meeting rather than presenting an open question, and it signals to the senior person that they're being handed something actionable, not a problem being pushed up the chain for someone else to solve.

Einstein's line that everything should be made 'as simple as possible, but not simpler', is the right test for a PEST brief. None of this replaces detail entirely. If the person receiving the brief wants more, they'll ask for it, and that's exactly the moment to have supporting material ready in reserve. But leading with that detail, rather than having it available on request, is usually what costs Engineers the room before they've made their point.

The Common Thread

Complexity doesn't need to be abandoned to be communicated well. It needs to be structured for the audience receiving it, not the audience that already understands the technical background. PEST works because it respects the listener's time first and their curiosity second, rather than the other way round. In briefings with senior people, that ordering is very often what determines whether the message lands at all.

Trial Sign-off

One practical action

Before your next briefing to a senior, non-technical stakeholder, write out your point using Problem, Effect, Solution, Timeframe before you write anything else. Notice how much of your usual detail doesn't survive the cut, and keep it in reserve rather than the opening.

One question for reflection

Think of the last time a briefing of yours didn't land. Was it the technical content that was wrong, or the order in which you gave it?

Have a great week!

Steve

Find out where your next Engineering leadership development stage is here.

For short courses which target specific leadership issues, see this link.