The Recommendation Problem: Why Engineers Bury Their Own Conclusions in Data
Engineers are trained to show their work. A conclusion without supporting calculations looks unfinished on paper, so the instinct in a presentation is to walk an audience through the analysis first and let the recommendation emerge naturally at the end. That instinct, reasonable as it is in a technical report, tends to backfire in a live meeting, where a client or a board loses the thread of the argument long before the recommendation ever arrives.
Where the Conclusion Actually Belongs
A presentation is not a proof. It doesn't need to derive its conclusion in front of the audience the way a report needs to justify one on paper. The recommendation can, and usually should, come in the first two minutes, stated plainly, followed by however much supporting detail the room actually wants. This runs against how most engineers were trained to structure technical writing, but a live audience processes information differently than a reader working through a document at their own pace.
What Gets Lost When the Order Is Reversed
When the analysis comes first and the conclusion comes last, an audience spends the whole meeting trying to guess where the engineer is headed. Some give up and stop paying close attention, waiting for the eventual answer. Others form their own guess partway through and stop listening for anything that might contradict it. Either way, the careful analysis that took weeks to produce ends up wasted, because it was delivered to a room that had already checked out or made up its mind before the point was reached.
The Discomfort of Stating a Recommendation Plainly
Part of the reluctance to lead with a conclusion is genuine caution. Engineering recommendations often carry real liability, and a flat statement feels riskier than a hedge buried in a wall of supporting data. But a recommendation delivered with appropriate qualifications, clearly and early, actually reads as more credible than one that only becomes visible after ten minutes of data the audience wasn't prepared to interpret. Confidence in the delivery and honesty about the limits of the analysis are not in tension with each other.
Matching Depth to the Room, Not the Report
The full technical report still needs to exist, with every assumption and calculation laid out for review. The presentation is a different document with a different job. A client who wants deeper justification for a recommendation will ask, and that's the moment to bring out the supporting slide, not before. Structuring a deck with the detailed analysis held in reserve, rather than displayed by default, lets the same presentation serve both a room that wants the short version and one that wants to dig in. This also means the deck itself needs a different internal structure than the report it's drawn from, with backup slides organized by likely question rather than by the order the calculations were originally performed.
A Habit Worth Unlearning
Because this ordering is close to the opposite of how engineers are taught to write, changing it takes deliberate practice, not just awareness. Reviewing old decks and asking where the recommendation actually appeared is a useful diagnostic. If it shows up on the second-to-last slide, that deck was built for a reader, not a room, and the next version deserves a different structure. Junior engineers in particular benefit from having a senior colleague sit in on a rehearsal specifically to flag this pattern, since it's difficult to notice in your own presentation without someone else watching for it.
The Bottom Line
An audience remembers the recommendation it heard, or the one it never got a clear read on. Leading with the conclusion, then supporting it with only as much data as the room asks for, tends to produce meetings where the engineer's actual judgment lands, rather than getting lost somewhere in the appendix of a very good analysis.
The PRESWERX Team
