Communicating With Non-Engineers
Demos as the primary language, the three-sentence executive readout, and how to say no without losing the room.
The audience map
In a single customer engagement, an FDE typically talks to four kinds of audience, each of which requires a different register. The executive sponsor cares about whether this project still makes their decision look good; they want one slide, the headline number, and a confidence level. The middle-manager owner cares about adoption and risk; they want to know what's working, what's blocked, and which of their fears were unfounded. The end user cares about whether their day got worse; they want concrete walkthroughs and the chance to complain. And the customer's technical counterpart cares about whether your work is sound; they want to see the code, the design tradeoffs, the things you got wrong. Using the same update for all four is the most common communication failure in FDE work, and it leaves everyone slightly unsatisfied.
Demos beat decks, and Palantir built a culture around it
Whenever a choice exists between showing and telling, show. A working demo, even a flawed one, transmits more information in two minutes than a thirty-slide deck does in an hour, and it does something a deck cannot: it lets the audience react to the thing itself rather than to your description of it. The reactions you get during a demo, the question someone interrupts to ask, the thing they laugh at, the moment they look away, are research data you cannot get any other way. Akshay Krishnaswamy's TBPN framing of FDE work, 'the entire product development process runs front-to-back from the field, not from a privileged engineering core,' is the same point at the organizational level. Demos beat decks because the field beats the conference room. Decks are useful as the artifact left behind, not as the conversation. A good FDE update meeting is a five-minute live demo, a five-minute discussion of what they noticed, and a one-page document sent afterward summarizing decisions.
The executive readout in three sentences
Senior people are not avoiding detail because they don't understand it; they're avoiding it because their job is to make decisions across a portfolio of projects and they have ten minutes per project. Respect that constraint. A useful executive readout is three sentences: where we are, what changed since last time, what decision (if any) is needed from them. Anything else is appendix. If you write the readout and find yourself unable to compress to three sentences, that's usually a sign that you don't yet have a clear story about the project; keep working on the story, not on the readout. The clearest indicator of FDE seniority is the ability to summarize a complex engagement in this format without it being misleading.
Saying no without losing the room
FDE engagements generate requests faster than they can be met, and many of those requests are wrong: the wrong feature, the wrong direction, the wrong sequence. Saying no is unavoidable. The technique is to never say no without a substitute. 'We can't do X by Friday' lands badly; 'We can't do X by Friday, but we can do Y by Friday which addresses the same underlying concern, or we can do X by the following Friday, your call' lands well. The substitute does two things: it shows you understood the request well enough to find an alternative, and it transfers the choice back to them. People accept 'no' easily when they're given an agency-preserving substitute. They reject 'no' when it sounds like a verdict.
The political register
Most FDE work runs through political terrain you can't see. The manager you're working with may be in a quiet feud with another team. The exec sponsor may be losing budget battles internally. The end users may be afraid you're going to automate their jobs. None of this is visible from the engineering work, and all of it shapes what you should and shouldn't say in any given room. The practical rule is: never volunteer information that could be weaponized in a fight you don't understand. Specifically, don't pre-announce features to one team before the other knows, don't share rough numbers with executives before they're sanity-checked, and don't agree out loud to timelines you haven't validated with the people who'd have to deliver them. Being technically correct in the wrong room is one of the few ways an FDE can torpedo an otherwise-successful engagement.
Key takeaways
- •Four audiences (executive, manager, user, technical counterpart) need four different registers. One update for all of them fails everyone.
- •Demos beat decks. A flawed demo transmits more than a polished deck. Krishnaswamy's 'front-to-back from the field' framing is the same point at the org level.
- •Executive readouts are three sentences: where we are, what changed, what decision is needed. If you can't compress, you don't yet have a story.
- •Never say no without a substitute. The substitute transfers the choice back to them and preserves their agency.
- •Most FDE work runs through invisible politics. Don't volunteer information that could be weaponized in fights you don't understand.
Exercise
Take a project you're currently working on. Write the three-sentence executive readout. Then write the same project as a demo script: what would you click through, in what order, and what's the single moment of recognition you're aiming for? Where do the two artifacts disagree about what matters? That gap is information.
Self-check
- 1.Why does the same update fail when sent to all four audiences?
- 2.Connect Krishnaswamy's 'front-to-back from the field' framing to why demos beat decks in customer engagements.
- 3.What two things does providing a substitute do that a flat 'no' doesn't?
- 4.What's an example of being 'technically correct in the wrong room,' and why is it harmful even when accurate?