Although “collaboration” is a buzzword, it’s also a worthy goal for any tech writer. Or customer support agent. Or customer success manager. Or pretty much anyone, to be honest. I’ve known more than one tech writer who was happy working alone, receiving technical specs from engineers and throwing docs back. But those jobs: a) aren’t much fun; b) aren’t going to help you build your department.
Or your career.
Last week, on this blog…
In my last post, I mentioned that at my last company I sat with the customer support and customer success teams. This was possible because I was the only writer in the company (I later hired another writer), and because I worked well, and often, with the teams. Although I worked with all of the departments in the company, I worked with customer support/success every single day. There really wasn’t a day when I wouldn’t have questions for them (as product experts), or they would have questions or doc requests for me (asking where some feature was documented; and if it wasn’t, then a request to get that doc written!).
Formal vs. informal communication
While many companies use a formal process for this, working next to each other allowed us to communicate both formally and informally. Often, a quick, informal question would be enough, especially when I could show them an existing topic. I would still make a note of that, though, and use that info to help improve the documentation structure. After all, if support couldn’t find a topic quickly, then I couldn’t expect the users to do have any better luck.
If that wasn’t enough, we had task-tracking tools. The problem was that it required someone to step away from their current work and create that doc request, so I would often take over and create the task for myself. The benefit is that it makes it easier for people to request new or updated documentation; this made those requests very low-cost for the requester. Make yourself easier to work with, and people are more likely to work with you, right?
But those costs must balance…or lead to greater benefit
Of course, decreasing the cost for the requester meant that I was increasing the cost for myself. And being able to track requests doesn’t magically give you more time to fulfill them.
But I knew that going in, because I’ve done this before. So although I understood that I was incurring a cost (to myself), I also knew that I would see a larger benefit. What I really wanted was a record of how much content I was being expected to deliver, for two reasons: First, because it wouldn’t fall out of my head or get lost when someone threw away a post-it note. Second, I could use that information, with the addition of time estimates, to argue for more resources.
In this case, I was able to take all of those doc requests and turn them into a request for a new writer. In addition to the usual maintenance requirements, we had three big projects in the works. By creating time estimates for all of those tasks, I built up an impressively large number of required work hours to present to my boss.
Asking isn’t enough
I’ve learned that going to your boss and saying, “We need more writers!” never works. No matter how true that is, your boss needs to justify that requirement to someone else: probably their own boss, and eventually the CFO. And if your CFO is any good (in other words, if your company is still in business), they’re going to need a very solid justification for that request. Which is exactly what they should be doing, but it’s something that most of us in the trenches don’t always understand.
So I spent time collecting those tasks and building my case. Numbers added to more numbers, representing work hours that I could never come close to reaching. And that limitation in itself was something that I had to accept.
Let me tell you my biggest weakness, like the ubiquitous interview question: I take on too many tasks. I don’t want to look like I’m not pulling my weight (which is a common issue that I’ve seen with tech writers), so I’ll research the content, write the docs, edit them, build the documentation architecture, design the online documentation site, take care of links and metadata and other useful features, publish the docs, track and respond to comments, track doc requests, take on special projects, test the procedures, validate the API, edit the UI text, attend meetings for every project I’m working on…all without complaining, because isn’t that what I was hired to do?
Forests, trees, and API references
It’s easy to get so caught up in your own work that you focus on the immediate tasks and miss the forest for the trees (or miss the knowledge center for the topics). By that I mean that while you’re spending time writing a few great topics, there are many other sections of your doc set that are going untended.
For example: I was focusing on online help for our product, and all but ignoring the API guides. But web analytics showed that the API docs were getting a lot of views, and I knew that those docs were incomplete and badly out of date. All I could do was perform Documentation Triage: I recruited a couple of API experts to help identify the worst problems, and then I fixed as much as possible as quickly as possible. It was only a small side project, and I knew that it wouldn’t make our API users happy.
This was frustrating, and extremely difficult to accept for a perfectionist. I hid behind two sayings that have helped at times like that: “The perfect is the enemy of the good,” and “A good plan today is better than a perfect plan tomorrow.”
I repeated those a lot. But telling myself those things didn’t solve the problem.
Moving from denial to action
What helped me was more contact with customers. Throughout my career, I had customer requirements relayed to me from project managers, customer support, engineering leads, professional services agents, and the sales team. But I had rarely seen any actual requests from those customers. In too many cases, the PMs, etc., were guessing as much as I was. And my job as a tech writer was to represent the customer by demanding friendlier user interfaces and more complete documentation that answered their actual questions.
So there was a disconnect. And it was damnably difficult to fix that. All to often, I got pushback from the customer-facing teams: This isn’t your job, just listen to us, go back to your cube and write those docs. We’ll let you know what the customers say.
So I made customer contact a priority: I sat in on support calls and customer success meetings with customers. I attended user training, sat in the back of the room, and took pages of notes. Yes, I annoyed some of my coworkers, but I had a good reason for that: What questions were the customers asking? Which tasks were easy? Where did they get stuck? Did they use the docs at all?
Those points of contact are a great starting point. Even through you have to extrapolate information from a few users across your entire user base, it’s much better than working with no data.
And every training course should introduce users to the documentation. The trainer that I worked with did this already, so it was fairly easy to get into the training program and give a quick presentation to the students. By the end of a training course, the instructor will probably appreciate a 15 minute break!
The goal of any support role is to help your customers use your product better, faster, more efficiently. Basically, to help them get full value from the product. For tech writers, this means writing docs that answer, and anticipate, your customers’ questions, and also guide them to new features or use cases that will benefit them.
Getting information from your coworkers in customer support and customer success is important, as are any methods of getting you closer to your customers.
Using this information, you can clearly define what you need to do (write more docs), what’s required (time, information), and how you plan to accomplish that (hire more writers, clone yourself).
Without those facts, and especially those numbers, your requests won’t sway the people who can turn those requests into reality.
Although the cloning thing is always going to be a long shot.