What playing the flute has taught me about technical writing

A few years ago, my concert band was performing a hymn by Bach. I'd been leafing past it during my practise sessions, telling myself: Oh, Bach. No need to practise. It felt simple. Familiar. I had it.

The piece was Sleepers, Awake and I can tell you that, if anyone in the audience had nodded off, my confident A natural squawk took care of that.

The flutes were exposed in a quiet, delicate, part of the melody. And I played an A when it should have been an A flat. It was clear, obvious, and embarrassing. I caught the eye of my friend sitting next to me, also a flautist, and we both nearly collapsed trying not to laugh. I wobbled for a bar or two, then pulled myself together and kept going.

She has not let me forget about it. We're playing another Bach piece in our next concert, and she's already started.

I've been playing the flute since grade four. That's over thirty years, but who's counting! And when I became a technical writer, the last thing on my mind was how much those two lives would have in common. It turns out, quite a lot.

Reading the score

A musician's first job is to read the score accurately. Not to interpret it, not to perform it, just to understand exactly what's on the page. Every marking, every dynamic, every rest. Before you can play a piece, you have to know what the piece actually is.

A technical writer does the same thing before writing a single word. My "score" might be a product spec, a design prototype, a SME's explanation of a new feature, or all three at once. Reading them carefully is where the work really begins. The Bach mistake happened because I thought I already knew the piece. I'd stopped reading carefully. In documentation, that's when you end up writing confidently about how something works and getting it subtly, expensively wrong.

Translating for the audience

A score is written by a composer, but it's performed for an audience. The musician's job is to bridge that gap. We take what the composer intended and give it life for someone who may know nothing about music theory, who just wants to feel something.

This is, almost exactly, what technical writers do. A product is built by developers and designed by UX designers, but it's documented for users who can often be confused, in a hurry, and not interested in how the feature was implemented. They just want to know what to do next. My job is to anticipate where that confusion might show up before it happens, and answer the question the user hasn't managed to ask yet.

That skill doesn't come from domain expertise. It comes from practice — from spending years thinking about what it feels like to not know something, and learning to write for that person rather than for the people who built the thing.

Listening and adjusting mid-performance

One of the things I love most about playing in an ensemble is that you can't just play your part and tune everything else out. You have to listen to the people around you, to the shape of the piece as it's unfolding, and adjust constantly. Sometimes you realise mid-phrase that you've misjudged the tempo. You don't stop. You find your footing and you keep going.

Writing is like this too. I can't count the number of times I've been halfway through a draft and realized the structure isn't working. Maybe I've organised something around how the product is built rather than what the user actually needs to do. You can feel it before you can articulate it, the same way you can feel in a rehearsal that something is slightly off. When that happens, you have to stop and regroup before you go any further.

On AI, and the best accompanist I've ever had

I've been thinking a lot lately about how AI fits into all of this, and I keep coming back to the same metaphor: AI is an accompanist.

When a flautist performs with a piano accompaniment, the pianist isn't playing the flautist's part. The melody, the phrasing, the interpretation — that's all still the soloist's job. But a good accompanist changes what's possible. They fill in the harmony. They support you through the difficult passages. They free you up to focus on expression rather than holding everything together on your own. And if you don't know how to listen, adjust, and communicate with the accompanist, even the best pianist in the world won't help you.

That's what working with AI feels like to me. I'm still the one reading the score. I'm still the one thinking about the audience. I'm still the one who notices, mid-draft, that the structure is wrong. AI can help me move faster, fill in gaps, or try out a different approach, but only because I know what I'm listening for. A writer who doesn't have those skills won't get better output from AI. They'll just get confidently written content that misses the point.

And unlike my friend in the flute section, AI has never once teased me about a wrong note!

The Bach lesson

I think about that A flat more than I probably should. The moment I assumed I knew something well enough to stop paying attention, out came that confident but ugly A natural. In music and in technical writing, that assumption is where the mistakes live. The work that feels easiest can be the work that deserves the most care. And the skills that feel second nature, like reading carefully, thinking about your audience, staying flexible when something isn't working, are only second nature because you've practised them so many times you've stopped noticing you're doing it. Until, of course, you stop.