How to build a culture of knowledge-sharing | Support Hacks

A few months back I had the opportunity to talk with over thirty Support Engineers, most working for established software companies with mature products. Surprisingly, many of them told me they frequently find themselves in a situation where they couldn’t trust the documentation. The same documentation is supposed to help them find solutions and resolve tickets faster.

This was an interesting finding, knowing that KCS has been around for more than 20 years. I believe one of the reasons many teams are not adopting a knowledge-centered service, is because they think it requires a significant investment. You need to “implement” KCS: purchase expensive tools, hire new people and get consultants to help.

This might be true for very large organizations, but if you are a relatively small or medium-size company you can have a knowledge-centered approach without even realizing it. In this issue, I will describe a set of practices that will help Technical Support Teams put knowledge at the center of how they work.

Many years ago I was working for a small software startup in Dublin as a developer. The product was very complex and hard to troubleshoot. I was spending an important amount of time explaining the same concepts over and over again.

It was frustrating as I wanted to spend my time building software rather than explaining troubleshooting steps repeatedly.

These are some of the symptoms you could spot when knowledge is not considered a strategic business asset.

Think about it this way:

In Support, you’re constantly working on resolving immediate issues for customers. It’s your main task. Ticket by ticket, you go as fast as you can through the queue to see the end of the day.

This makes it very hard to pause, think and do things differently. Especially things whose positive impact builds up slowly over time, like a knowledge base. It requires discipline and tolerance for delayed gratification.

To adopt a knowledge-sharing mindset, a cultural shift needs to happen in your team. A culture that balances long-term thinking with short-term tasks.

Changing how people work is hard, but not impossible. You can employ similar methods to those used to change unwanted behaviours in children 🙂

This is crucial. Make sure the team fully understands why capturing and sharing knowledge as they work is important. If you can, use examples from other teams or companies.

Like with kids, explaining is not something you only do once. You need to keep explaining and repeating yourself for weeks or even months. Build up the argument as you progress and the real impact of having a solid knowledge-sharing practice starts to kick in.

I think we underestimate the power of in the moment, honest praise. People want to make an impact: on the team, customers, company or world in general. If they think they don’t care, they lie to themselves. The more you highlight the impact they make on the shared team knowledge, on the customers and the business, the more likely they will continue the right behaviour.

In Romania, we have a saying: “Do what the priest says, not what he does”. Make sure this doesn’t apply to you. Take every opportunity to show your team how to do the right thing.

Work with them on this, side by side, as your time allows it. Capture and reuse knowledge at every opportunity, rather than asking other teams over and over or trying to re-inventing the wheel.

The KCS principles are simple. You don’t need to read books to understand them. The hardest part is figuring out how you put them into practice: adapt and apply KCS into a framework that works for your team.

To adopt KCS you need to implement a continuous loop of capturing, structuring and reusing knowledge while the team is actively supporting customers.

For every new customer request, search if there is an existing article that could be used as an answer. If there isn’t, create a new article and document the solution provided to the customer. Try to use the language and phrasing used by the customer when describing the problem.

Don’t let your team start from scratch. Use templates to help them get started with writing documentation on a new topic. This simplifies their workflow and ensures consistency across the entire help centre.

Don’t reinvent the wheel for every new customer issue. Always search the knowledge base first and use links or paragraphs within articles to write the response to the customer.

If the article contains out of date information or doesn’t fully address the customer question, make all the necessary updates. This will keep the content fresh and prevent the “I don’t trust the documentation” problem mentioned at the beginning.

And that’s all it is: capture, structure, reuse and improve. The four steps are very simple. The hardest part is helping your team break the old habits and adopting a new mindset. The good news is that once you gain some momentum, the benefits of this process become more and more obvious to your team. The value builds on itself.

By speaking with many Support Engineers a few months ago I learned that most of them were spending a significant amount of their ticket work time searching for answers in lots of different places: old tickets, Help Center, Confluence, Slack etc.

So I decided to build an app that brings them all the answers at their fingertips. It makes searching for old tickets and articles in Zendesk extremely easy. Confluence and Slack integrations will be available soon. If you are using Zendesk, you can give it a try at no cost.