For ten years I've written the words that help people use complicated products.
It started at General Motors, in technical training. I noticed I was good at writing the documentation that went with my team's training, and I liked doing it. A few years later I moved into technical authoring and found the same thing: I was quick, and I was good at the part a lot of writers struggle with, which is getting answers out of engineers and turning them into something a normal person can read. That's been the constant ever since. I'm back at GM now, which is a nice full circle.
Since then the work has taken a lot of shapes. Release notes that tell a driver what changed in their car overnight. A tooltip that keeps someone from giving up on a payment. An owner's-manual section that has to be exactly right because it's about a safety feature. It's different every time, but it comes down to taking something technical and making it clear.
The part I like most is the behind-the-scenes work: setting standards, building a process, keeping things consistent. At PayiQ I walked into a company with no documentation at all and built it from scratch, and at GM I did the same for the release-notes process. I actually like starting from a blank page.
A few things I believe
Start where there's no process
A lot of my work begins with nothing in place. I'm comfortable being the one who figures out how it should work, not just following someone else's system.
Write for the person reading it
Whoever's reading doesn't care how the system was built. My job is to describe things the way they'd actually think about them.
Get it right
Especially when the words live inside a car or a payment screen. I check everything against the source, whether that's the spec, an engineer, or the actual interface, before it goes out.
Where I've done it
Beyond the work
When I'm not working, I'm usually reading a novel or baking something. I spend a lot of my free time outside with my husband and our dog, Bravo.