Introduction: Who, What, and Why

First, the who, what, and why of this whole thing. I’m starting this blog because things are getting interesting, and in a way that I think might be interesting to other people. 

Where I’ve Been and What I’ve Done

I’ve been a technical writer for 18 years, and a documentation team manager for part of that. Since a fair chunk of that time has been as a lone writer, I’ve also had to learn about information architecture, content management, and content strategy. I’ve written almost everything: admin guides, install guides, end-user help, API references, and I’ve done a whole lot of editing. (I’ve only documented hardware once, for a contract.) This probably isn’t all that unusual, and I’m guessing that a lot of other tech writers have picked up similar skills. That’s why I’ve never felt that it was worth throwing my hat into the ring as yet another tech writer blogger.

Why Start Now?

What’s changed is that some very smart people have been reevaluating the tech writing field, and realizing that what we do, and how we do it, needs to change to allow us to stay relevant. I’ve been thinking about that, too, and putting those ideas into practice. In my previous job, I moved myself from the far corner of the engineering section right into the middle of the company: Sitting with the customer support and customer success teams.

This is probably one of the best ideas that I’ve ever had, at least as far as work goes. (Truth be told, the Support team encouraged it since we spent so much time talking, anyway.)

Since I was the only tech writer in the company, it was an easy move to make, although my boss wondered why I’d want to move from a quiet area to a noisy one. Suddenly, I had instant access to the people who talked to our customers every single day, and real-time access to questions from customers.

A running joke was that a support person, on the phone with a customer, would turn around and say, “I’ll let our documentation team know about that issue.” And since our docs were in an online wiki, my response would often be to pull up the docs and make the required changes right then and there.

Sure, it was noisy. If I knew that I had to write a huge amount of docs for a new project, I’d spend a day at home. But the insight into our customers’ questions and needs made for better docs, and also made me a better writer.

Do We Know Our Audience?

One of the first rules in tech writing is Know Your Audience. But how many tech writers really know their audience? I’ll admit that I usually had a vague view, filtered through other people: It’s always a good idea to talk to product managers, support, professional services, sales, and marketing (did I miss anyone?). And doc teams will often build (or at least think about building) personas to represent their customers. But personas are guesses, and they’re imprecise. As writers, we understand those limitations, but those are the best tools that we have.

CS and CSM

A friend of mine in customer support once said that everyone in a company should spend a week taking support calls. Not only would they learn a lot about the product, but they’d learn a lot about the people who use the product. Those users are often very different from the people who decided to buy the product: As often as they talk to the decision-makers, sales and PMs might never talk to the day-to-day users. Which, on a daily basis, they don’t need to do. But I spending a few days a year on the support lines would be an enlightening experience.

And then there is the Customer Success Management team (CSMs), who are like customer support…but very different. Although I’ve known CSMs who came from support roles, and the CSMs need to have a thorough understanding of the product, they don’t track individual issues (they hand those off to support). Instead, they track accounts (customers) and make sure those customers have what the knowledge and support they need to be…er…successful. Which in this case means: Using the product in a way that helps you (the customer) do your job better, so you have good results to show to your bosses, and your company buys more of our software.

That’s a simplistic view, and that’s one reason why this blog is going to be a learning experience for me.

Ok, Really: Why Start Blogging Now?

Six months ago, I took a new job. While my official title is Documentation Manager, I’m also the head of Customer Care (aka, customer support). And by “the head of,” I mean “the one and only person who answers tickets and support calls.”

I was excited about the job because I believe that the Docs and Support departments should be as close as possible. After all, we both work to support the customers as they learn about and use the product. Plus, there’s so much good info coming from customer questions that needs to be included in the documentation, and in the past I’ve found that this is transmitted very poorly, if at all. In fact, I recently went to a meetup at a large company where the user documentation and support teams maintain entirely separate knowledge bases. The explanation for this: “One is descriptive, the other is prescriptive.”

I spent the rest of the meeting shaking my head in astonishment. Why make your users go to TWO sources of truth? What if they conflict, or even say the same thing in a slightly different way?

And these were massive doc sets. Two different teams, managing different doc sets, using different tools. And millions of users who just want their questions answered.

A New Job, a New Path (I Hope)

So when this job was described as “documentation, customer support, helping with the UI, editing papers, and we could use some help with training,” I leapt at it.

In the first few weeks, I built a support site, adapted the existing docs (a 25 page PDF) into knowledge base topics, and helped out with editing (lots of proposals and whitepapers). We have a low number of support tickets being filed, so I can stay on top of those while working on the docs for the next version of our product.

Then my boss asked me to help with training. First it was just to talk to the people who have been training our customers, so that I could create a training outline. Basically: Write down what they do. This was useful, but we’ve known that it’s incomplete: an outline is great, but no two people trained users in the same way, on the same topics, and we need standardized, repeatable training.

In fact, we need standardized, repeatable processes to help our customers learn to use and keep using our product. Which is why my boss decided that we needed a customer success management team.

And that’s where I am now, and why things are getting really interesting.