Connection Points with the Tech Comm Role

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.

connection points

Connection Points

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.

Adobe RobohelpMadcap Flare

This entry was posted in general on by .

By Tom Johnson

I'm a technical writer working for The 41st Parameter in San Jose, California. I'm primarily interested in topics related to technical writing, such as visual communication (video tutorials, illustrations), findability (organization, information architecture), API documentation (code examples, programming), and web publishing (web platforms, interactivity) -- pretty much everything related to technical writing. If you're trying to keep up to date about the field of technical communication, subscribe to my blog either by RSS or by email. To learn more about me, see my About page. You can also contact me if you have questions.

8 thoughts on “Connection Points with the Tech Comm Role

  1. Larry Kunz

    Yes, Tom, you’re onto something; and no, it’s not unique to you or to where you work. A key thing that distinguishes technical communicators is our ability and our desire to connect people with the information they need. It’s what gets many of us out of bed in the morning.

    Awhile ago I wrote something (although I can’t find it now) about how we technical communicators like to explain things. I much prefer your word: connect. Connecting people with information, especially where the connection crosses silos and therefore isn’t readily apparent, is what we excel at. It’s also the foundation for a trend that we hear a lot about: content curation.

    Because you love being a connector, I’d say that you’re in exactly the right line of work. Not everyone shares your passion. But a lot of people who read this blog do.

    1. Tom Johnson

      Larry, thanks for your comment! When I initially published this article, I was unsure about its value, so it was good to get your feedback. I like how you’ve phrased the overall argument — “A key thing that distinguishes technical communicators is our ability and our desire to connect people with the information they need.” I think that describes the tech comm role perfectly, because it establishes an audience for the information we create. We don’t just explain products. We get the right information to the right people. This also gives our role more of a purpose.

  2. Fer O'Neil

    I can also confirm that you are not alone in your experience as a “connector.” Actually, I can recall performing all of the same connecting functions you described in your work, so perhaps this is a more common role or one that is becoming more prevalent in some industries (e.g., such as yours and mine). I have written a little on this topic, not specifically as you have done, but this idea is weaved through most of my technical writing blog articles and my more practical-based presentations. I looked back through some of these and found that what you label a “connector,” I have called a “coordinator,” “facilitator,” and “cross departmental” but I’m sure there are many more names out there for this.

    1. Tom Johnson

      Thanks Fer. It’s good to know that being a connector is more of a widespread role technical writers play. I’m glad to see you’ve written about this. I think perhaps more attention could be played to the connector idea and role. Too often tech writers are portrayed as isolated, introverted hermits.

  3. Mark Baker

    Tom, I think writers have always been connectors. The difference is that when connections are made by the exchange of paper, the connection is buffered, often highly buffered, with a cycle time measured in years.

    On a network, the connections are largely unbuffered, or the buffers/cycle times are much smaller. The absence of the buffer substantially changes the nature of the job and the kinds of things you do throughout your day.

    I think one of the biggest challenges for tech comm in adapting to the Web is that it is so imbued with the conventions and practices of highly buffered connections that it has a hard time adapting to an unbuffered world, and wants to run and hide behind its old buffering mechanisms. That is doomed to failure in the end, of course, because consumers simply prefer unbuffered connections to buffered ones.

    1. Tom Johnson

      writers have always been connectors. The difference is that when connections are made by the exchange of paper, the connection is buffered, often highly buffered, with a cycle time measured in years.

      I like the point you make. You’re right — tech writers connect project teams to users through the help material we create, which allows users to understand and interact with the products created by engineers. I hadn’t thought about that larger, fundamental activity that we do. Thanks for this insight.

      I also agree that buffer times are decreasing. We see this with email regularly. Rather than allowing people 24 hours to respond to an email, now the general response time is at least half that, if not a third.

  4. Bobbi

    Tom,

    Another on point article.

    I am presently brainstorming how I can elicit user feedback from our users about our documentation set. I’d like to have some feedback around what information (and format, etc) is most useful to our users. What don’t they like and what would they like.? I’m thinking a very brief set of questions on a forum might give users a touch point when they do have issues.

    I’m trying to brainstorm how to begin collecting this data without a long survey, or absorbing too much of the user’s time. I especially liked your solution of the list of SMEs and products for moderated forums.

    If anyone has any ideas or experience with collecting user feedback, I’d love to hear about it. What worked and what didn’t and perhaps why.

    Thanks again Tom.

    1. Tom Johnson

      Our user forums have been the most successful way to gather feedback from users. We use phpbb as the forum software — it’s probably similar to other forum platforms. I like forums because the information you gather can be read by others (in other words, it’s not a 1:1 information exchange situation), the information is searchable and appears on Google, you can have back-and-forth exchanges to surface information, and others can respond, so the entire burden to interact doesn’t rest with just one person.

      I would be interested to hear what you find out from your survey.

Comments are closed.