I’ve been a tech writer for 18 years, and I’ve worked for half a dozen companies as a full-time writer or doc manager (which has meant “full-time writer who also helps other writers clear roadblocks”). In all that time, I’ve never been a member of the Support team.
From my experience, and from talking to other tech writers, we’re almost never part of Support. But that’s exactly where we should be!
Possibly. At least I think so.
Who do we report to?
As a tech writer, I’ve been incorporated into the Engineering team, Product (product management), and Marketing (for about five minutes). Even when I was part of a large doc team, we either reported to an engineering VP, or they had the power to approve new hire (and, ultimately, lay us off). Why do we rarely ever see docs as part of support?
In most of my jobs, I’ve been part of the engineering group, and my management chain has gone up to a VP of engineering. This makes some sense when you consider the documentation to be a product deliverable: Engineers (aka Developers, aka Programmers) write the software to create the product that gets shipped on some date. And traditionally, there needs to be documentation to go along with that product release: You get a box of disks and a bunch of printed manuals. Or a bunch of PDFs that would be a shelf full of paper if you printed them.
But in this century, it’s not so easy to find a home
But that doesn’t happen with modern software development, especially with SaaS products. We have products that see continuous development. Similarly, the documentation must be written and updated continuously to keep up with the product changes. We’re not creating huge manuals anymore, which can only be done in year-long (or longer) development cycles. Current user docs are knowledge bases and wikis and other types of online web content that have a research-write-publish cycle that is measured in days, or even hours.
All of which doesn’t argue against being part of engineering: After all, shouldn’t the writer be close to the people who are building the software?
Yes, of course! But if the product management team builds the roadmap for the software, then why not be part of that group? I’ve done that a couple of times, and while it can work, not many PMs focus on the needs of the end user. They’re thinking strategically, figuring out what the product will look like in a year, two years, or more. While they work to address customer needs, it’s not the customer’s immediate needs in the sense of “What button do I press?”
Although PMs are often great about providing the larger context for a product (what problems does it solve, how should users think about using it), they usually aren’t as helpful when you need to answer basic usage questions.
Merging Docs and Support
I’ll start with an argument against merging Doc and Support teams: Customer support is often thought of as being “prescriptive” (here’s how you solve your particular problem), while the user documentation is “descriptive” (here’s what this feature does and how to use it). And while that can certainly be true, it’s not always true, and they often blur.
In my current role, I’m responsible for the product documentation and customer support. About half of the support tickets I receive are usage problems: A user can’t connect to our servers, they’re seeing errors when uploading data, etc. The other half are questions: How do I know what to look for when analyzing my data?
Then there’s a small number of tickets that are reporting problems with our server (a few users hit it really hard one day), and people asking for a free trial of our product (which gets forwarded to our sales team).
Based on this, most of the tickets can contribute to the documentation: usage problems become tips and troubleshooting, and questions become conceptual topics.
Maybe this is an unusual distribution, and I’ll have to revisit it when we start to get a higher volume of tickets. But for now, most of the tickets that come in will either get turned into topics, or will be used to improve existing topics.
Support, docs, training
At a previous company, training was part of the support department. This is unusual in my experience, but it worked well. But training is even further away from the delivery of information about day-to-day product usage; individual support tickets would rarely affect the training course or materials.
In short: The technical writers have more of a support role than the people developing and delivering training!
But all three roles are all about customer support: Helping customers use the product better, either by solving individual problems (support, docs), by showing them how to use product features (docs, training), or by helping them get the most out of the product (training, docs).
What are the risks?
The main risk is that customer support is usually one of the least powerful and least respected departments in a company. Of course, that’s also true for the documentation department. Neither are profit centers, and lower levels of support don’t usually require a lot of technical expertise. Engineering is almost always a more respected department, and the head of an engineering department will have more political power than the head of support. After all: If the code doesn’t get written, the product doesn’t ship, sales aren’t made, and the company goes bankrupt. A product can ship without support (or documentation). Because of this, support will not be the most powerful ally when times are tough.
That said: I’ve seen documentation groups gutted when an engineering director had to decide whether to keep a programmer or a tech writer when it was time for layoffs.
A doc team that’s part of a larger engineering team will share a bit more of a sense of inclusiveness with the engineers. In theory, at least. In my experience, it’s more likely that the engineers will give you a funny look when you attend an engineering team meeting: “You’re part of this group?”
And anyway, that’s easily overcome by getting to know the engineers: join them for lunch, talk about their favorite APIs (and especially their favorite API documentation), and just generally make yourself known to them before you have to ask them to review your docs.
And the benefits?
The greatest benefit to working with your support team is the ability to have one question answered very easily: What are our customers asking about?
That will determine your doc priorities. Yes, there’s a new product being released next month, and five new features for the existing product, but face it: Your current docs aren’t perfect. Mine certainly aren’t, and never have been. You can’t answer every question, or provide perfect, insightful documentation for every feature in every one of your products. But you can talk to your support team to identify areas where your users need more help. Or maybe the help is great, but the users can’t find it (and keep asking for info). You can show the support team where those docs are, and they can provide links to your users. And then you can figure out why the users can’t find it! (Poor search functionality? Not enough links? Confusing TOC? Or maybe you just forgot to add the new topics to the navigation…which has happened to me more than once.)
Where is your doc team located in your corporate structure? Does it match with your closest collaborators? Would your doc team be more effective in a different department?
Maybe it’s not necessary to restructure your company, but I’ve learned that it is worthwhile to collaborate with your support team, and do more than exchange email once or twice a month. Effective docs are solving customer problems before your customers have problems; your support team will be thrilled to learn that you want to work with them to make that happen.