Technical Writing Is the Most Underrated Skill in Engineering

Hot take: I've watched more engineering careers get accelerated by a well-written design doc than by a genuinely clever piece of code, and almost no engineering org treats writing as a skill worth deliberately developing the way it treats, say, system design or a specific language. It gets filed under 'soft skills' and quietly deprioritized, which undersells exactly how much leverage it actually has.

Where the gap actually shows up

Two engineers on a team I worked with were roughly comparable in raw technical ability. One wrote design docs that any stakeholder could read in five minutes and understand the tradeoff being proposed. The other wrote technically accurate docs that required a thirty-minute synchronous walkthrough to actually land, every single time, because the writing buried the actual decision three paragraphs deep under implementation detail nobody asked for yet. Guess which one's proposals got approved faster, got referenced by other teams months later, and got that engineer invited into more cross-team decisions.

The code you write gets read by a compiler and a handful of reviewers. The doc you write about it gets read by everyone who has to decide whether to trust your judgment.

What actually separates clear technical writing from unclear

It's rarely about vocabulary or grammar. It's almost always about structure and ordering — leading with the decision and the tradeoff before the implementation detail, stating the actual recommendation instead of just the options, and ruthlessly cutting context the specific reader doesn't need instead of including everything that's true.

• Lead with the decision and the one-sentence reason, not the full history of how you got there — most readers need the conclusion before they'll invest in the reasoning.
• State an explicit recommendation, not just a neutral list of options — 'here are three approaches, I recommend B because X' moves faster than 'here are three approaches' and a silent expectation someone else picks.
• Cut anything the specific audience doesn't need to decide — an exec reading a design doc summary doesn't need the same implementation detail an implementing engineer does, and conflating the two audiences produces a doc that serves neither well.
• Get a genuinely unfamiliar reader to read a draft before shipping it — if they can't summarize the actual decision back to you in one sentence, the doc isn't done yet, regardless of how technically complete it is.

None of this is about being a better writer in some literary sense. It's a trainable, mechanical skill — structure, ordering, audience-awareness — and most engineers never get deliberate feedback on it because it's treated as an innate trait instead of a practice. The engineers who do treat it as a practice end up with outsized influence relative to their raw technical output, not because writing is more important than code, but because writing is how everyone else finds out the code was good.