{"id":295,"date":"2022-06-27T14:45:30","date_gmt":"2022-06-27T14:45:30","guid":{"rendered":"https:\/\/titanapps.io\/blog?p=295"},"modified":"2025-08-26T08:55:41","modified_gmt":"2025-08-26T08:55:41","slug":"knowledge-transferring-in-jira","status":"publish","type":"post","link":"https:\/\/titanapps.io\/blog\/knowledge-transferring-in-jira","title":{"rendered":"Knowledge Transferring in Jira"},"content":{"rendered":"\n

Some say that knowledge is power. I say that knowing how many times Ross said \u2018we were on a break\u2019 throughout the entire run of Friends<\/a> has a 0.001% chance of having a practical application other than winning a silly bet on a night out for drinks.<\/p>\n\n\n\n

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\u2019t find any useful applications for this type of knowledge. <\/p>\n\n\n\n

Moreover, the vast availability of knowledge forms a mirage of accessibility. All you need to do is ask, and you\u2019ll have your answer. Right?<\/p>\n\n\n\n

The knowledge that\u2019s 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. <\/p>\n\n\n\n

Moreover, even if the employee – let\u2019s 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.<\/p>\n\n\n\n

How We Practice Knowledge Transferring at Railsware<\/h2>\n\n\n\n

Our team chooses to document the knowledge we continuously accumulate using software like Confluence and Jira Smart Checklist<\/a>.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

That\u2019s why I\u2019d like to illustrate the differences between kinds of knowledge and approaches to sharing the knowledge through the perspective of the onboarding process we use<\/a> at Railsware.<\/p>\n\n\n\n

Knowledge transferring during the onboarding period: Vision and Strategy<\/h2>\n\n\n\n

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. <\/p>\n\n\n\n

Denis sat down with me and we talked about vision and strategy. <\/p>\n\n\n\n

Why is this important? Well, I didn\u2019t join the company to write blog articles. And the company did not need articles for the blog. <\/p>\n\n\n\n

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. <\/p>\n\n\n\n

Why is this important? <\/p>\n\n\n\n

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\u2019t make us money. A useful, actionable article people can read and implement to improve their processes, on the other hand, might. <\/p>\n\n\n\n

That\u2019s why I can\u2019t 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. <\/p>\n\n\n\n

Wikis & Confluence<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Knowledge like this works exceptionally well when documented and compiled into a unified playbook everyone gets access to. We use Jira\u2019s Confluence<\/a> to work with these kinds of info. <\/p>\n\n\n\n

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.<\/p>\n\n\n\n

And, as practice shows, people occasionally drop by to remind themselves about certain policies, look at how-to\u2019s, or make edits and changes when a certain process is being improved.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Atlassian already has a nice guide on creating one. <\/em>Feel free to give it a shot<\/em><\/a>.<\/em> <\/p>\n\n\n\n

Jira\u2019s Project Poster template<\/h2>\n\n\n\n

Taking a step down from the high-level, strategic knowledge, let\u2019s take a look at something a little bit more grounded – the scope of a particular project.<\/p>\n\n\n\n

Jira has a handy Project Poster template<\/a> that\u2019s designed with this element of knowledge sharing in mind. <\/p>\n\n\n\n

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\u2019s simple and intuitive to everyone (especially those who aren\u2019t \u2018in on it\u2019).<\/p>\n\n\n\n

Share what you are doing, why, and for whom. What will be the deciding factors of a project\u2019s success or failure? What will you use to measure these results? <\/p>\n\n\n\n

Having answers to these questions will make onboarding – and even sharing updates with the stakeholders – so much simpler. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Checklists<\/h2>\n\n\n\n
\n