Working with people
Audience altitude
Same facts, different height. Mechanism for engineers, impact for PMs, decision and ask for executives.
The same facts need different altitudes. An engineer needs the mechanism so they can challenge it. A PM needs user impact and dates. An executive needs a decision and an ask on one screen. Sending the JDBC pool writeup to a director is not thoroughness; it is the wrong altitude.
Concept
Altitude is how far above the mechanism you write. High altitude is outcome, cost, risk and ask. Low altitude is interfaces, queries and flags. BLUF stays at every altitude: the first lines still carry the point.
The big idea
Think of a building cross-section. Executives see the roof line (will we launch Friday?). PMs see the floors (what users hit, what slips). Engineers see the pipes. Each view is true. Mixing them without a label wastes time.
The analogy breaks when the executive is the technical decision maker — a CTO may want the mechanism. Even then, start one screen high and link down.
Walking through it
| Audience | What they need | What to cut |
|---|---|---|
| Engineers on your team | Mechanism, trade-offs, links to code and metrics | Motivational fluff |
| Peer engineers elsewhere | Interface contracts, ownership, how it affects them | Internal ticket numbers without context |
| PMs and designers | User impact, scope options, dates, risks to the roadmap | Implementation digressions |
| Executives / directors | Decision, recommendation, cost, risk, ask — in one screen | Jargon, long history, open-ended brainstorming |
For executives, write as if they will only read five lines. Lead with the decision and the ask. One paragraph of why it matters in business terms. One short "options and recommendation." Offer an appendix or doc link. Many will not open it, and that is fine.
For PMs, translate technical risk into product risk: "If we skip the dual-write, rollback takes a day of data repair" beats "eventual consistency window." For engineers, the reverse: give the mechanism.
Trade-off
Over-explaining wastes senior time; under-explaining creates wrong decisions. Default: one-screen BLUF plus a link. Add depth when the reader asks or when the decision is irreversible.
Working with PMs and designers is this translation in both directions. Share options early. Do not surprise them in the sprint review with a constraint you knew last Tuesday.
Common mistakes
- One paste for every audience. The exec gets pool-tuning; the engineer gets a slogan.
- Jargon as a status test. If the reader cannot act, you wrote for yourself.
- Altitude with no ask. Even a perfect one-pager fails if nobody knows what you need from them.
Check yourself
- Rewrite "eventual consistency window" for a PM deciding whether to skip a dual-write.
"If we skip the dual-write, rollback takes a day of data repair."
- An executive has five lines. What belongs in them?
Decision, recommendation, cost, risk and the ask — plus a link for depth.
Key takeaways
- Match altitude to the reader: mechanism, impact or decision.
- Translate technical risk into product or business risk when the reader is not an engineer.
- Default to one screen plus a link; go deeper for irreversible bets.
Further learning
Next: meetings and demos.
Related
Bottom line up front
Put the decision, ask or outcome in the first sentence. Context comes after.
Written and verbal communication
Lead with the point, write for skimmers, and adjust depth for engineers, PMs and executives.
Working with product managers and designers
Product sense for engineers — shaping scope, trade-off conversations, feasibility spikes, and building the right thing with PMs and designers.