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. I can't rest during an info-gathering phase. The system fights you. 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. You have to get there anyway. And that, the fact that you know you can, provided that you dig hard enough, is part of the fun.
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 great. And synthesis is the epiphany that comes after the understanding of it all. When you do get there, when the model clicks, the whole structure becomes visible at once. It's a brief suspended moment until a new question arises. Sometimes, it leads you to question a design choice and influence a change. These are beautiful moments where your user-zero impersonation is the most rewarding.
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 be there at that moment, with exactly the right thing. 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. That part is fun too. It's an engineering problem of understanding transfer. Once the scaffold is up, the writing follows, connecting the dots, coloring within the lines if you will.
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.