Tech Writers and KCS

The KCS Academy hosted a KCS in Action web session on September 25 about how to improve collaboration between groups who contribute differently to essential knowledge capture in organizations. Watch the recording here (YouTube).

With well over 100 attendees tuned in live, the chat window was full of valuable insights and conversation. It’s no surprise that we ran out of time to address all the questions. We’ll tackle some of the questions here, and stay tuned for upcoming Consortium for Service Innovation events where this conversation will surely continue!

Web Session Summary

Libby Healy from Tyler Technologies, Sara Feldman from MindTouch, and David Kay from DB Kay & Associates led a conversation about the intersection of KCS and technical writing. We described the role of a Tech Writer, detailed areas of similarity and overlap with KCS, and explored ways to bridge the gaps between KCS and technical writing.

What you should know about Technical Writers

Sara gave us an overview of the role of Technical Writers. The mission of Technical Writers, who are truly professional communicators across many formats, is to transfer information through any medium that best facilitates comprehension. The Tech Writer role is cross-functional and frequently collaborates with design, development, product, marketing, and support teams. Although it varies across industries, Tech Writers consider their customers to include both external users and internal teams (often Support or Services).

Projected job growth is promising! And of course, there are constant changes that generate a spectrum of reactions from fearful to excited.

Strategies for KCS and Tech Writer collaboration

Libby shared strategies for boosting collaboration between KCS Knowledge Workers and Technical Writers.

• Co-create a customer “hierarchy of needs” for technical documentation. Define who your customers are externally and internally and what each group needs to be successful. Find areas of overlap. Educate the Technical Writing team about how concepts within the Solve and Evolve Loops help meet the needs of customers within different business areas.
• Share metrics to have consistent measures of success. Discuss the KCS Strategic Framework with your Technical Writers. Identify measures that apply to published knowledge across teams and share your analytics tools and dashboards.
• Develop a shared Content Standard to the extent possible. Find alignment between your Technical Writers’ Style Guide and your Content Standard. Explain how the structure outlined in the Content Standard reduces time to delivery, increases findability, and enables Knowledge Workers to publish content that is optimized for your users.
• Involve the tech writer sooner in the process of new product support / issue resolution. Harness the power of the Evolve Loop to create a culture of Agile knowledge. Work collaboratively with your Technical Writing teams, who already have relationships with your product teams, to evangelize product and process opportunities.

Easing from traditional Knowledge Management to KCS

David drew upon his many years of training and consulting experience to share how to guide organizations towards a stronger knowledge-sharing culture.

KCS adoption can be unsettling to Knowledge Managers who aren’t sure how their Tech Writers will fit into the new equation. However, addressing how KCS can solve their common pain points can fast-track collaboration.

Over time, KCS Knowledge Workers become valuable subject matter experts who can avoid traditional organizational bottlenecks and help distribute technical or less exciting work into existing workflows.

Knowledge Managers are left with more time for high-value, more interesting work. As the methodology of the Evolve Loop matures, Knowledge Managers will have even more opportunity to contribute to rewarding product and process improvements that deliver value to customers and the business.

Questions and Input from Attendees

As a presenter, nothing is more exciting than an engaged audience and this audience delivered!

The questions and comments clustered around three themes:

1. Tools
2. Workflow and SMEs
3. Feedback, measures, KPIs

Tools

Attendee Questions and Comments

• Could you talk more about tools? Long-time Tech Writer here who is just stepping into the world of KCS.
• As a tech writer using FrameMaker for printed guides, we post PDFs which provide nothing more than download metrics. We are exploring HTML output but it would require significant web development to function.
• Thoughts on how to get Tech Writers and the Solve Loop working in the same tools? Typically KM tools built for the speed of conversation are not exactly what Tech Writing teams use.
• Technical writer here – would love to hear experiences or opinions related to using DITA and KCS together.
• How do Federated search options factor in?
• What do you use to store documentation that “lives” where it can be maintained and kept up to date? As best practices state, we should link to that documentation where it will be maintained.
• You shouldn’t have to know where Team A has their content and where Team B has their content. Team A has a wiki; Team B has a OneNote; Team C has a Sharepoint site and they don’t interlink – I get the need for a good “Customer Experience” when looking for information.

Presenter Responses

From Sara: I understand why it’s necessary to consider tools, but too often I see that it’s where people’s minds go first when trying to tackle change or optimize processes. The most important thing you can do is first determine what’s needed, in terms of knowledge delivery, for your internal and external customers to be successful. Then work backwards, or “outside-in”, to determine how tools can enable that experience. It’s why KCS methodology recommends waiting to consider a technology update until phase 2 of KCS adoption. It’s why at MindTouch, even as one of just a few KCS Verified Tools, we remind anyone who will listen that a tools-first approach to Knowledge Management is misguided.

At a minimum, your customers (and therefore tool requirements) likely need real-time access to extensible, web-based (HTML) content. As a career Technical Writer and KCS practitioner, I forsee Technical Writers needing to adjust how they use tools (while still maintaining their methods) to more closely follow how customer-facing Knowledge Worker teams have evolved than the other way around.

From Libby: Sara’s answer here is great. Many traditional KM tools do not allow for crowdsourcing in document creation. Harnessing the collective knowledge of an organization through crowdsourcing, as opposed to one person needing to know everything about solving an issue, is the key to leveraging organizational knowledge. Additionally, the ability to put links in knowledge articles that can take users to additional documentation, like release notes, makes the need to all work in one system less urgent.

Unified search engines can help enormously to bring together several sources; but in the area of client support, many times the language used in documentation is the sticking point rather than a lack of documentation. One of the great things about KCS is that it captures the description of the issue in the client’s words and then simply outlines the context and resolution.

From David: First, as one of the questioners suggested, even if KCS solve loopers and tech writers work in different tools, the most important thing is the experience of the person looking for knowledge.  As Libby says, a unified search can pull together a “one stop shopping” experience across multiple repositories.

But Sara’s right: the process is the key thing to work on.  And in this case, the most important part of the process is the nature of the content itself.  KCS articles are short, in the reader’s context, and about one thing. Those seem like desirable characteristics for other documentation, too!  Combining 327-page PDFs in the same tool or search results with KCS articles will never yield a desirable experience, but our clients who have rethought their docs to look more like articles have achieved real success.

Workflow and SMEs

Attendee Questions and Comments

• Our Tech Writing team is chartered to write post-sales installation, usage, and troubleshooting content. Typically “support” documentation is geared to our Global Services team with info that isn’t meant for customers. Is that typical?
• If our organization only publishes one type of content – knowledge base help articles – how do the Tech Writer and KCS Knowledge Workers work together?
• How does a traditional doc flow apply to all of this? My background is a workflow like this: 1) author writes 2) someone peer reviews / proofreads 3) SME reviews 4) schedule publication 5) publication.
• Where does Online Help / User Guide content fit into the KCS realm? The user guide should list a bunch of tasks the user can do in a system, content that is not being created because of a customer issue.
• “Every Solve Loop article is a mini-customer conversation”. << Great quote!
• I am a knowledge manager, coach, and service desk manager. We moved to KCS 3 months ago and currently piloting with the service desk and desktop groups. What suggestions can you give on getting adoption from SMEs?
• SMEs also don’t necessarily *like* to write or that’s not their forte. Teams that keep their knowledge in silos is a real thing. 
• Sometimes SMEs do not have the ability to articulate themselves on paper. Yet in conversation it starts to unpack the thought process, that missing information. What can be done to assist in this?
• Being in the UI from a tech writer perspective often results in a totally different documentation of the process than even something from an SME.
• “Reuse content” means different things to me. A snippet of text – for example, the Help Desk info that might be located at the bottom of multiple documents is reusing content.
• One of my soap box topics is that you should tell the user to do the same thing the same way every time using the same words. You shouldn’t vary between “Edit the details” and “Modify the details” and “Update the details”. Don’t make the user guess if there is a difference between the synonyms.

Presenter Responses

From Sara: Consider planning a Design Session with expanded scope to include Technical Writing functions. Be sure to prioritize what will most effectively get useful content in front of users as quickly as possible, rather than maintaining processes just because it’s how you’re used to working. Also, do not assume you have a shared vocabulary across teams. Words like “reuse” and even “structure” mean different things depending on context, so take the time to define and agree on a common vocabulary for your cross-functional content processes.

From Libby: The idea that support agents can deliver product support information verbally over the phone or in writing in a case, but are not welcome to create documentation for a knowledge base article, is short-sighted when you consider the key issue resolution information they have as tacit knowledge. Co-create a glossary of terms and synonyms and align on what terms like “reuse” mean in the context of issue resolution and client support. Your support agents are in the perfect place to tell you which of these terms resonates and makes sense to clients as opposed to what we understand internally.

Getting buy-in from SMEs can be difficult. First, they don’t have to be good writers–get them to put in what they know and have their coach work with them to get the article to comply with the Content Standard. Second, if you are having difficulty getting your SMEs involved in the creation of knowledge articles… have you asked them why? Sit with them while they work. Observe and acknowledge their frustrations and blockers, and then work together to overcome. You don’t need to get them all, but you do need to get some key influencers to work with you.

From David:  First, I’d like to point out that KCS doesn’t restrict content contribution only to SMEs.  If you’re working a case or ticket, by definition, you’re the expert on that issue in the moment, and “if it’s worth solving, it’s worth putting in the knowledge base.”  We’re not asking them to become tech writers and master topic sentences and proper use of the colon; we’re effectively asking them to fill out a form.

Tech writers can be invaluable assets to KCS Evolve Loop content development (“EvolveOps.”)  Let demand, in the form of page views, article links, and feedback, tell you where to focus tech writers’ talent in the knowledge base, and leave the everyday work to solve loopers.

Feedback, Measures, and KPIs

Attendee Questions and Comments

• What feedback mechanism do you use as a Tech Writer so the process can be improved?
• Feedback tools in the UI that presents the self-help developed as knowledge articles can be helpful to measure the usefulness of content.
• Because our content is distributed as HTML content over the internet, we use Google Analytics to determine which help topics customers most access. It doesn’t get to quality but at least importance.
• We use a feedback tool on our web-based documentation. Customers give a thumbs-up or thumbs-down and can reply in free-text what they want changed if they give a thumbs-down. We combine the feedback with Google Analytics to figure out our feedback rate.
• Can you identify KPIs that we should be measuring?
• I’ve requested our data team to build a report showing if customers opened tickets after visiting a knowledge article about the same topic. This gives an idea of the quality of the article for self-service.
• How do you track reuse? What platform has been most useful technology-wise?
• Success Story: I’ve created dashboards that show knowledge usage, and also the participation of people who have suggested updates and SMEs who have helped confirm the updates. Both sides are starting to see the impact they’ve made and that they’re really being heard/respected.  I feel they’re starting to trust each other more…which is HUGE!

Presenter Responses

From Sara: Derive feedback from actual customer interactions and effort, rather than just content-specific mechanisms. Vanity dashboards of content engagement don’t prove much value. Determine the connection between your content and the KPIs that keep the lights on (and fuel your paycheck): adoption, expansion, renewals, etc. Zoom in on high effort friction points or where self-service opportunities failed to find the best opportunities to improve. Consider that if you leverage content insights effectively to prioritize product and process improvements, then decreased content engagement over time could even be a good thing!

From Libby: Dashboards are amazing to see the big picture of successful documentation, but nothing compares to going right to the source. If you do not have access to digital tools to measure success, what you do have access to are your agents in support. How often do your Tech Writers sit with Support and watch them use documentation in the process of supporting clients? How many user group sessions have you hosted with Support to get feedback on the tech documentation being created for them? Pro Tip: bring pizza. Everyone likes pizza.

If Tech Writers do not have the ability to sit with Support, can you get the top 20 client questions from the last quarter and look to see if the answer is documented and easy to find? Go on a client visit and watch them try to find answers.

Clients contact support for 3 main reasons: Bug Report–reporting a bug, Service Request–requesting to have work done on their behalf, and Training–asking for assistance with expected functionality. Within the sphere of client support, Technical Writers should take aim at the calls marked as training and, more importantly, repeat questions. If clients are calling with the same question over and over, this can indicate a documentation failure.

From David:  We infer article value from user behavior.  Did a team member attach an article to a case?  Did a user print or bookmark it? Did they dwell on it a long time after viewing other articles?  Did they stop opening a case after viewing it? You can’t prove anything with these indicators, but they’re helpful nonetheless.

As far as KPIs for the value of knowledge, my favorites are:

• Contact rate, or cases normalized by demand (e.g., number of customers or monthly recurring revenue).  As self-service increases in effectiveness, each customer will open fewer cases. If contact rate decreases while self-service sessions increase, we have a strong indication of self-service success
• Time to resolution for cases with a reused article vs. cases that created an article vs. cases with no article.  (Substitute your favorite productivity metric for time to resolution.) This clearly demonstrates the value of knowledge reuse, as cases linked to an existing article will be more efficient.

What’s Next?

Feel free to reach out to any of the presenters for further questions or conversation. Additional chat comments also requested more exploration of the Evolve Loop. We’ll see if the “EvolveOps” name catches on, but the Evolve Loop is certainly an opportunity to improve how we leverage cross-functional resources to generate the most value in our knowledge-centered organizations.

Thanks to Libby Healy from Tyler Technologies, Sara Feldman from MindTouch, and David Kay from DB Kay & Associates for their time and expertise – and to Sara for pulling together this fabulous recap!

Register for future KCS in Action calls here, or leave a topic suggestion in the comments below.