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.

The Foundation

Looking back, I had two things going for me—one obvious and one not so obvious. The obvious thing was that I loved to write, and the University of Washington had a subcategory of its English degree that it called "English with a Writing Emphasis." Basically, it meant that I had to focus on two writing styles. I opted for poetry and expository writing. That spoke to me. I was even known for writing my essays in poetry form, because I found it amusing.

The non-obvious advantage? All of my friends were computer science majors. I didn't realize this was valuable at the time, but it taught me that code wasn't anything magical. It was challenging, sure, and required training and practice to do well. But my friends who were computer science majors weren't geniuses—and I mean no offense by this. Coding, programming, software engineering—these are hard things, but they're things you can learn. I just hadn't spent the time they had learning them.

When I graduated college, though, I had a shiny English degree and no idea what I wanted to do with it. I fell into working in computer sales, which I was terrible at. I didn't like making people buy things. But I was pretty good at explaining how things worked, and that seemed valuable. Still, I had no idea what I actually wanted to do.

After that green pen conversation, I went back to UW and took their Certificate in Technical Writing Course. I lucked out a little—at the time I was in school, around the 1990s, tech companies were hiring all over the place. I ended up landing a job as a technical writer at a very small company.

Learning the Craft

That first job lasted until they shut down. Then I went to another small company, where I documented wireless access points and point-of-sale devices. Eventually I wanted to do more, so I found myself at a startup. That's where I cut my teeth on a whole lot of things. A few experiences stand out.

The startup had very little money. They couldn't even buy a copy of Word. So I learned about open source and XML and how to write transforms so that I could create PDFs and webhelp. I still have the book on XSL-FO that I used. I don't want to ever read it again, though.

I needed to learn more about how to write code. One of the founders of the company handed me a book on Perl. I think it was "Perl for Dummies" but I don't remember. I will never forget that he wasn't gatekeeping his knowledge. He wanted me to understand how to write code. I particularly remember that his goal was to help me learn how to create.

I also learned how to lead projects and think about documentation strategically, not just as isolated topics but as part of a larger system that needed to work together.

Unfortunately, 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, which is another tech adjacent role. My job was to create courseware on Architecture on AWS. This is where I got firsthand experience that users don't use products in isolation.

The course covered how to set up an AWS account, how to create EC2 instances, how to connect those instances to RDS or DynamoDB, how to set up load balancing—all of these different products and services that had to work together. In fact, they really didn't do much all by themselves, when you think about it! I also learned the importance of exploring on your own. I would build out my own networks, trying to set up a NAT server, and so on. To me Cloud Computing was such an amazing playground. And if you messed something up, you could just delete it and start over. Which I had to do a lot.

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.

I also learned how to develop systems for maintaining content. I put together programs to help localization efforts, for example. And I developed policies for deprecating content.

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.