Some say that knowledge is power. I say that knowing how many times Ross said ‘we were on a break’ throughout the entire run of Friends has a 0.001% chance of having a practical application other than winning a silly bet on a night out for drinks.
The same can be said about a lot of things, really. Knowing how to document a test case is quite useful to a newbie in your QA team, but the guys from accounting or operations probably won’t find any useful applications for this type of knowledge.
Moreover, the vast availability of knowledge forms a mirage of accessibility. All you need to do is ask, and you’ll have your answer. Right?
The knowledge that’s shared verbally or kept locally by a single employee is as good as lost when said colleague takes a sick leave or chooses to move on to a different company.
Moreover, even if the employee – let’s call him Steven – is fine and dandy and chooses to stay with you, people asking him questions still take away his valuable time. Time Steven could have used to be more productive.
How We Practice Knowledge Transferring at Railsware
Our team chooses to document the knowledge we continuously accumulate using software like Confluence and Jira Smart Checklist.
HR is one of the simplest and most coherent examples of using and sharing knowledge in an order to both maintain a clear and cohesive process and to educate someone completely new to the company.
That’s why I’d like to illustrate the differences between kinds of knowledge and approaches to sharing the knowledge through the perspective of the onboarding process we use at Railsware.
Knowledge transferring during the onboarding period: Vision and Strategy
During my first day at Railsware, I had a lot of calls and meetings. The very first one was with my project coordinator, Denis. We never talked about the scope of work or how to do task X or accomplish result Y.
Denis sat down with me and we talked about vision and strategy.
Why is this important? Well, I didn’t join the company to write blog articles. And the company did not need articles for the blog.
Business needs to make money. Being a product studio, we make money from our products. Products do not sell themselves. Ergo, everything I write should flow down the chain and meet the higher goal of making money through selling products to customers.
Why is this important?
Well, I could write a lot of stuff for SEO, get a lot of traffic, and call it a day. The thing is, traffic doesn’t make us money. A useful, actionable article people can read and implement to improve their processes, on the other hand, might.
That’s why I can’t stress enough the importance of sharing your vision and strategy with newcomers. Not through a Wiki or doc, but by sitting together and talking about where you want your company to be headed.
Wikis & Confluence
There are certain things every member of your team needs to know. Company history, corporate culture, and tidbits of accounting or benefit policies are great examples of high-level stuff.
Then there are more down-to-earth, boots-on-the-ground examples like where does one get the tech they need to work or basic office utensils, how do the compensation or other policies work, what needs to be done in terms of accounting or legal, etc.
Knowledge like this works exceptionally well when documented and compiled into a unified playbook everyone gets access to. We use Jira’s Confluence to work with these kinds of info.
After some trial and error, we concluded that the best format for this centralized hub of knowledge is a Wiki. This Wiki is the first thing our HRs share with newcomers.
And, as practice shows, people occasionally drop by to remind themselves about certain policies, look at how-to’s, or make edits and changes when a certain process is being improved.
Note: Atlassian already has a nice guide on creating one. Feel free to give it a shot.
Jira’s Project Poster template
Taking a step down from the high-level, strategic knowledge, let’s take a look at something a little bit more grounded – the scope of a particular project.
Jira has a handy Project Poster template that’s designed with this element of knowledge sharing in mind.
Using this template requires you to have a shared meeting with the team at the beginning of the project. Grab your notes, sit down, and discuss then document the knowledge about the project in a way that’s simple and intuitive to everyone (especially those who aren’t ‘in on it’).
Share what you are doing, why, and for whom. What will be the deciding factors of a project’s success or failure? What will you use to measure these results?
Having answers to these questions will make onboarding – and even sharing updates with the stakeholders – so much simpler.
When it comes to domain-specific knowledge, our Human Resource Managers direct newcomers to project managers and onboarding coordinators inside their respective teams. This is the stage where people learn about the ins and outs of their trade.
This is where the real magic begins.
Again, through trial and error, we concluded that a checklist is the most efficient method of sharing knowledge regarding a certain process. I’ll use the process of writing this article as an example.
Why a checklist?
- It clearly illustrates what needs to be done.
- In the case of the Smart Checklist, you can tag people, convert checklist items into sub-tasks, set deadlines, or use collapsible fields to pack a checklist with useful info, guides, links to Wikis, and all sorts of other instructions.
- Checklists can be automatically added to new issues of a certain type, removing the necessity of re-work or making mistakes and corrupting a process.
- You can easily see and track the progress.
- Checklists contain useful links to navigate via tools, docs, or communication channels.
In simpler words, I have my entire workflow in front of me. I’ll definitely have the ALT tags in images and I won’t forget to use external links. And my colleagues will know what I am doing or which stage I am on at the moment.
Some extra tips
Here are a few handy knowledge-sharing tips you can implement in your organization. I tried to mention the most actionable ones you can implement relatively quickly.
- Encourage a habit of documenting: Something as simple as meeting notes can (and as practice shows – usually does) grow into an implementation plan for a new feature, piece of content, improvements to existing processes, or even an entire project. Having perspective on where the idea came from and how it came to be will become a great starting point for an addition to the product’s Wiki.
- Use tech that promotes safe collaboration rather than disruptive security: Noone is saying you shouldn’t password protect your knowledge but having a shared folder or an app like BitWarder or 1PassWord beats relying on a password-protected Excel file the team can’t access when Steven is not around to share permissions. Do note that some of your data does indeed need an extra layer of protection, but this is not what we are about here. I am talking about the knowledge your teams need to access regularly.
- Focus on creating practical, bite-sized pieces of content: Whenever someone is looking for a solution they probably don’t have the time to browse through piles of documentation. A collapsible item in a checklist can give a lot of insights on how one should proceed or where one can learn more.
Why knowledge transferring is important? (What’s in it for you)
Now that we’ve dived into the world of knowledge-sharing culture, let’s talk about the gains. What does the business actually get from relocating its knowledge hubs from kitchens and cubicles into the digital world of content?
- 100% of the knowledge is yours to keep: Having a centralized knowledge hub and well-documented processes removes the Bus Factor from the playing field.
- Your key players have more time to focus on their tasks: The math on this one is quite simple. The less a manager, lead, or architect needs to spend looking up answers or browsing through documents to find the right one, the more they’ll have to be productive in much more meaningful ways.
- Self-learning is promoted, thus creating a very fruitful culture in the company: We’ve found that people who are actively looking for answers are much more pleasant to work with. We’ve also noticed that people who share this mentality choose to solve challenges rather than partake in the ‘blame game’.
- Knowledge is shared as part of a process: A well-documented Wiki or a checklist in a task offers much more context than a simple answer to a question. In simpler words, your employees will not only learn about how they can do a certain thing but also about its place within the process as a whole.
Would you like to improve your knowledge sharing with Smart Checklist for Jira? Give it a shot for free.