You need to sign in or sign up before continuing.
Reflection — An Honest Take 8 min

Honest Take — Before You Begin

Honest Take — Module 9: Teaching Across the Technical/Non-Technical Divide #

This is the module where senior engineers earn their multiplier. The rooms where decisions get made are full of non-engineers, and the engineer who can speak in those rooms without condescension becomes the person whose engineering decisions actually get made. The engineer who can't gets routed around by people who can communicate, regardless of which one is the better engineer. This is unfair if you take "best engineering" as the goal. It is perfectly fair if you take "best decision in a room of mixed expertise" as the goal — and best-decision-in-a-mixed-room is what almost every senior engineering decision actually is.

The two failure modes look opposite and come from the same place. Condescension treats the audience as too dumb to handle the real picture; jargon-flooding treats the audience as obligated to handle your preferred level of abstraction. Both are forms of "the translation is your job, not mine." The skill of this module is taking the translation work as your job and doing it well enough that the audience leaves understanding what they need to understand, without ever being made to feel talked down to. Study Bartosz Ciechanowski most closely from the calibration set, because his technique is not "simplify" — it is radical patience: scaffolding from first principles, each concept built on the one before, nothing skipped and nothing falsified. Most engineering communication is impatient. The patience is the entire secret, and it is learnable.

For the executive form specifically, the working pattern the Pyramid Principle describes but doesn't quite spell out for engineers: lead with the answer. "We should choose X over Y. Here's why in three sentences. Here are the three reasons in detail if you want them. Here are the supporting facts below that." Most engineers do the exact opposite — long buildup, exhaustive survey of alternatives, recommendation buried in the conclusion — and then feel insulted when the executive reads only the first paragraph. The executive is doing the right thing. The pyramid is not about being shallow; it is about being structured so that whatever level of attention the reader brings, they get the right level of answer.

And a warning about the standard advice on analogies: a tired analogy is worse than none. The database-as-filing-cabinet explanation illuminated someone in 1985; today it either mis-extends or slides off entirely, while giving the false sense of comprehension. The test for any analogy is "is this doing work, or just signaling that I tried?" Pick ones your audience hasn't already absorbed dead.

Two last things worth naming plainly. First, engineers who do this translation work sometimes get accused of "dumbing down." The accusation is almost always wrong, and it tends to come from engineers who have never attempted the work and find it threatening when peers do it. There is genuine dumbing-down — explanations that are false in service of accessibility — and there is genuine translation, which preserves the truth at a different level of abstraction with the hand-waving honestly marked. Hannah Fry, Ciechanowski, and Patrick McKenzie are not dumbing down; they are doing the harder version of the work. Don't internalize the accusation.

Second: the hardest audience for this skill is not the executive. It is family — the people who love you, want to know what you do all day, and from whom every previous explanation has slid off because the prior-knowledge gap is enormous and the patience requirement is total. If you can explain your work to a parent or a sibling, concretely, with affection, without losing patience, you can do everything else in this module.

Conclusion #

The translation work is the senior engineer's multiplier, and it is work — refusing both condescension and jargon-flooding, doing the patient scaffolding, leading with the answer, retiring the dead analogies. Your audience is a system that does not share your internal types; design the public API instead of leaking the internal representation and blaming the client. The hardest integration test is family. Run it.

Predictions #

  • The first time an executive reads only the first paragraph of your carefully structured memo, you will feel insulted on the work's behalf. They are using the document correctly. Pyramid harder next time.
  • Within a month you will catch yourself saying "let me back up — what does X mean?" in a meeting before the non-technical attendee has to ask. That is the module working, and it will save the room ten minutes.
  • Ciechanowski will reset your sense of what is possible. You will spend an hour inside one of his posts and come out slightly humbled. Bring the patience back to your own writing rather than the humility.
  • You will write at least one analogy in your next explanation that you later realize was tired. Catch it, replace it, and keep the test question around permanently.
  • One specific non-technical colleague will start coming to you for explanations, then start sending other people to you. That is the multiplier becoming visible in real time, and it will precede any formal recognition by several months.
  • The answer-first form will bleed into all your internal writing. Mostly a net positive — but watch for the cases where the thinking-out-loud form was actually the appropriate one, because the pyramid can flatten genuine open questions into false conclusions.