Most of us know that nowadays the IT environment is dynamically evolving. Companies run multiple projects across different teams, and engineers may face similar problems as each other during development. Usually, applications require similar functionality parts like log in, charts and tables, menus, etc. In order to save development time and reduce the risk of inventing the wheel twice, we need to spread our knowledge and expertise across teams.
At Star, we follow a specific approach that allows us to keep engineers up to date with our best practices and align on ways to solve common problems.
To build such a process of knowledge sharing we follow these steps:
- Gather a group of technical experts
- Prepare a list of topics and typical problems to be discussed
- Conduct knowledge base ideation sessions per each topic and document best practices
- Share knowledge base across departments and align on best practices
- Include knowledge base review in an onboarding process for new crew members
- Review knowledge base content at least twice a year to keep it up to date
Now let’s dive into each step and see how we can implement it.
1. Gather a group of technical experts
The main goal for this group is to prepare a list of common tasks and drive the knowledge-sharing sessions later. Ideally, we should involve proactive engineers with strong technical expertise and extensive experience across different projects.
2. Prepare a list of topics and typical problems to be discussed
First, conduct a brainstorm meeting and write down all of the topics that could potentially be added to the knowledge base. You can simply use Google Sheets to define such a list. Then, set a priority for each of these topics and sort the list.
3. Conduct knowledge base ideation sessions per each topic and document best practices
The next step is to assign a moderator and identify engineers with relevant experience. Feel free to involve people from the whole department, not only from your team of experts.
It’s worth mentioning that junior engineers may have good expertise in some specific areas, and may significantly contribute during the discussion, so don’t restrict yourself by inviting only senior engineers. The goal of the discussion is to gather different opinions and align on a common approach regarding specific technical problems.
Each meeting should have a moderator to ensure the discussion is productive and focused on the main topic. Such a discussion is a great opportunity to improve soft skills and practice in moderating and mediation. We all know how difficult it can be sometimes to agree on a specific tool or approach in development, so these meetings are great opportunities for engineers in terms of self-development.
During the ideation process, the moderator should listen to speakers and document ideas. For storing these documents, you can simply use a Git repository.
Document structure may be as follows:
- Topic name
- Description and general information: A brief overview of the task, why it’s important and the general ways to solve it.
- Best practices: There should be a set of recommendations regarding tools, approaches, etc. We should add descriptions of our proven experience.
- Bad practice (optional section): Some solutions may lead to unwanted results. To save the time of other engineers, we should also describe bad practices and their aspects.
- Additional resources: We don’t want to duplicate information that is already present on the internet. If there are resources with great explanations of particular topics it’s better to simply refer to them.
- Related projects and developers: This information may save an engineer's time, as they will know the right person to ping in case they need more information.
4. Share knowledge base across departments and align on best practices
Once you’ve covered one topic it’s worth sharing it with the department so people can review pull requests and share their thoughts and comments. As a result, you may gather more great ideas regarding a specific problem and involve more people in the discussion.
When there has been a significant amount of documents created, you can conduct a knowledge-sharing event – pick a few topics, discuss them with your teammates, even add more new recommendations into the document if needed.
5. Include knowledge base review in an onboarding process for new crew members
Each new Crew member should be aligned with our best practices, so we need to include the knowledge base review in the onboarding process. This will be beneficial for new crew members because the knowledge base, in a nutshell, is concentrated experience of highly skilled professionals. Also, knowing that there is a common approach regarding your problem may save time on research.
6. Review knowledge base content at least twice a year to keep it up to date
In order to keep the knowledge base up to date we need to have a specific process and responsible people. Reviewing the content twice a year should be enough. You can involve the experts who participated in the ideation sessions previously. Engineers need to go through topics and create a pull request with changes if needed. Those pull requests can be discussed with a wider group of people and accepted.
Empowering engineers with a unified knowledge base
As you can see, all of the steps are pretty straightforward. Keeping engineers aligned on best practices may save development time and keep them from repeating the same mistakes. Therefore it’s definitely worth investing in creating a knowledge base and spreading technical expertise across departments.
