Written Communication

Why This Matters for Engineering Leaders

You write more than you speak: Slack messages, emails, design docs, RFCs, status updates, performance reviews, project briefs, incident reports. Each piece of writing either builds or erodes your credibility. As a leader of 16 engineers, your writing scales your influence – a well-written RFC reaches the entire org; a poorly written one wastes everyone’s time.

The Amazon 6-Pager

Amazon’s meeting format: instead of PowerPoint, attendees read a 6-page narrative memo in silence at the start of every meeting. The document does the heavy lifting; the meeting is for discussion.

Why It Works

• Forces clarity of thought: You can’t hide fuzzy thinking behind bullet points and animations
• Levels the playing field: Introverts and non-native speakers get equal footing – the document speaks for them
• Creates a permanent record: Unlike slides, a memo can be forwarded, referenced, and refined
• Enables deep engagement: 20 minutes of silent reading produces better questions than 20 minutes of passive slide-watching

Structure of a 6-Pager

Section	Purpose	Length
Introduction / Context	What’s the situation? What does the reader need to know?	0.5 page
Problem Statement	What specific problem are we solving? Why now?	0.5 page
Tenets / Principles	What beliefs guide our approach? (optional but powerful)	0.25 page
Proposed Solution	What do we recommend and how does it work?	2-3 pages
Alternatives Considered	What else did we evaluate and why did we reject it?	0.5-1 page
Risks & Mitigations	What could go wrong and how will we handle it?	0.5 page
Ask / Next Steps	What decision do we need? What resources?	0.25 page

Writing Tips for 6-Pagers

• Write in complete sentences and paragraphs. No bullet points in the body (appendix is fine).
• Start with the customer. Frame the problem from the user’s perspective, not the engineering team’s.
• Include the “so what” early. Don’t make readers wait 4 pages for the recommendation.
• Use data, not adjectives. “Response time increased significantly” is weak. “P95 latency increased from 200ms to 1.4s over the last 30 days” is strong.
• Write for the skeptic. Anticipate objections and address them in the document.

Email Effectiveness

The BLUF Principle (Bottom Line Up Front)

Military communication principle adopted by effective business communicators. Put the conclusion, request, or decision in the first sentence.

Bad:

Hi team, as you know we’ve been working on the migration project for several months now and there have been some complications with the vendor timeline and some dependencies that we didn’t anticipate. After discussing with the stakeholders and reviewing the current progress…

Good:

We need to delay the migration launch by 2 weeks, from April 15 to April 29. Here’s why and what changes for each team.

Email Structure Template

Subject: [ACTION NEEDED] / [FYI] / [DECISION NEEDED] -- Clear topic

Line 1: The bottom line -- what you need from the reader
Line 2-3: The critical context (2-3 sentences max)

Details (if needed):
- Supporting point 1
- Supporting point 2

Next step: Who does what by when

Email Rules for Leaders

Rule	Rationale
Subject line = mini-headline	People triage by subject line. Make it scannable: “[DECISION] Platform choice for AI service”
One email = one topic	Mixing topics guarantees one gets missed
Name the recipients in the body	“Alice – can you review the API contract? Bob – please update the timeline.”
State the deadline explicitly	“I need your input by Thursday 5pm CET” not “when you get a chance”
Front-load the ask	Busy people read the first 2 lines. Put the action there
Reply inline for complex threads	When responding to multiple points, reply inline with a different color or prefix. Don’t make readers map your responses to their questions

RFC / Design Doc Writing

RFCs (Request for Comments) are how engineering decisions get made asynchronously at scale. A good RFC prevents months of wasted work; a bad one wastes weeks of review time.

RFC Template

# RFC: [Title]

**Author:** [Name]
**Status:** Draft / In Review / Approved / Superseded
**Reviewers:** [Names]
**Last Updated:** [Date]

## Summary
[2-3 sentences. What are you proposing and why?]

## Motivation
[Why is this needed? What problem does it solve? Include data.]

## Detailed Design
[The meat of the doc. Architecture diagrams, API contracts, 
data models, sequence diagrams. Be specific enough that 
another engineer could implement it.]

## Alternatives Considered
[What other approaches did you evaluate? Why were they rejected?
This section builds credibility -- it shows you thought broadly
before narrowing.]

## Risks and Open Questions
[What are you uncertain about? What could go wrong?
Being explicit about unknowns is a sign of maturity, not weakness.]

## Rollout Plan
[How will this be deployed? Feature flags? Gradual rollout?
Rollback plan?]

## Success Metrics
[How will we know this worked? Define measurable outcomes.]

What Makes an RFC Persuasive

1. The “Alternatives Considered” section is the most important. If it’s empty or has strawman alternatives, reviewers won’t trust your recommendation. Show that you genuinely evaluated other approaches.

2. Lead with the problem, not the solution. If people don’t agree the problem exists or matters, your solution is irrelevant.

3. Include a “non-goals” section. Explicitly state what this RFC does NOT try to solve. This prevents scope creep in reviews.

4. Diagrams beat prose for architecture. A sequence diagram or system diagram saves 500 words and is more precise.

5. Write for the reviewer who disagrees with you. Address their likely objections preemptively. This is the written equivalent of Crucial Conversations’ “anticipate resistance.”

Async Communication (Slack / Teams)

Slack Etiquette for Leaders

Practice	Why
Thread everything	Unthreaded messages in busy channels create noise that makes people mute the channel
Don’t say “Hi” and wait	Send the full message. “Hi” followed by silence is the async equivalent of tapping someone’s shoulder and staring at them
Use structured messages	Context -> Question -> Deadline. Not a stream of consciousness
Set status and availability	Model the behavior you want. Show that being offline is okay
Don’t DM what should be in a channel	If others might benefit from the answer, ask publicly. Knowledge hoarding kills teams
Batch your responses	Don’t be a Slack firefighter. Check 3-4 times per day, not every 5 minutes
Write complete thoughts	Reread before sending. If it needs 3 follow-up messages to clarify, it wasn’t ready

The Async Message Template

For any Slack message that needs action:

Context: [Why am I writing this? 1 sentence]
Request: [What do I need? Be specific]
Deadline: [By when?]
If no response: [What will I do? Default action]

Example:

Context: The staging environment has been flaky since the last infra change. Request: @platform-team – can someone investigate and share findings in #incident-log? Deadline: By EOD Wednesday If no response: I’ll escalate to the infra lead Thursday morning.

Writing Quality Checklist

Apply these to any written communication:

Clarity

• Could someone outside your team understand the main point?
• Is every sentence necessary? (If you can delete it without losing meaning, delete it)
• Are you using concrete nouns and active verbs? (“We will migrate the database” not “The database migration will be undertaken”)

Structure

• Does the first sentence tell the reader what this is about and what you need?
• Are paragraphs single-topic? (New topic = new paragraph)
• Do headings allow scanning? (A reader who only reads headings should get the gist)

Tone

• Does it sound like a human? (Not a corporate announcement)
• Have you removed hedging? (“I think maybe we should consider” -> “We should”)
• Is the tone appropriate for the audience? (Direct to your team, more structured to executives)

Completeness

• Is the ask explicit? (What + who + when)
• Have you anticipated the first question the reader will ask and answered it?
• Are all claims supported by data or examples?

Anti-Patterns

1. The Wall of Text

A Slack message or email that’s 15 lines with no structure. Break it up. Use paragraphs, headers, or bullet points. If it’s longer than 5 lines, it probably needs structure.

2. Passive Voice Everywhere

“It was decided that the project would be deprioritized.” By whom? Passive voice hides accountability. Use it only when the actor genuinely doesn’t matter.

3. Writing to Sound Smart

Jargon, acronyms, complex sentence structures. Clear writing uses simple words and short sentences. If a 10-year-old can’t understand your sentence structure (even if they can’t understand the domain), rewrite it.

4. No BLUF

Burying the lead in paragraph 4. Your reader may never get to paragraph 4. Put the most important information first, always.

5. Over-Engineering Slack Messages

Not every Slack message needs the full template. “Sure, sounds good” is a fine response. Save the structure for messages that need action or convey important information.

6. Premature Sending

Writing an emotional response and hitting send before editing. For any high-stakes written communication, write it, walk away for 30 minutes, then edit. The first draft serves you; the second draft serves the reader.

References

• Bezos, J. (2018). Annual Letter to Shareholders. – Contains his explanation of why Amazon uses 6-pagers instead of slides.
• Minto, B. (2009). The Pyramid Principle. Pearson. – The foundational framework for structured business writing.
• Williams, J. & Bizup, J. (2017). Style: Lessons in Clarity and Grace. Pearson. – The best book on sentence-level writing quality.
• Zinsser, W. (2006). On Writing Well. Harper Perennial. – Classic guide to nonfiction writing. Read chapters on simplicity and clutter.
• Larson, W. (2019). “Writing an Engineering Strategy.” https://lethain.com/eng-strategy/ – Practical advice on engineering-specific documents.
• Stripe. “RFC Template.” – Stripe’s internal RFC process has been widely cited as a model for engineering decision-making.
• Hilliger, H. (2020). “NoHello.” https://nohello.net – The case against empty “Hi” messages in async communication.