Written and verbal communication

Most of your impact as an engineer travels through writing: Slack threads, status updates, design docs, PR descriptions, incident notes and the occasional slide deck. Code ships once; the message around the code is what gets decisions made, blockers cleared and credit assigned. Clear writing is how ownership becomes visible.

The core habit is simple and hard: put the bottom line first, write for someone who will skim, and match the depth to the reader.

Why this matters

Managers and staff engineers will forgive imperfect grammar. They will not forgive being surprised. SDE2s are trusted to send status and decisions before anyone chases them — updates with artifacts, risks named early, asks that are easy to answer (yes/no, pick A/B, approve N days).

In interviews, behavioral stories often turn on communication: a conflict resolved, a launch saved, a mistaken assumption caught because you wrote it down. Practice on real work. The brag document later will write itself.

Concepts in this section

Read them in order. Each one builds on the one before.

Step	Concept	What it answers
1	Bottom line up front	What does the first sentence owe the reader?
2	Writing for skimmers	How do you structure for a tired phone scan?
3	Status and decision updates	What slots does a status, incident or decision need?
4	Async etiquette	How do you ask in chat without wasting a round trip?
5	Audience altitude	Same facts — how high do you write?
6	Meetings and demos	How does a room end with a decision, owner and date?

A status that earns trust

Same facts; different signal. The weak version: "Still chipping away, hit snags, hoping to wrap soon." Nobody can help.

The strong version names status, artifacts, a number, a risk and a binary ask:

AT RISK for Friday. Vendor cap is 100 msg/s shared. Backfill at 50 msg/s is ~14 hours. Ask @morgan by Wed noon: (A) Friday with ~30% users on the old path for 48 hours, or (B) slip to Monday. Recommend A.

Five extra minutes of writing can save a meeting. That is the return.

Common mistakes

Mystery novel. Point arrives in paragraph four. BLUF; delete the warm-up.
Fake status. "Working on it" every week. Name artifacts, risks and dates.
Audience mismatch. Exec gets JDBC pool tuning. One-screen decision; link for depth.
Hello-only ping. Full ask in message one.
Decision amnesia. Chose X in Slack; paste it into the living doc the same day.

Key takeaways

Lead with the bottom line; support it after. Skimmers should get the point in two lines.
Use stable templates for status, incidents and decision requests.
Match altitude to audience: mechanism for engineers, impact for PMs, decision and ask for executives.
Meetings open with purpose and close with decisions, owners and dates.