Context
At Mews, I onboarded new people into the billing area. Onboarding documentation already existed, and I had contributed to a large part of it. As long as only a few newcomers arrived, the process worked personally: I walked them through the documentation, explained the context, and answered questions.
Problem
Documentation by itself did not solve the whole learning process. When more newcomers arrived at the same time, it became clear that personal guidance did not scale well, not only because of the number of questions, but also because I needed to know what each person could already build on.
Approach
I tried to turn documentation into a shared learning process. In Miro, I prepared a board where each documentation chapter worked like one field on a map. People could create their own character with a sticky note and move it according to which part of the documentation they were currently going through.
I was not only interested in visual progress. I wanted it to be visible where each person was, where questions were appearing, and who could already help someone else. When something was explained to one person, it did not have to come back to me again next time. It could start spreading through the team.
People could leave questions, comments, or suggestions for improvement next to individual chapters. I also added elements such as a scoreboard and achievements, for example for moving through the documentation, helping others, editing articles, or actively contributing to the improvement of the knowledge base.
Goal
Gamification was not the main point. I did not want people to go through the documentation in isolation, each at a different time and each on their own. The point was to create a shared moment where the team learns at the same time, people can see one another, help each other, and one person’s questions become useful for others too.
The game elements were mainly there to reduce friction and add a bit of energy. Achievements and the scoreboard were not only rewards for “finishing a chapter”, but also for helping others, improving documentation, or actively participating in shared learning.
Outcome
In the end, the initiative remained more of an experiment than a long-term team practice. In the day-to-day flow of development, it gradually lost priority, faded out, and never became a stable part of onboarding.
Even so, I see it as an interesting experience. It showed me that documentation alone is not enough if nothing happens around it. I started thinking more about the fact that useful documentation cannot be just a link sent to a newcomer. It has to stay close to everyday work, be used by the team as a source of truth, and be continuously maintained by the people who work with it.
What I took from it
Sharing and maintaining knowledge inside a company matters, because otherwise each person starts assembling their own version of the domain. Over time, that can create different incompatible ideas about how the system works and why it behaves in a certain way.
At the same time, it is hard. People do not only want to sit at a computer, read long pages of text, and memorize things. Documentation has to be accurate, but if it is not alive, usable, and at least a little interesting, it can easily stay outside everyday work.