Blog
Posts on technical communication and content systems.
Coming soon...
While you are waiting, here are some thoughts
What happens before the writing
I've been trying to name what I love most about this work, and it might sound counterintuitive, certainly to the profession at large, but it's not the writing.
Not that I don't love crisp, well-structured content. I do. But writing is mostly the output, and models are good at it anyway. What I'm actually into is what happens before it.
There's a phase where you have to understand a new system from scratch. What it does, the problem it solves, how it works, how it gets used, by who, and in what context. You're collecting fragments from everywhere at once: meetings, docs, architecture blueprints, the codebase, the API surface... and you have to make real sense of it.
That phase is uncomfortable. Almost overwhelming. It's a puzzle you are constitutionally incapable of leaving unsolved. Engineers are busy, and you value their time. You're the generalist in a room full of specialists who've been living inside this problem for months, sometimes years. That gap is precisely where the thrill lives.
Here's another counterintuitive thing: I don't think you can write good hyper-technical content without going through this. Depth isn't really optional. Fragments without synthesis don't lead anywhere useful. And synthesis is the epiphany that comes after the understanding of it all. When you do get there, when the architectural elements all click, the whole structure becomes visible at once. It's a brief suspended moment. Sometimes, it leads you to question a design choice and influence a change. These are gratifying moments where your user-zero impersonation is the most rewarding.
Only then comes the writing. Or rather, the architecture of it first. For whom? Doing what? Because let's be honest: nobody reads the docs until they need to. So the job is to meet the reader at that very moment, with exactly the right information. You impersonate your reader. You think in structure and sequence, how to walk someone's understanding forward, one foothold at a time. You build the scaffold. It's an engineering problem of understanding transfer. Once the scaffold is up, the writing follows.
I get paid to go from not understanding to understanding, on hard things, over and over. Then I build the artifact that shortcuts that path for everyone who comes after.
So, in my opinion, a technical background helps enormously, more than I can overstate. It's what lets you own the understanding and architect its transfer. And that's the fun of the job.