Written Communication
as a Force Multiplier

Every day you write things. Slack messages. Pull request descriptions. Design docs. Status updates. Meeting notes. JIRA comments. Most engineers treat this writing like paperwork — something to get through so they can get back to the "real work."

That is the mistake.

Here is what actually happens to your writing. Your Slack message gets forwarded to someone you've never met. Your design doc gets read at 11pm by a VP deciding which projects to cut. Your status update gets copy-pasted into a leadership sync by your manager. Your PR description gets skimmed by an engineer six months from now trying to understand why the code does what it does.

Your writing is a clone of you that works while you sleep, attends meetings you're not invited to, and makes arguments on your behalf without you in the room. A weak clone loses those arguments. A strong clone wins them.

This chapter is about building strong clones.

Think about how you normally share an idea. You find the right person, schedule a meeting, explain the context, make your case, answer questions, and then — if you're lucky — they agree. That's one person convinced. One hour spent.

Now write a clear, well-structured doc. Share it. Now five people read it simultaneously. They forward it to three more. Someone reads it a month later when the topic comes back up. The doc answered questions you weren't there to answer. It built alignment while you were doing something else entirely.

This is leverage. A meeting scales linearly. A document scales like a web page.

Amazon famously banned PowerPoint in executive meetings and replaced them with six-page narrative memos. The reason wasn't a quirky cultural preference. It was a leverage calculation. A slide forces the presenter to be present to explain it. A memo speaks for itself. The discipline of writing a memo forces the author to think more clearly, and the act of reading it forces attendees to engage more deeply than they ever would with a deck.

You don't need to be at Amazon to apply this. Every time you default to a 30-minute call when a well-written paragraph would do, you are spending a dollar to do what a dime could handle.

Most engineers write design docs like they're writing for a compiler. They describe what the system will do. They enumerate the components. They list the APIs. They draw the boxes and arrows. Then they wonder why nobody reads it carefully, why feedback is shallow, and why stakeholders weren't "aligned" at the end.

The mistake is thinking the audience is the future implementation. The audience is the current human who needs to understand, trust, and approve what you're proposing.

A design doc has two jobs: think rigorously, and persuade clearly. If it only thinks rigorously but doesn't persuade, people won't trust it. If it only persuades but hasn't thought rigorously, it will fall apart under review.

Here is the structure that actually works:

Nobody tells you this in engineering school, but the weekly status update is one of the most politically important documents you write. Not because leadership hangs on every word, but because patterns accumulate.

Over weeks and months, your updates form an impression. The engineer who writes crisp, confident updates that match reality is seen as someone who has things under control. The engineer who is always vague, always running late, always discovering surprises — even if they're working just as hard — is seen as someone who doesn't have a handle on their work.

The difference is usually not the work. It's the framing.

The bad version is vague, passive, and uses fear-language ("longer than expected," "some issues"). The good version is specific, shows you understand the problem, shows you're solving it, and closes with a reaffirmed commitment. Same underlying situation. Completely different signal.

Here is the template in your head every time you write a status update:

Something broke. Your name is attached to it, or your team is. Now you have to write a post-mortem. Many engineers treat this as damage control — a document you write to show you're sorry and it won't happen again.

That framing is exactly wrong, and it produces bad documents.

The engineers who rise fastest in elite orgs treat a post-mortem as a leadership opportunity. The incident is already in the past. You can't undo it. What you CAN control is what the org takes away from it. A great post-mortem makes people think: "The system failed, but the humans handled it like professionals. I'd trust them with harder problems."

A bad post-mortem makes people think: "They still don't fully understand what happened."

Slack is the river of the modern engineering org. It flows constantly, everything is urgent, and most of it is forgotten in hours. This is fine. Slack is meant to be fast and ephemeral.

The mistake is using it for things that aren't fast and ephemeral — long analyses, complex proposals, important decisions, status on something that matters. When you do this, you're putting high-value content into a low-retention medium. It gets lost in the scroll. It doesn't get read at the right time by the right people. It generates reactive replies instead of thoughtful ones. It's not findable two weeks later when someone asks "what did we decide?"

The 5-bullet rule is a forcing function. If you need more than five bullets to explain something, the thing is complex enough to deserve a document — where it can be structured, linked, versioned, and found again.

Notice the Slack message in the "good" version still exists. Slack is how you announce the doc, create urgency, and route the right people to it. The doc is where the conversation happens.

Slack is the trailer. The doc is the movie.

You don't need to be a novelist. You don't need purple prose. Engineering writing has one standard: does the reader understand what you need them to understand, as quickly as possible, with no room for misinterpretation?

These six rules will get you there.

There is a side effect of writing clearly that most engineers don't anticipate: it makes you think better.

When you write a vague idea, the vagueness hides in the words. "We should improve the pipeline" sounds fine in your head. When you try to write it clearly — what pipeline, what specifically is wrong, what does "improve" mean, how would we measure it — the gaps become obvious. The act of writing is the act of finding the gaps in your own thinking.

This is why engineers who write a lot tend to think more clearly over time. Not because writing is magic — because the feedback loop is tight. You write an imprecise idea. You try to express it concisely. It falls apart. You think harder. You write it again. It holds together. You've sharpened the idea.

The engineers who don't write go through this process less often. Their ideas stay half-formed longer. They discover the gaps in a meeting instead of a draft — which is a much more expensive place to discover them.

The compounding part is this: every good document you write becomes a reference. Future engineers cite your RFCs. New teammates read your old design docs to understand the system. Your post-mortems become case studies in team retrospectives. Your status updates become the institutional memory when the team is audited.

The engineer who writes well doesn't just communicate better. They become the historical record of the team. And the historical record of the team is read by the people who decide who gets more responsibility.

Reading this chapter counts for nothing if nothing changes. Here are four things you can do this week that will immediately make you a better engineering communicator: