Case Study 1: The Engineer Who Learned to Write

A composite, fictional-but-realistic case. "Tomás" is not a real individual; his story is assembled from the common arc of technical professionals whose careers turned on communication. The pattern is real even though the person is invented.

Tomás Okonkwo was, by any technical measure, the strongest engineer on his team. He shipped clean code, found root causes others missed, and could hold a gnarly distributed system in his head. At his two-year review, his manager told him so — and then told him he wasn't getting promoted to senior.

The reason stung because it had nothing to do with his code. "Your design docs," his manager said, "don't land. People come out of your reviews more confused than they went in. Last month the platform team built the wrong thing for three weeks because they thought your proposal meant something it didn't." Tomás had written the proposal. He had been sure it was clear. He understood the design completely — he just, in his own words, "wasn't a writer."

What was actually happening

Tomás was living inside the transcription model. He believed the design was finished in his head, and that writing it up was a clerical afterthought he happened to be bad at — a cosmetic weakness, separate from his real competence. So he rushed it. His docs were walls of text that opened with implementation detail and never stated, in one plain sentence, what he was proposing or why. The conclusion — what should we build, and what should you do about it — was either buried on page four or never written at all, because writing it would have forced him to decide things he'd left comfortably vague.

The three-week mistake was the tell. The platform team didn't misread a clear document. They filled the gaps in an unclear one with their own guesses, and guessed wrong. The information was technically present in Tomás's doc and functionally absent from the version that reached their heads. He had been right and uncommunicated, which on a team is indistinguishable from being wrong.

What he changed

A skeptic to the end, Tomás didn't take a writing course. He adopted exactly one habit, almost as an experiment: before writing any design doc, he forced himself to write a single sentence stating what he was proposing and why — and he would not start the doc until that sentence was true and clear.

The first time he tried it, he couldn't do it. He sat for twenty minutes unable to write the sentence — and realized, with some discomfort, that he hadn't actually decided between two architectures. He'd been planning to "let the doc figure it out," which is to say he'd been planning to ship undecided thinking and let three teams sort out the ambiguity downstream. The blank sentence had caught what a year of confident whiteboarding hadn't. He went back, made the decision, and then the doc wrote itself in half the usual time, because he finally knew what he was saying.

Over the next six months the habit compounded. His docs now opened with the point. Reviewers stopped asking "wait, what are you actually proposing?" Meetings got shorter. The platform team started saying his proposals were the easy ones to build against. None of his technical ability had changed — he was the same engineer. What changed was that his thinking now reliably made it out of his head and into other people's, intact.

The outcome — and the real lesson

Tomás made senior at the next cycle. Two years after that, he was the person other engineers asked to review their design docs, and the de facto author of his org's technical-decision template. The thing that had capped his career — "not a writer" — became, once he stopped believing it was a fixed trait, the thing that accelerated it past peers who out-coded him.

The lesson isn't "learn to write to get promoted," though he did. It's subtler and it's the whole chapter: Tomás didn't just get better at communicating his designs. By forcing himself to write the one sentence, he got better at making them — because the writing exposed the decisions he'd been dodging. The promotion was a side effect. The real change was that he started finishing his thinking on the page instead of leaving it half-done in his head and hoping the reader would cover the gap.

Takeaway: The single highest-leverage writing habit in this entire book costs one sentence. Before you call any piece of technical thinking finished, write the plain sentence that states your conclusion. If you can't, you've found the work that's left — and you've found it before your reader does.