Introduction
Hello! I’m @raven from Mercari’s Engineering Office.
This article is an English translation of a Japanese article I wrote for Day 14 of the Mercari Advent Calendar 2024 series.
Mercari’s Engineering Office is a team that works to solve problems and challenges faced by engineers across Mercari Group. Improving knowledge management for our engineering organizations is also part of our job.
When I joined Mercari in April 2024, I felt that it was hard to find knowledge. I had to ask coworkers where I could find the information I needed; I didn’t know where knowledge owned by other teams was stored, nor how to go about looking for it.
Right around the same time, we carried out an annual survey targeting engineers across Mercari Group, and internal knowledge ranked as the area with the highest level of dissatisfaction. Just as I was pretending to be surprised, I got a request to be part of a project to improve knowledge management—talk about luck!
What you’ll find in this post
We haven’t reached the finish line with this project yet, but I’d like to share what we’ve done so far to increase satisfaction with knowledge management among engineers. Specifically, I’ll talk about the following two points:
- What approaches we took to solving the problems faced by engineers
- How we drove the project across Mercari Group
I hope this post is useful to anyone out there facing similar knowledge-related problems in their own organization.
Dissatisfaction with knowledge management among engineers
Improving knowledge management is much easier said than done. It requires asking engineers to make changes to the culture of documentation they’ve cultivated over the years. This is a difficult process even within just one organization; the scope of my team had just expanded from a single product division to all engineering organizations in Mercari’s Japan Region, including our India office. That made this knowledge management project a great initiative for us, perfect for our mission of solving problems and challenges faced by engineers across Mercari Group.
We began by analyzing engineers’ responses to the survey that showed dissatisfaction with knowledge management. The major sources of dissatisfaction seemed to be the following points:
- Knowledge is scattered across multiple platforms, making it hard to search for or find what you’re looking for
- There are many different knowledge platforms, but each organization has their own rules for building knowledge, so the knowledge isn’t centralized or organized
- There isn’t a standard format for documentation, so even the same type of document may have different content and be written in a different style depending on the organization that owns it
- No one is actively maintaining knowledge, so there are many cases of outdated or redundant knowledge
- There are no training programs or guidelines regarding knowledge management
- Some documents are in English and some are in Japanese; the language barrier makes it hard to share information
If you’ve made it this far, you’re probably nodding in agreement with at least some of these points.
The loss caused by not managing knowledge appropriately is greater than any of us could imagine—for both the company and for engineers.
We started this project envisioning a world where our engineers could share and find information stress-free, across organizations and languages.
How to approach each of these problems
After looking through the comments from engineers, we determined that we needed to solve the following problems:
- Knowledge is scattered across multiple platforms
- Knowledge isn’t organized because there are no consistent rules
- Because of the first two points, it’s hard to search for or find what you’re looking for
- Information isn’t shared widely enough because of the language barrier
- Documentation isn’t standardized
- Knowledge is not appropriately maintained
- There are no guidelines or training programs about knowledge
In the next section, I’ll share our approaches to tackling each of these problems.
Problem: Knowledge is scattered across multiple platforms
We mainly use three tools to create documentation:
- Confluence
- Google Docs / Slide
- GitHub (knowledge collected and published as webpages)
When it came time to select a platform to manage our knowledge, there were many different opinions about using our existing assets. For example, one dramatic approach suggested was to use Confluence as our only platform. But when we compared these products, we determined that each of them had different advantages.
| Product | Advantages |
|---|---|
| Confluence | Page creation is intuitive; knowledge and knowledge domains are easy to manage |
| GitHub | Offers features such as version management, reviews, and approvals |
| Google Workspace | Seamlessly integrates with various collaboration tools |
After a lot of discussion, we decided that our policy would be to use Confluence as our main knowledge platform, and use other platforms as necessary to supplement the features that Confluence is missing.
Problem: Knowledge isn’t organized because there are no consistent rules
We decided on a flexible design for our knowledge platform in order to leverage the advantages of each tool, but allowing the use of multiple tools runs the risk of not actually solving the problem of information being scattered across different tools. To prevent this, we used organizational structure information to automatically create Confluence pages for each organization’s knowledge domain dedicated to storing the knowledge of all teams in that organization. We had each team fill out a standardized template with information such as their communication channels, GitHub repositories, and design specs, to assemble team information that is worth sharing internally as knowledge on Confluence in a consistent format regardless of organization.
We chose to organize knowledge in this way mainly because, given the current organizational structure and chain of command, categorizing the information by team would make it easier to implement governance and drive projects forward. We also considered categorizing the information by product or by tech domain, but we thought that as the first step toward improving knowledge management, the team-based approach was the best way to clarify who is responsible for what knowledge as we move ahead with this project.
Organizing information on the same team level across all of Mercari Group also had the important purpose of enabling engineers to understand the information and knowledge held by other organizations more easily. Personally, I feel that this was like drawing a map by hand of an uncharted world—it’s rough and not very detailed, but it still gives us a broad view of the different organizations across the company.
Problem: It’s hard to search for or find what you’re looking for
By linking information on Confluence, we made it a little easier to follow a link trail to each organization’s knowledge. However, just placing links doesn’t make it dramatically easier to search for knowledge.
You may have noticed the arrow from Confluence to LLM + RAG in the knowledge platform diagram. From the beginning of the project, we’ve been working with our Large Language Model (LLM) Team to see if it’s possible to use a retrieval-augmented generation (RAG) solution for information to enable engineers to search engineering knowledge on Confluence. The LLM Team had already imported the main sources of engineering knowledge on GitHub into a RAG, so we decided to do the same for information on Confluence that would be useful to engineers and provide that knowledge using internal LLM systems.
Problem: Information isn’t shared widely enough because of the language barrier
Engineers who can’t understand Japanese well won’t read documentation in Japanese. Engineers who can’t understand English well won’t read documentation in English. It may seem obvious, but breaking down the language barrier is crucial to enabling engineers to seamlessly share knowledge.
That said, we don’t have the resources to write all documents in both Japanese and English, and Confluence’s translation plugin cost scales based on use, so using Confluence as our main knowledge platform comes with a potential impact on cost.
Thankfully, we already have LLM and RAG solutions, so we decided to use them to solve the language issue for knowledge that should be shared in both Japanese and English. Using our LLM system, engineers can ask questions in Japanese and receive answers in Japanese, even if the content comes from documentation written in English. We expect this to facilitate seamless sharing of knowledge regardless of differences in language and contribute to engineers discovering knowledge they may not have had the chance to find before.
Problem: Documentation isn’t standardized
Before this project, most documentation was written using templates that each organization had defined as their own standard. For more complex cases, some organizations even had multiple different templates.
Using one standardized template across organizations ensures that each document provides information in the same level of detail and enables anyone to create documentation with just the right amount of information. It also reduces the stress readers may face when they try to find and understand the information they’re looking for. Therefore, we decided to first recommend the use of standardized templates for the types of documentation most frequently created by engineers.
Problem: Knowledge is not appropriately maintained
In order to ensure that knowledge is kept up to date, we enhanced the “health check” tool we use for documentation on Confluence. This tool enables us to monitor and visualize the freshness of information, the usage status of standardized templates, and other data. We periodically request that engineers run these checks as a way to manage knowledge maintenance.
Problem: There are no guidelines or training programs about knowledge
To help engineers understand our knowledge management initiatives, we created guidelines on Confluence regarding choosing documentation tools and using standardized documentation templates. We plan to expand these guidelines going forward.
That said, we know that not all engineers will read through the guidelines and immediately change their habits to follow them. We used our internal e-learning system to create a training course on our fundamental approach to knowledge management and the content of the guidelines, and made it a mandatory course for engineers in order to promote understanding of the guidelines and a change in mindset regarding knowledge management.
In addition to this training, we are also taking other actions to ensure that engineers understand how important knowledge management is, like sharing information at company-wide meetings for engineers and holding periodic open-door sessions.
Driving a Mercari Group-wide project
Just deciding how to approach the problems faced by engineers isn’t enough—you can have the best idea in the world, but it’s meaningless if you can’t commit to and follow through with the plan.
In this section, I’ll go over some points we were particularly careful about when driving this project across Mercari Group.
- Project design
- Visualization
- Forming a knowledge management committee
- Following up with information owners (IOs)
- Announcements and awareness-raising activities
Project design
Throughout this knowledge management improvement project, we carefully considered the outline of our initiatives, the schedule, detailed tasks, risk assessment, the plan for spreading awareness of appropriate knowledge management, training, monitoring plans, and more.
We also created a project management Confluence page with this information and worked to actively publish information to increase recognition of our initiatives among both project members and other employees.
Visualization
We visualized our plans and initiatives using diagrams to ensure that they would be easy to understand for project stakeholders and other employees. In meetings, using visual images of our initiatives helped participants understand the content more accurately and quickly, enabling seamless understanding across the group.
Forming a knowledge management committee
Even within the same company, different organizations have different cultures and habits surrounding documentation.
In order to drive this project forward across Mercari Group, we first selected information owners (IOs) to act as representatives of knowledge management within each organization and formed a knowledge management committee. There were about 20 IOs in the committee. We worked together with these IOs to consider how to share documentation between organizations, the best policies for documentation across the group, guidelines, training content, and more. When collecting knowledge owned by each team, each IO asked the managers in their organization to update the information. They also encouraged the members of their organization to take the training course. Thanks to this committee, we were able to work together to improve knowledge management.
Following up with IOs
In an ideal world, IOs would be able to focus all of their time and energy on the knowledge management project, but in reality, they’re busy with their own work. Not all IOs can participate in committee meetings, so we assigned each IO a representative project member in the Knowledge Management Team and held individual one-on-ones to follow up with IOs and minimize any information gaps.
Announcements and awareness-raising activities
Just releasing guidelines or training programs is pointless if engineers don’t actually read them. We do make announcements on communication channels, of course, but announcements aren’t enough to ensure that all engineers know about the guidelines and programs and take the appropriate action. We worked with IOs to apply knowledge management methods in their organizations and actively raised awareness of the importance of knowledge management among engineers through company-wide meetings for engineers and open-door events.
Conclusions
In this post, I wrote about our initiatives to improve knowledge management in our engineering organizations and key points for driving the project across Mercari Group.
Knowledge management initiatives don’t stop when the project is over; we still have to periodically reflect user feedback in our guidelines and training programs, expand and encourage use of standardized templates, import knowledge into LLMs, and more. We will continue to strive for further enhancements to a sustainable knowledge management culture for engineering at Mercari.
Once we have established a knowledge foundation for engineering, we’d like to expand our knowledge management initiatives to product and business areas as well to cover the entire company.
If you made it this far, I hope our experience provided some valuable insights.
Thank you!
