Chapter 3: A Personal Reckoning

When I joined Google, it was as a Technical Writer. This title was, on paper, a step down (level-wise) from previous roles. So, after about a year, I did what most of us would do: try for promotion. I worked with my manager to put together my justification—what we called a ‘promotion packet’—a comprehensive document listing my accomplishments, links to content I created, and testimonials from colleagues. Then I waited.

I didn’t get the promotion.

That stung, but it’s hardly unusual. Most people don’t get promoted their first time through. I listened to the feedback, put together an action plan with my manager, and prepared to try again six months later.

I was declined again.

This time, it hurt worse. Not just because I had done what I thought the committee had asked, but because of the reason they gave me: “We have concerns about his writing quality.”

I would like to say that I handled this feedback well. But I didn’t. I spent a good half year being angry and upset. (Don’t do that, by the way. It neither helps you nor those around you.)

When I finally moved into more of a growth mindset, I made a decision. If my writing wasn’t of high enough quality, then I was going to fix that. And to fix that, I needed information. Specifically, I needed to know: How did we define content quality?

The Search for Standards

I thought I would find an easy answer. After all, I was at Google, a company that prided itself on making data-driven decisions. We had all sorts of mechanisms for measuring code quality—tests, style guides, coding standards. But technical writing had nothing equivalent. No way of determining if a conceptual topic actually explained its concepts, or if a how-to guide actually helped a user perform a task. We had page analytics and feedback widgets, but those told you what people did, not whether the content was good. We knew some documentation was better than others, but we couldn’t articulate why.

And that’s a real problem. It’s one reason why product teams so often underappreciate what technical writers do. If you can’t measure something, it’s easy to treat it as an afterthought. Every technical writer I know has experienced some variation of the following conversation:

Product team: “We need docs!”

Technical Writer: “Sure! When?”

Product team: “We shipped yesterday!”

An Attempt at a Solution

A part of me thinks: “Who am I to determine what content quality is?” The best answer I can give you is: “I’m no more and no less qualified than anyone else who has spent their career writing technical content. But I know we have to do better than a definition that amounts to ‘we know it when we see it.’” My promotion experience had forced me to think systematically about what makes writing work, and I’d seen firsthand how the absence of clear criteria hurt writers, our teams, and our customers. The status quo isn’t good enough.

The rest of this book is my attempt to fix that. You might read my words and agree. And you might read them and think I’m full of it. That’s not the point. If you read the rest of this book and come away just thinking about what content quality means, and understanding why it’s important, I’ve done what I set out to do.

So let’s get to it.