Why (and how) cultivate a knowledge transferring culture with Jira?

[#1]

All you need to do is ask, they say. But why would you, really? 

Think about it - asking a question may have its uses for an individual, but it isn’t scalable for a company. The people with all the answers - your experts, top performers, and knowledge holders typically have enough on their plate as is. Therefore I believe that good documentation, well-adjusted processes, and clever use of Jira are, in fact, a vastly superior option for knowledge sharing.

Why is knowledge transfer important and what’s in it for you?

Relocating your knowledge hubs from kitchens and cubicles has a series of advantages. For starters, the knowledge is yours to keep. A documented and well-kept process is prone to the Buss Factor as everyone who needs some info (and has the correct permissions) can access the knowledge at any time. A shared folder on BitWarder or 1PassWord beats relying on a password-protected Excel sheet when the person with permissions has decided to take an unexpected vacation (looking at you, Vlad). 

This also frees up your managers and team leads. They can be much more effective with their time as they don’t need to look up answers to questions - they allready have readily accessible, documented solutions. 

A culture that promotes documentation and knowledge sharing promotes self-learning and encourages accountability. I only have anecdotal evidence to back this claim, so take it with a grain of salt, but - in my experience - the people willing to look for answers are much less likely to play the “blame game”

Lastly, documentation can offer context. A well-documented wiki page or a checklist you can find inside a task offer much more insight into the flow; allowing the user to see where the answer to their question fits within a process. They might even find the next steps before they ever though about looking for them.

Ad-hoc knowledge sharing

Knowing where the idea came from and how it came to be will result in a much more defined and refined user story later. That’s why something as simple as meeting notes in Confluence can grow into an actionable implementation plan for a new feature or improvements to existing processes. 

Knowledge sharing in established and repetitive processes

A habit of making and keeping notes can grow into a culture that supports knowledge sharing. And just like any other culture - this one will need its kingdom - a centralized knowledge hub. In my experience, hosting a wiki on Confluence is more than enough to do the trick.  

The wiki can serve as a high-level overview of insights everyone needs to know, like company history, culture, benefits, and policies. And it can be a much more tactical solution with clear instructions for complex and nuanced processes like accounting, procurement requests, etc. 

As practice shows, people will appreciate your effort in putting a comprehensive knowledge base together as every time they drop by to take a look at a certain how-to or get a refresher regarding a rarely used policy, they can do so without distracting domain knowledge holders from their work. 

That being said, Confluence isn’t always enough. There are many instances where teams or departments have their own established ways of doing things. These processes gradually evolve, shift, and change. So, keeping and updating everything in a centralized wiki is a bit too much. 

And, if a certain process is relevant to the things you do daily - why not keep in the tool you use to do things on a daily basis? You can document domain-specific knowledge as checklist template in Jira.

This way, when a new person joins a company for example, all the HR team needs to do is create a new ticket and assign it to the correct person. The ticket will already have all the steps this person has to take from signing into their accounts and generating two-factor verification to gaining access to the tools and equipment they need to do their job successfully. This checklist can be broken down into things people should do on their first day, during the first week, two weeks, and one month. This way you'll have all of the necessary steps and instructions hosted neatly inside but one Jira issue. 

You can use the same approach and scale checklist templates to any recurring processes you have. For example, I’ve set up my automation in a way where a new Jira issue is created automatically at the end of each month reminding me to check on my performance. And it already has the steps I should take to check everything I need, as well as the links to tools I’ll need to use.

Why checklists?

• They illustrate what needs to be done quite well
• An app like Smart Checklist for Jira allows for effective Markdown formatting and helps with attaching links to tools, docs, or communication channels inside checklist items
• You can use checklist templates to automatically create checklists when an issue of a certain type is created
• They are flexible. If a process changes, new steps are added or removed, etc. - you can make the changes rather quickly and efficiently

Some extra tips

• I’d recommend creating practical, bite-sized pieces of content. If a certain process is related to something else - link them rather than describing everything on the same Confluence page or inside a checklist item.
• Encourage a habit of making notes.
• Don’t forget that some data you’ve shared on your WiKi may require an additional layer of protection. Manage permissions with care and keep the data only a select group of people needs to access away from public spaces. 

[Prabhu Palanisamy _Onward_]

Excellent article. Using OnRewards we can tie in the recognition and reward to this positive behavior. When a team member completes a well documented knowledge sharing checklist and document, peers can award to show their appreciation. This promotes the culture of sharing and ensuring its done across all projects and teams.