Connection Points with the Tech Comm Role

by Tom Johnson on Jan 14, 2013
categories: technical-writing

I've noticed a trend lately in the role I play as a technical writer, but I'm not sure if the experience is common enough to be similar to other technical writers' roles, or whether it's just a role unique to my work. I have felt more and more that I'm becoming a "connector." This is both good and bad — but mostly good.

Here a few ways I connect people at work:

A lot of our users interact through an online forum. We try to drive a lot of technical support to the forum. But the forum has 120 different categories. I'm a subject matter expert of less than 10 forum categories. As such, I see a lot of threads related to products outside of my domain. I often forward links to these threads to other subject matter experts so they can respond to users.

The same thing happens with our technology blog. We post articles on a variety of technical topics. The comments coming in aren't always questions I can answer. I'm not often the subject matter expert of a blog article, just the writer or editor who lets people know about an upcoming release or new service or product. The comments often touch on a variety of topics, and I'm constantly forwarding the comments to subject matter experts (SMEs) to respond, connecting these SMEs with users.

I also try to connect user feedback to the bug tracking databases used by project teams. When people report issues in the forums, I'll often log a bug in JIRA (our bug tracking tool) for that issue. This helps connect project teams to user requests and bugs. (Usually work only gets done if there's a bugged logged about the issue.)

Outside of work, I regularly play a connector role on my blog. Questions will come about some authoring tool I know little about, and I'll forward it to someone I know who uses that tool. Or someone will ask about a tech writing program, which I only have a small knowledge about, so I'll connect the user with someone who knows much more about the program. Or someone will invite me to write articles for their blog, and I'll forward the invite to someone else.

The connector role is amplified through the Internet. We live in an era in which almost any knowledge is accessible within a few clicks. We have enough access to know a little about a lot of different things, with contact points to experts so that we can learn more. Almost every question you can ask is just a search away on Google, and the transition from a web page to an expert is usually just another click, using the "Contact" or "About" button on the same website. Whether it's comments on blogs at work, forum threads, comments and pingbacks on my blog, e-mail messages, listservs, groups, meetings, WordPress consulting, and more, I'm constantly interacting with people, connecting with myself or connecting them with others.

We've grown so used to this access, it seems normal. We feel we should be able to contact just about anyone we want, sending the person an email with a question, or comment, or other feedback. If you have a contact point, you give people a way to connect with you. With these connections, knowledge transfers more easily.

Connection points are particularly specific attribute of the tech writer role. We tech writers know more people at our work than most, because we're constantly crossing over boundaries and lines. Whereas a developer might work for years on the same program, technical writers bounce from project to project. One month we're documenting an application in Department A, the next month in Department B, the next month in Department C.

At tech writing conferences, I feel as if I know half of the attendees. Either I interact with them online, having seen or listened to a webinar, podcast, presentation, or blog post they gave, or else they know me through the same.

Even as the world expands and grows, our connections with each other expand commensurately, so that the web, although doubling or tripling in size each day, has even more interconnecting strands.

One problem in playing a connector role is that it detracts from my ability to be an individual content contributor. When I'm constantly looking at forum threads, comments, emails, and other sources, logging bugs here, contacting people through email, making phone calls, etc., I don't get in the documentation flow to get a lot of work done. At the end of the day I try to think of what I accomplished, and it's hard to even remember what I did.

Still, I love being a connector. It makes me feel as if everything and everyone is within reach. One short email to connect two people together, or to connect myself to the person, is all it takes.

The web presents us with a world without walls. In previous ages, it would have been unthinkable to contact people on the other side of the world, in other cultures and faraway places. Now, that connection is not only possible, it's practically mundane. There is no distance online — everyone is in the same room.

Playing the role of a connector is especially important at my work, a non-profit church organization. Working for a non-profit organization like mine has certain challenges. Customers don't pay for products — everything is free. There isn't a financial revenue associated with products. At first glance, this might sound appealing, because it takes off some of the pressure. But in reality it presents all kinds of problems.

If your IT group doesn't live or die by the profit it makes from customers, everything sort of slides in importance. Does customer feedback matter? Sure, but not really. Your customers haven't paid anything, so why should they be entitled to support? There isn't any competition for the products, so there's no worry that your customers will use other solutions. Most likely your customers just won't adopt the solution, but you don't have any threat that a competitor will put you out of business, because you're the only solution.

That's not to say that teams don't act on feedback. When it mounts up, if it's representative of a widespread complaint, teams suddenly wake up and prioritize the issue to find a resolution. But it takes someone to get the feedback in front of the teams and champion the user's cause before teams make usability, documentation, and support a priority. It requires someone to connect the feedback to the right person.

As a result, I regularly connect project teams with feedback from customers, highlighting trends and pasting forum thread after thread on bugs I've logged. For example, last week after I highlighted a hot forum topic with 80 plus posts, the developers spent the next day fixing the problem.

Recently I compiled a list of 75 products and their individual contacts throughout our organization. I gave it to the forum moderators to post in a restricted area that they could access when a forum thread needs escalation to a specific organization team. With this model, moderators can connect feedback from users with the right internal teams so that this information can find its way through the firewall, into JIRA, and onto the developer or designer's task list.