How To Create a Team Knowledge Base?

Hello there! 👋 This is Krzysztof.

What Awaits You in This Article?

• ✅ What a team knowledge base (wiki) is and why it is important.
• ✅ My example of a team homepage.
• ✅ Examples that can be part of the knowledge base.
• ✅ A list of arguments you can use in discussions with leaders or the team to “push through” this initiative.

Let’s start

A few years ago, some time after my promotion (I previously had the mistaken belief that this was not my area), I decided to clean up the team's knowledge base, the popular wiki. There was a lot of mess, and occasionally, it took several minutes to find something. Many pages were outdated, sometimes describing processes that have long since ceased to be relevant.

I cleaned it up so it's better now. Based on that, I want to talk today about what you can do for your team.

It's important to start any changes with yourself. If you see that you can have a positive impact on your surroundings, then simply do it. Each such activity accumulates over time. Which in the context of your career brings you closer to a promotion or simply being closer to important events.

Your task for this week.

You have a challenging task this week. Update, create a new wiki page, or simply add this idea to the agenda of your dev meeting. If you decide on your own invention, then prepare a procedure of some process (I know there's never time for that). Dedicate even just 30 minutes a day to its preparation. After a few days, or maybe even sooner, you'll have something that will help your team.

You wonder why? We all remember how to do something as long as we do it regularly. It's like working out at the gym – if we stop exercising, we lose shape. After some time, everything magically vanishes. Then such a procedure described in wiki is worth its weight in gold.

What if we have it written down somewhere? Then it's awesome. We open a specific page, do something step by step. There's no need to wonder, so it reduces the chance of making mistakes or forgetting a step. Another plus is the possibility of introducing a new person into a specific process without the involvement (or with less involvement) of additional people. Which means that, for example, thanks to this you can add new value to the onboarding process of new team members.

🚀 What can you focus on?

Team homepage.

You can prepare a page aggregating the most frequently used links in the team. Such a homepage. Here you can add links to the latest UI mockups, code rules, or practices used in the team. Everything related to daily processes can also be found here.

Procedure for preparing a new release.

Describe step by step what needs to be opened, clicked, moved to prepare a new test or production build of the application. Remember that more complicated steps should be supplemented with additional screenshots.

In the process of documenting the process, it may turn out that there is something in the process that could be optimized.

Onboarding page.

Here, I don't mean that you should fully write down everything that can be helpful for a new team member. However, I suggest that you prepare (or at least initiate) a list of problems that new people encountered during their first days at work – maybe you remember what was problematic? You can talk to new colleagues and ask them for their opinions and suggestions.

However, remember to talk to the team leader (manager, team lead) responsible for hiring and managing people in the team beforehand.

A few example ideas for the onboarding page:

• Link to a page with a list of tools used in the team.
• Description of the software development process used (e.g., what scrum looks like in your team).
• Link to a page with team coding practices.
• Link to a glossary (more on this in the next point).
• Link to a page with the team structure.
• Tasks to be completed in the first days of work.

Glossary

A list of terms, acronyms, and jargon used in the team along with additional explanation. Great for new people in the team and a reminder for current members.

In my team, there are abbreviations such as: CE, CFO, KVP, PPE, WL. It's worth writing them down and explaining them concisely. Besides, explanations of the concepts you use daily will also be helpful. It's important to use the same language in a project. Therefore, if you see that the business (client) and the development team use different terms for the same thing, it means it's worth establishing one version and writing it down in the glossary.

A table can be a good starting point. It just needs to be clear.

Catalog of tools, scripts

A list of tools that the team uses along with links to them. You can add here important portals that make up the company intranet (ordering licences or equipment). If you use your own scripts in the project, you can add information on how to use them. Often, such knowledge comes up during conversations or chats with team members.

Written down once, it reduces unnecessary communication: you send a link and it's done. 👌

Pages with solutions to specific problems

Perhaps in your project, there are typical, recurring problems that are still unsolved for various reasons. It's worth documenting how to solve them. As with scripts, such knowledge often lives in chats, so it's valuable to write it down in one place.

Other ideas

• Recommended books, courses, or places on the web with knowledge (you can add a link to this mailing 😎).
• Instructions for setting up the development environment.
• HR procedures and policies – this is more a topic for your manager.
• FAQ – answers to frequently asked questions.

You know, you don't have to do this alone.

You can simply propose the idea of changes to the wiki (or its creation if it doesn't exist yet) to team leaders or at a dev meeting. Use the following arguments:

• ✅ Time-saving. Something written down once will be used multiple times. We don't have to take up other team members' time.
• ✅ Easier onboarding of new people. You give them a link with a list of basic information about the team and project. Then it's just a matter of supplementing this with additional meetings that clarify everything.
• ✅ Writing down procedures increases the stability of what they concern. Things are done step by step, not based on what we think or remember.
• ✅ The knowledge of team members is fleeting. We are still humans, not hard drives, so we often forget. Knowledge written in the wiki won't disappear when someone from the team who has had it so far leaves the project. Besides, you might have experienced a situation where, after entering the same password into the computer for months, you suddenly forget it. Therefore, even established processes that we carry out daily can one day be incorrectly implemented in one way or another. That's why a process written down in black and white is significant.

Do it this week.

If you're reading this on Monday, you still have a full week to get started on the team wiki. Even if your team members won't jump for joy over it (most people prefer to focus on coding), they will certainly use the wiki with great appreciation when they find themselves in urgent need of reminding themselves how a certain script or process works.

Recently, I've sent links to pages from our knowledge base to my colleagues multiple times as answers to their questions. A damn time saver. ⏱️

-🚀 Good luck! Please let me know what idea you came up with and how the team reacted.

KB