Explaining to Different Audiences

The most common failure in technical communication is a technically correct explanation aimed at the wrong person.

Match the abstraction to the decision they own. An engineer joining your team needs interfaces and invariants. A product manager needs what it enables and what it costs in time. An executive needs risk, money, and timeline. Support needs what breaks and what to tell users. Same system, four different true explanations — and giving the PM the engineer's version is not thoroughness, it is a failure to translate.

Lead with the consequence. "This migration will take three weeks and freezes schema changes during it" earns the attention that a description of the migration mechanism does not. People decide whether to keep listening based on your first sentence.

Analogies buy comprehension and cost precision. They are excellent for building a first mental model and dangerous when the listener extends them past the point where they hold. Say where the analogy breaks: "it's like a queue at a shop, except the queue can duplicate people."

Jargon is a shortcut only between people who share it. Inside your team, "we'll denormalise the read path" is efficient and clear. Outside it, the same phrase transfers nothing while signalling that you have not thought about your listener.

Check, don't assume. "Does that level of detail work, or would it help to go deeper?" costs five seconds and prevents the entire rest of the conversation from missing. In a remote meeting where you cannot read faces, this is close to mandatory.