Why isn’t the documentation team part of customer support?

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.)

Wrapping up

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.

14 thoughts on “Why isn’t the documentation team part of customer support?

  1. Descriptive vs. prescriptive: I’ve been fighting this fight myself. When users access the doc, they don’t ask “What are all the different things I can do?” They ask “How do I do what I want to do right now?”

    One problem is that descriptive is easier: the product is usually evident as an API or UI. The writer has specs, email threads, access to developers, PMs, and to the product itself, all of which can give a vague impression of what the product was intended to do. This path leads to massive PDF reference guides that age like fresh milk and are trotted out whenever a salesperson frantically asks “Do we have doc for [Product X]?”

    On the prescriptive side, what the customer wants can be a challenge to determine. Often, the customer can’t be bothered to articulate their needs beyond an angry phone call or email. The customer is also often shrouded behind layers of relationship management, corporate reputation protection, marketing spin, and the low-status/high-chaos environment of Customer Support. Even if you do resolve this challenge and figure out the customer’s needs, delivering fresh content in no more than a couple of taps or swipes is another complication. You can bring technology to bear on the problem, but it will not be consistently solved until we effect an evolution of corporate culture.

    I got a little carried away just then. Tech writers are not going to be in a position to push through big changes. This is not a symptom of an inferiority complex. It’s a reality of consumer culture. As you conclude, applying your energies in a lateral, social approach can work well. In my experience, initiating collaboration with other groups has yielded incremental improvements and, in at least one case, a big improvement in corporate communication. As a writer, Customer Support is your friend. QA is your friend. PM is your friend. Engineering is your friend. Marketing? Well, let’s just say you’re on the same team.

    1. “This is not a symptom of an inferiority complex. It’s a reality of consumer culture.”

      Like the way you put that. And agreed. Tech docs is never going to be the biggest/closest to the customer/etc. Size of the department (among other things) is always going to factor into influence in a company. Tech docs are not an income generator, for one.

  2. Excellent points, Phil. You identified something that I left out, but is incredibly relevant: Descriptive docs are easier to write. Absolutely true, and always a problem when writers are delivering docs before a product launch. If a user hasn’t used the product, how do we know how they’ll use it?

    “Evolution in corporate culture:” I agree that it might be wishful thinking, but that also speaks to why I like smaller companies. But even then, I’m not a tech writer with access to customers; instead, I’m transitioning away from a “pure” technical writing role towards being more customer-facing. As you say, tech writers are almost never given access to customers, for all sorts of corporate reasons.

  3. Belonging to Engineering, I can provide usability input while Feature X is being developed. By the time it hits Support, it’s too late. The customer already has a problem. The “lateral” outreach I use with CSS, Marketing, etc. instead.

    My best experience, though, was where all teams reported to the PM — Product Manager, not Project Manager. By spanning all teams, the product manager balanced headcount needs and profitability in all teams. He assigned teamwork that otherwise would not have been in the interest of an individual group, but was necessary for the overall product to succeed. He also chaired regular, quick product meetings that made in-group behavior built-in — not voluntary.

    Top down is the only way you can reliably prevent silo mentality, in my experience. The other way (grassroots — convincing all peers to agree to be a cross-functional team, even though managers’ interests may conflict) is just too mathematically improbable, to say nothing of psychology and how human egos and trust-building work.

    1. Thanks for the response! There’s a lot to think about there.

      As you said, good product managers will pull the team together and focus on the strengths of everyone involved. So one solution is “Hire great product managers.”

      But I’ve worked with PMs who don’t do that (they assign tasks but don’t encourage feedback). We don’t have *any* PMs in my current company (we’re looking, though). I know that this isn’t typical, and it’s certainly different than my experiences at larger companies.

      I strongly believe that the doc team needs to be involved from the early stages of product development. Again, this is where a good PM will help. But in case you don’t have a good PM, I’ve found that it’s up to the individual (or the doc manager for a team of writers) to make the connections with engineering and get involved in those design meetings. I’ve certainly seen enough of the ego and self-protection problems that you mentioned, but I’ve seen a lot more of that in larger companies.

      But this also assumes that the engineering leads see the value of bringing in the doc team early. If they have the old school mentality that they’ll throw some specs over the wall a few weeks before the release, and then magically get some PDFs to include with the product…well, that one will probably require a VP to get involved.

      Personally, I get ready to move on once it becomes clear that things will only be done when a lot of pressure is applied from above. At that point, everything becomes a political battle, and it becomes too much work just to get my job done. This is when I need a good manager to help me sort things out, and pull me away from the cliff.

      And that’s clearly not an ideal solution, either!

  4. (Side note: FYI Google+ sign-in didn’t work for me. Hung on “Connecting” progress bar. Could be related to the extensions. I’ve seen other sites where the widgets on the page conflicted with the button in the browser. Chrome 30.0.1599.69 m with Google+ Notification and +1 Button extensions.)

  5. Interesting post though I will add a few more benefits of documentation teams working closely with support teams.
    – Support teams know the hot spots of where a majority of users have maximum concern and documentation team can prioritize it by paying urgent attention to update, or to connect with users by whatever media is part of content strategy.
    – Support teams can help documentation teams to plan for more content types (deliverables) if required. For example, if a reasonable section of users are asking about ‘how to setup notification parameters before I generate the credit report’, the documentation team may plan to add some graphics or even a video to help users.
    – Support teams are always updated on latest news and development on product and so they are excellent SMEs whom writers can contact or engage with.

  6. Neal, I agree with your following comment: “effective docs are solving customer problems before your customers have problems.” Also, I agree that documentation can benefit from being a part of the customer service department. I have the following answers to your questions:
    Where is your doc team located in your corporate structure?
    We are a part of the product marketing department. And, as you’ve written, the focus of the managing authorities is not on delivering quality documentation, but on covering the features (seeing which feature goes into the product, and which doesn’t).
    Does it match with your closest collaborators? Would your doc team be more effective in a different department?
    Well, I personally like to interact with people from all teams. I feel that I am a catalyst to communication in my organization. As a technical writer, I try to translate complex coding and algorithms into understandable business-benefiting descriptions. So, for me, being in the product marketing department becomes fruitful, because I can (with the vision from the department) deal better with the customer-centric questions.

    I too have written on a similar topic (http://wp.me/P1bt0i-4N) and would appreciate your views on it.

    1. Thanks for the comment. I’m obviously not the only one writing about this, and I feel like I’m late to the game. I agree with your summary:

      Like achieving long-term objectives, good documentation too is a team effort, which requires cross-departmental collaboration. This collaboration, in the form of information exchange, is in itself the most critical task. And, as a technical writer, I am happy to be the catalyst in that exchange.

      I’ve always felt like my role in a meeting is often to get the other people to start talking to each other, and starting a conversation that wouldn’t otherwise happen.

Comments are closed.