Never Waste Confusion. Most Organizations Answer the Question and Discard the Diagnosis in the Same Motion.

August 25, 2026

Never Waste Confusion. Most Organizations Answer the Question and Discard the Diagnosis in the Same Motion.

A reader named John Cassel left three words in a comment on an article I wrote about new hires: never waste confusion. It compresses an entire diagnostic mechanism most organizations never build, and the frame reaches well past onboarding, into every support ticket, every abandoned form, every question a customer asks that the product should have already answered. I have been sitting with those three words since he wrote them.

The standard instinct, in onboarding and in support both, is to answer the question and move on. Efficient resolution is what gets tracked, speed of response is the metric that matters, and stopping to document every point of confusion looks like it would slow everything down without adding real value.

Here is what that instinct throws away. Each individual resolved confusion gets discarded the moment it is answered. The support agent closes the ticket, the onboarding buddy answers the question, and the actual content of what confused them, which specific assumption was wrong, which piece of documentation no longer matches reality, evaporates along with the resolution. No single instance looks worth capturing, and correctly so, because any one instance genuinely might just be noise. But because nothing gets captured at all, the organization never accumulates the volume needed to see the pattern that would distinguish real drift from a one-off. The same confusion can recur across dozens of new hires or hundreds of customers, each one individually resolved and individually discarded, and because nobody is looking at the aggregate, the organization never learns this is a recurring signal rather than isolated unfamiliarity. What looks like good customer service or smooth onboarding, quick, competent, friendly resolution, is actually the mechanism erasing the evidence in real time.

The cost compounds invisibly. The documentation keeps drifting further from reality, and the organization pays the resolution cost of the same underlying problem over and over, forever, instead of paying once to fix the actual drift at its source. Nobody notices, because every individual instance looks like a routine question handled well, which is exactly the problem.

The organizations that actually catch this share one trait: they have built the two things that make catching it possible at all, not a workforce that happens to care more about confusion when it occurs.

The discipline that actually works has two parts, and skipping either one leaves you back where most organizations already are. Capture cheaply and broadly at the moment of resolution: a low-friction way to log what confused someone, without asking anyone to judge in the moment whether it matters, because that judgment is exactly what nobody can make reliably case by case. Then build a systematized report, on a regular cadence, that surfaces which confusion is recurring across new hires or customers rather than isolated. The recurrence is the signal. Volume is what separates real drift from a one-off question, and volume only becomes visible if someone built the report that surfaces it on schedule, not if someone happens to notice a pattern by memory.

Pick one channel where confusion shows up in your organization right now, new hire onboarding questions, support tickets, sales objections. Is there a low-friction way to capture what confused someone without anyone having to judge in the moment whether it matters, and does a report on that captured data actually go out on a schedule, or does the data just evaporate the moment the question gets answered?

LeadershipOS™ has the full Persistence Layer discipline for making sure signal like this survives past the moment it gets resolved: http://TheLeadershipOSBook.com


I write about structural leadership for technical leaders in high-stakes operating environments. The full operating model is in LeadershipOS: http://TheLeadershipOSBook.com

Anthony S. Jackson

Anthony S. Jackson

Anthony S. Jackson has spent 30 years inside technical organizations. He is the author of the Architecture Protocol Series: three books on the structural problems technical leaders were never told they would face. He writes the LeadershipOS™ Inner Circle, a monthly printed newsletter for CTOs and engineering managers who design teams that hold under pressure.

LinkedIn logo icon
Back to Blog