Every developer has lived through this moment: you demo something you spent months building, something genuinely hard, and the room responds with polite nods and a question about the color of a button. The gap between what you built and what people understood is one of the most expensive problems in technology, and a recent analysis of why deep tech companies struggle to be understood captures the mechanics of that failure with unusual clarity. The short version: the harder the science, the harder the storytelling — and most technical teams treat storytelling as an afterthought rather than an engineering problem in its own right.
The Curse That Ships With Expertise
The root cause has a name in cognitive psychology. Once you know something deeply, you lose the ability to imagine not knowing it. Chip and Dan Heath documented this vividly in their classic piece on the curse of knowledge, describing an experiment where people tapped out famous songs on a table and predicted listeners would recognize half of them. The actual success rate was 2.5 percent. The tappers heard the melody in their heads; the listeners heard random knocking.
Now replace "tapping" with "explaining a photonics breakthrough to a procurement manager." The founder hears the full symphony — years of papers, failed prototypes, the elegant insight that finally worked. The buyer hears knocking. No amount of enthusiasm fixes this, because the problem isn't passion. It's that the speaker literally cannot reconstruct what it feels like to lack their context.
For developers, this matters far beyond deep tech startups. It's why your README makes perfect sense to you and confuses every new contributor. It's why your architecture proposal died in review while a weaker idea, explained better, got funded.
The Stakes Are Not Abstract
When communication fails at a deep tech company, the consequence isn't a bad meeting — it's a dead company. These ventures burn capital for years before revenue. According to BCG's research in an investor's guide to deep tech, more than 80 percent of deep tech ventures are building physical products, which stacks engineering risk on top of commercialization risk, with average investments now routinely reaching nine figures. An investor writing a $100 million check into a quantum computing or synthetic biology company cannot personally verify the science. They are, in a very real sense, buying the explanation.
That means the explanation is the product during fundraising. A team that can't compress five years of research into a narrative a generalist can evaluate will lose to a team with weaker technology and a clearer story. This feels unjust to engineers. It is also how the world works, and pretending otherwise is a strategy for running out of money.
Treating Communication Like Code
The good news: explaining hard things is a learnable skill with patterns, just like software. A few that consistently work for technical audiences trying to reach non-technical ones:
- Lead with the change in the world, not the mechanism. "Surgeons will see tumors invisible today" beats "we've improved near-infrared fluorescence imaging sensitivity by 40x." The mechanism earns trust later; the outcome earns attention now.
- Use one concrete scenario instead of three abstract benefits. A single named use case, walked through end to end, sticks. A slide of bullet points about "efficiency gains" evaporates.
- Quantify against something the listener already knows. "Our battery holds a phone charge for a week" needs no glossary. "380 Wh/kg energy density" needs one.
- Test your explanation on someone outside your field before it matters. If a smart friend from a different discipline can't repeat your pitch back to you, investors won't be able to either — they'll just be too polite to say so.
Documentation Is a Pitch, Too
Here's the part most relevant to working developers: every piece of technical writing you produce is a miniature version of this problem. API docs, pull request descriptions, incident postmortems, RFCs — each one is an attempt to transfer a mental model from a head that has it to a head that doesn't. The teams that do this well move faster, onboard faster, and win arguments they deserve to win.
A practical exercise: take the most complex system you own and write three explanations of it — one for a fellow senior engineer, one for a product manager, one for a customer. If the three documents are nearly identical, you haven't actually adapted anything; you've just pasted the same knocking sounds into three files.
The Uncomfortable Conclusion
Technical brilliance that cannot be explained might as well not exist, commercially speaking. The market doesn't reward what you built; it rewards what people understood about what you built. Deep tech founders learn this lesson at the most expensive tuition rates imaginable, but the lesson itself is universal. Clarity isn't marketing polish layered on top of engineering. It's the last mile of the engineering itself — and shipping without it means you never really shipped at all.
Top comments (0)