Ask any engineering leader to name the strongest engineers they've worked with, and an uncomfortable pattern shows up: a disproportionate number of them are also good writers. That's not a coincidence and it's not because writing ability and engineering ability share some hidden gene. It's because clear writing is downstream of clear thinking, and the act of writing something down forces exactly the kind of thinking that produces good engineering decisions.
Writing forces the thinking that talking lets you skip
A design conversation in a meeting can survive a lot of hand-waving — someone nods along, the ambiguity never surfaces, and everyone leaves with a slightly different understanding of what was decided. A design document can't hide that ambiguity nearly as well. The moment you try to write "the service will handle retries," you're forced to specify how many, with what backoff, and what happens after they're exhausted, because a sentence that vague looks obviously incomplete on the page in a way it never did out loud. This is why engineers who write design docs before building tend to catch more design flaws before writing code — the writing is doing real design work, not just documenting a decision already made.
Writing is how influence scales past your calendar
A senior engineer can influence maybe a dozen people through conversation in a given week — the people in their meetings, their reviews, their hallway conversations. A well-written document read by two hundred people has done more organizational work in the same week than any number of one-on-one conversations could. This is the actual mechanism behind a lot of staff and principal-level impact: a strategy memo, a well-argued RFC, a postmortem that reframes how the org thinks about a class of failure — these are how one person's judgment reaches people who will never sit in a room with them.
The formats worth deliberately practicing
Design docs that state the problem, the constraints, and the trade-offs between real alternatives — not just the chosen solution — are read more carefully and survive scrutiny better than ones that present a single option as inevitable. Postmortems that trace a failure to its actual systemic cause, rather than stopping at "the engineer forgot to check X," produce fixes that prevent whole classes of future incidents instead of one specific recurrence. Onboarding docs and internal explainers that anticipate the reader's confusion before it happens are some of the most quietly high-leverage writing anyone can produce, because they save an accumulating amount of other people's time for as long as they stay accurate.
Getting better at it is a tractable, ordinary skill
Technical writing improves the same way code quality does: through feedback and revision, not talent. Ask a colleague you trust to read your next design doc specifically for where they got confused, not just whether they agree with the conclusion — confusion points are usually where the thinking, not just the prose, needs work. Read documents that worked, the ones that actually changed a decision or got widely cited afterward, and notice concretely what made them effective: how they front-loaded the problem, how they handled the counterargument to their own proposal, how they used structure to make a long document skimmable.
None of this requires becoming a stylist. The bar for effective technical writing is much lower than the bar for good prose — it's precision, honest treatment of trade-offs, and respect for the reader's time. Engineers who invest in that bar consistently find their ideas travel further than their peers', which is, in most organizations, functionally indistinguishable from influence.