Chapter 2: My Journey

I never thought I’d become a technical writer. In fact, I didn’t even know the job existed when I graduated college. But my path to technical writing—and my passion for advocating for content quality—started with a green pen.

One day, I was at a friend’s apartment—a common gathering place for a whole host of different people—when another friend of theirs arrived with a stack of papers and a green pen. She sat down and began editing. I probably would have ignored it if I hadn’t noticed the unusual color choice.

“Why are you using a green pen?” I asked.

“I’m editing,” she explained. “And I don’t want the engineers who wrote this to feel like they’re back in high school. A red pen makes them feel like they just got a final exam back with the words ‘See me after class’ written on it.”

“What are you editing?”

“I’m a technical writer,” she said. “I’m editing some how-to topics.”

Our conversation continued as I peppered her with questions about being a technical writer. What did she do all day? How did she learn about the technical topics she wrote about? What was it like working with engineers? By the time I went home that day, I knew I had found what I wanted to do as a career.

Getting Started

I had two things going for me: I loved to write—I got my English degree from the University of Washington with a focus on poetry and expository writing—and all of my friends were computer science majors. I didn’t realize how valuable that second part was at the time, but it taught me that code wasn’t anything magical. It was challenging, sure, but it was something you could learn.

After that green pen conversation, I went back to UW and got my Certificate in Technical Writing. It was the 1990s, tech companies were hiring everywhere, and I landed my first job as a technical writer at a small company. From there I bounced through a couple of small shops and a startup, each one teaching me something new—how to build docs from nothing, how to think about documentation as a system, how to learn just enough code to be dangerous. Eventually, the startup didn’t quite make it. My next stop was F5 Networks.

Learning to Push Back

At F5, I owned the documentation for the Global Traffic Manager. I learned a lot here too, particularly how to really engage with subject matter experts. I’ll never forget handing some new content over to a very senior engineer. In those days, we still printed everything out! A day or so later, I got his feedback back. Across two pages he had drawn a red line and just a single word: “No.”

I remember being scared out of my mind—this was a pretty senior member of the team—but I had to go back to him and say, “That’s not good enough feedback. You wouldn’t accept a bug report that just said: ‘this is broken.’ Help me understand where I went wrong.”

And you know what? He did. He just wasn’t great at communicating his thoughts through writing. This taught me an important lesson that would serve me throughout my career: being an expert in one area doesn’t automatically make you an expert in another. Engineers need technical writers just as much as technical writers need engineers.

I also learned how important it was to meet with users and get a sense of what they were struggling with and what they needed to know. You can’t be a good technical writer or content creator and not engage with your users—and I stand by that statement.

Working with an Editor

When it was time to grow my career again, I found myself at Microsoft. And that was transformative.

At Microsoft I learned a lot, but probably the most important thing I learned was how to work with an editor. When I joined Microsoft, I was part of a very small team working on Windows Live. There was me, my manager, a couple of contract writers, and an editor. It was working with that editor that was so transformative.

At the time, the writing process was as follows: I would write the content and get subject matter expert approval. Then I would hand the content to the editor, who would edit for clarity and consistency and all the other things that make writing good writing and then publish it. Rarely would he come back to me with questions. But that meant that I wasn’t going to learn about flaws in my writing.

So I set up a weekly meeting with him so he could share where I could improve. Those meetings were invaluable. I learned a lot about how to consider localization, how to think about the broader content ecosystem as a whole, and so on. After some time, I remember him telling me: “I save your work for the end of my day. It’s like dessert, because you’ve already written things so well.”

To this day, that’s one of the highest compliments I’ve ever received in my career.

Understanding User Journeys

Amazon was another evolutionary leap. When I was first there—10+ years ago—cloud computing was new. I joined as a curriculum developer, creating courseware on AWS architecture. This is where I got firsthand experience that users don’t use products in isolation. Everything I was teaching—compute, storage, networking, databases—had to work together. None of it did much by itself.

There’s another piece that’s important. At Amazon, I honed my belief that you don’t need to be an expert to be a great communicator. And, in fact, being an expert can actually be a hindrance. I remember getting into a discussion with a colleague about this.

“We need experts,” he argued.

“No, we don’t,” I said. “We need people who are knowledgeable enough that they can write about what we want to share. But if we become experts, we cease to become user advocates. We forget what it’s like to be the novice. We have to be aware of that risk, all the time.”

I’m not sure I convinced him, but I convinced me.

Learning Strategy

When I got to Google, I again learned so much.

One of my first experiences was when I was writing about a SQL dialect that Google used for several of its services. I remember being in a meeting with the project lead and telling that lead that the way he wanted to talk about a feature wasn’t going to resonate with our users. After the meeting, a fellow writer took me aside.

“Do you know who that is?” they asked.

I was new to the company, so of course I didn’t know. “Not a clue,” I replied.

“He’s a distinguished engineer at Google!” they replied in hushed tones. If you’re not aware, distinguished engineer is one of the highest, if not THE highest, levels you can achieve.

“And you know what that means?” I said. “It means he’s not a technical writer. He needs me to be knowledgeable about what I do, so he can focus on what he does. Just because you’re a brilliant engineer doesn’t mean you’re a great writer. And just because I am a writer doesn’t mean I don’t know what I’m talking about.”

Another major experience at Google was when I was the lead writer for Angular. That was when I needed to learn about strategy. The Angular docs were, at that time, an untended garden. It was probably nice at one point, but it was now overgrown and difficult to sift through. I had to advocate for focusing more on strategy—cleaning up outdated docs, deleting unneeded content—instead of constantly chasing new features. I had to learn, again, how to deal with senior leadership who thought their programming expertise automatically made them writing experts. And I needed to do this as a collaborator, not as an adversary.

The Quest for Quality

There’s one more thing about my Google experience that I need to share. It was at Google that I got set on my quest to define and champion content quality. But it wasn’t a great experience.

I had gone up for promotion one year, and I was declined. That isn’t unusual. But the reason they declined really bothered me. I was told that they were concerned about my writing quality.

Imagine how that feels, as a writer, to be told your writing isn’t any good. I was absolutely devastated and more than a little angry. It took me months to get myself back together. When I finally did, I started asking: “What do we mean by content quality?” It turns out, as in Zen and the Art of Motorcycle Maintenance, folks knew quality when they saw it, but couldn’t articulate what quality writing was. So I started my own journey to find—at least for me—what quality writing was and how you could define it.

It’s funny, but since that moment, my time at Google, and then later Stripe, at startup, and then back at Amazon—where I am now—has all been about answering a question: “How do we define quality content, and how do we ensure that content helps our customers succeed?”

That green pen conversation started me on a career path I never expected. But that promotion feedback at Google started me on something more important: a quest to understand what makes content truly valuable. This book is the culmination of that quest—an attempt to give concrete shape to something we all recognize but struggle to define.