Why Effective Communication Requires the Same Rigor We Expect in Engineering Design
No engineer designs a pressure vessel from a list of tips. No structural engineer cantilevers a walkway off five best practices pulled from a blog post. Nobody builds an autonomous vehicle, or a rocket bound for Mars, by compiling advice. Every one of those problems gets a formal approach—codes, standards, validated methods—because the cost of guessing wrong is a failure nobody survives.
Ask that same engineer to present the pressure vessel design to the board that has to fund it, and the formal approach disappears. What replaces it is a tips list: five ways to nail your next presentation, three rules for talking to executives, whatever a search engine surfaces that week. The decision on the other side of that presentation can be just as consequential as the design itself. It rarely gets treated that way.
From the Real World
ISO 31000, the international standard for risk management, makes communication and consultation a core part of its risk management process, present at every stage. But the standard is explicit that it is generic by design, applicable to any organization in any domain, so the guidance amounts to this: communicate with your stakeholders and tailor it to your situation.
ISO 55001, the asset management system standard, gets slightly more specific: the organization must determine what it will communicate, when, with whom, and how. That is a checklist prompt, not a method. Compare either one to how the same bodies treat the technical work itself, with defined methods, validated tools, and years of accumulated guidance, and the gap is obvious. The standards that govern how rigorously technical professionals have to think say almost nothing about how rigorously they have to communicate what they found.
Gap 1: Technical Rigor vs. Communication Rigor
Technical work comes with a rulebook. Pressure vessels have the ASME code. Risk assessment has ISO/IEC 31010, the companion to ISO 31000 that catalogs dozens of techniques and explains when each one fits. Root cause analysis and lifecycle cost modeling have their own validated methods.
Communicating the results of that work has no rulebook. There is no 31010 for explaining a risk assessment to a board. The guidance defaults to broad directives such as “be clear and timely.” That is good advice. However, it is not a method.
Gap 2: Generic by Design
ISO management system standards are written to apply equally to a nuclear power plant, a bank, or a small municipal council. That is their strength. It is also why they say so little about communication.
The ISO 55001 checklist is not even specific to asset management. The communication clause in ISO 9001 (quality), ISO 14001 (environmental), ISO 45001 (safety), and ISO 55001 (asset management) is essentially the same paragraph: determine what to communicate, when, with whom, and how. The same words govern a hospital’s quality system and a utility’s asset management plan.
The standards tell us that communication must be managed. They do not tell us how to build an argument or explain complex technical risk to a decision maker who is not technical.
The Communication Standard That Is Missing
We have a formal approach and method for analyzing and designing anything physical when the consequences of failure are severe. Those consequences are also immediately visible.
That visibility is why the codes exist. On March 20, 1905, a boiler exploded at the Grover Shoe Factory in Brockton, Massachusetts, and killed 58 people. Massachusetts put boiler rules into law within two years. ASME published its first Boiler Code in 1915. The pressure vessel code was written in the aftermath of a disaster everyone could see.
The consequences of a communication failure show up later, as a project that never got funded, a board that stopped trusting the numbers, or a career that stalled for reasons nobody could precisely name. Nobody investigates. Nobody writes a code.
In many ways, whether we insist on a formal approach reflects how much a technical professional values hard skills versus soft skills. A failed weld leaves wreckage. A failed presentation leaves nothing to investigate, so we treat the skill as optional.
Communication Is a Piece of the Technical System
Reliability engineers know how a series system works. Every component has to work for the system to work, so the reliability of the system is the product of the reliabilities of its components. The system can never be more reliable than its weakest component.
Technical work that ends in a decision is a series system. The analysis and the design are components. So is the presentation to the decision makers. If the message doesn't get through, the decision won't reflect the analysis, no matter how good the analysis was.
Do the math. An analysis that is 99 percent reliable, followed by a presentation that gets the message through 60 percent of the time, produces a decision that is about 59 percent reliable. All the rigor upstream is capped by the least rigorous piece at the end.
No engineer would build one component of a series system to a technical standard and let the next one be assembled from a list of tips. Communication is a piece of the technical work. It deserves the same standard.
The FINESSE Approach
Technical professionals already know how to demand a formal approach and method when the consequences are high. We demand it for our analyses and designs.
FINESSE is one formal approach built for exactly this gap on the communication side. It has been used successfully for many years, and it is built on systems thinking.
FINESSE breaks communication into seven elements: Frame, Illustrate, Noise Reduction, Empathy, Structure, Synergy, and Ethics. The first three are about the data and information. The next three are about the audience. Ethics anchors the whole thing.
That is what makes it formal. It is repeatable from one presentation to the next, and a colleague can check a presentation against it the same way a peer checks a design calculation.
This is not a sales pitch for FINESSE. If it does not fit, find another approach and use it consistently. Just like analyzing and designing something technical, find the specific approach that works.
What should not survive is presenting the most consequential parts of technical work off a list of tips. We don’t learn as we go when designing a pressure vessel or a cantilevered structure.
Everything That Matters Requires an Approach
Nobody would sign off on a pressure vessel, a cantilevered structure, an autonomous vehicle, or a rocket to Mars built from a compilation of tips. It is laughable. Yet for high-stakes presentations related to big decisions—the kind that can make or break a career—technical professionals somehow consider a list of tips acceptable. It’s not. Communicate with FINESSE!
JD Solomon is the founder of JD Solomon, Inc., the creator of the FINESSE Fishbone Diagram®, and the co-creator of the SOAP criticality method©. He is the author of Communicating Reliability, Risk & Resiliency to Decision Makers: How to Get Your Boss’s Boss to Understand and Facilitating with FINESSE: A Guide to Successful Business Solutions.
.
Comments