In this article, you’ll learn how we tried to build a structure for knowledge management within our fast growing Tech organization. This post will not cover our work on Product Documentation, but the ‘everything else’. Some of the learnings may still be useful when thinking about how to approach it.

First diagnosis — Tribal Knowledge works… to a certain extent

I joined Doctolib in September 2020, between two waves of COVID. Any new joiner goes through a first week of Doctolib Academy, which gives a high-level overview of the company, tools and people. I was impressed by the level of professionalism and the enthusiasm of our various speakers, all of which have many other things to do than presenting to new joiners. It was obvious that a lot of investment was put in to make sure new joiners feel welcome on day 1.

The next few weeks were an opportunity to get familiar with the Tech organization. Building on the principles above, I really wanted to know my future colleagues as fast as possible, to identify strong relays. So I drank a lot of coffee and met a lot of people.

After a couple of weeks, I felt I had a better understanding of the company I was joining and the most immediate challenges.

Doctolib Tech was full of energy…

What caught my eye directly was the number of ongoing initiatives designed to build the best Engineering community. Initiatives of various sizes were flourishing: DoctoMasterClasses, our mentorship program Starsky & Hutch, TechTime, hackathons, documentation, ‘front-end guilds’, you name it. But what was impressive was that all of this was powered purely by the enthusiasm and self-organization of our hundreds of engineers. Any developer willing to propose to change things is open to do so, take ownership and make it happen!

… and some of it was probably dissipated

Another obvious thing to me was that as a new joiner, there was a lot of stuff going on, but it was very hard to access information about how things were done, what was being done, and who was doing what. One very strong aspect of the Doctolib culture was its ‘tribal knowledge’, which essentially resumed in ‘just ask [insert_person]’ for many topics. Thinking about my mission, I started wondering how this would work when Tech would have 500, 700, 1000+ people. To be fully honest, I think we’ve made progress, but are still far from perfection 2 years later :)

Making Knowledge Accessible Again

Starting with those observations, our gut feeling was that the best way to have a sustainable impact would be to make sure that all the energy out there would not dissipate. And one key element is to make sure to use developers’ time most effectively by:

• Reducing the time wasted looking for things
• Maximizing the reach of processes/tools that have been created to enhance developers and build good practices

The issue with tribal knowledge is that it is hard to find, it is hard to update, and it is hard to broadcast. I was worried that Engineers would spend a lot of time doing something that would benefit only a few individuals. It felt like there were opportunities to improve the return on investment.

At the same time, there was an ongoing initiative to bring all of our functional documentation (how the Doctolib product works) on Confluence. It was a good opportunity to do something that could not be more obvious: let’s add everything somebody needs to know in a single place, through the Engineering Hub.

Simple idea, but what about the execution?

Creating an Engineering Hub may sound like an obvious idea, but what is much more challenging is to implement a useful & long-lasting hub. There is a very large risk of spending a very large effort to, ultimately, create a snapshot of how Doctolib was at the time the hub was launched.

Also, documenting ‘everything a developer needs to know’ for an organization of 200 people is quite an ambitious task for one person, especially for a non-Engineer. As I did not have the expertise about our developer practices, nor the bandwidth, I decided to be the ‘architect’ and find experts to fill the content.

How we co-built the Engineering Hub

The idea we tried to implement was to break this ‘everything’ into smaller units of knowledge which we called DoctoBasics. We had ProductBasics (everything about our product), DevBasics (everything about our dev practices), TechCultureBasics (Everything about our culture & community). After a few workshops with other developers, we finalized a list of DoctoBasics, which were grouped into categories and would have a dedicated page. Examples of Doctobasics? “Bugs”, “Tests”, “Code Reviews”, “Career Growth”.

Managers were then asked to identify ‘DoctoBasics Ambassadors’ whose role would be to fill a V0 of the content. They had only 1 simple mission: make sure that any new Doctoliber who wants to know about this DoctoBasic is able to find it through this page. For a V0, we did not even care if the content was a vulgar link to a slide deck or Github wiki, what mattered was that it was the unique source of truth, and it was accessible.

A few tips that helped us ramp up our ‘knowledge’ game

We applied one golden rule, in a nutshell:

“If a Doctoliber finds the information on this page: it is the latest official source of truth. If a Doctoliber cannot find the information through this page, it’s because the information is not documented anywhere”.

Why? Duplicated information is your worst enemy. It requires more effort to maintain properly (twice the effort if you have the same piece of information at two different places. Third if you have three. And so on…). On top of that, if one of your duplicated information is partially up to date (correct somewhere, and outdated elsewhere), you introduce some risks into your daily operations. Your changes will be less likely to be properly adopted, and some of your teammates will probably still use the old improper ways/tools. And ultimately, people lose trust in the documentation.

On top of this general philosophy, here are a few takeaways from this experience.

• Knowledge accessibility is as important (if not more) as knowledge availability. Usually, companies do not run out of content. But as we produce more and more information, the bottleneck to information sharing becomes the ability to find the right source quickly, not to produce that source. Failing at accessibility means a lot of wasted time, duplicate sources of truth (‘I did not know it already existed’), or people giving up on finding the right information and taking shortcuts. In any of those situations, it means you will get nowhere in your mission of reducing ‘waste’. I have two tips for that: 1/ create an intuitive architecture for your documentation, 2/ ensure all pages are tagged properly with the right keyboards to be found through search. For Confluence, you can add labels.
• Design the architecture first, and don’t be afraid of blank pages/placeholders. Because of the tribal culture, a lot of content was not written anywhere. Even with an ambassador system, it’s hard to motivate people to document global processes. As such, there would be a lot of empty pages. What we realized was that the architecture, even with blank pages, nudged people into filling the gaps without even being prompted. And those gaps became, by default, the unique source of truth. As such, we were able to grow that base in a very decentralized way without creating anarchy.
• New joiners are your best ally to change habits. We like to say that 1/3rd of the 2022 Doctolib employees are not even aware they will work for Doctolib. Why is this important? Because new joiners rapidly become the majority, and they can change habits. On top of that, they are usually more inclined to write more content as they experienced the pain of not being able to find the information. So, one thing we did was to create an Onboarding Hub with everything they need to know, and introduce it on Day 1. And every month, I’m surprised to see that new joiners have updated the content naturally.
• Build a deep network to scale yourself — this was the first instance where one of the principles helped me a lot. Identifying the right people to carry the task has been an extremely effective way to have a large impact with limited effort. If you set the right high-level guidance, and find the right people, you won’t have much remaining work to do. The method for that was to ask managers who know who you can rely on for the task.
• … but don’t oversubscribe your volunteers. Engineers have a job and documentation is rarely their favorite activity. I realized that it’s better to ask them to commit to 100% of a very simple task (e.g. just putting the links) than have a much more ambitious goal. Usually, when I asked something that required a lot of investment (e.g. documenting a process from scratch), it led to no result at all. So always make sure you adjust your ambitions to people’s time, or give them this time.
• Focus on the user, not the tool. There are many solutions out there. The best one is the one that works. It’s a principle we apply for our products at Doctolib (#UserFirst), we also apply it for our internal tools. So, if I had one tip — focus on deeply understanding your users’ needs, and then find the tool that suits them.

What now?

18 months later, the Engineering Hub has been the backbone of our contributions — it has grown organically and there is more up-to-date accurate content than there ever was. It is also a great way to bring alignment, which is obviously a big challenge in an ever growing company.

We have also invested a lot in Product Documentation (thanks to the amazing Product Operations team). This documentation is key to help new joiners ramp up, outsiders understand how a feature close to their scope works, or technical support teams to understand whether something is a bug or not.

Don’t get me wrong, there are still some hiccups. We have a good V0, but there is so much more we can do to curate and complete the information we have. The biggest challenge we face is around team knowledge. Getting an accurate way to know who is working where, and on what, is extremely challenging. It’s important because as the company grows, dependencies increase but become harder to find. We already have multiple sources of truth (Workday, Confluence, and many other sources), all of which have their advantages and disadvantages. If you feel you’ve solved this problem for 200+ people, please let me know :)

What next?

Having good knowledge sharing in the company will not solely come from good practices and processes. As you grow, you have to expect that the amount of information generated will keep increasing exponentially. If the number of things a single developer needs to know follows the same trend, we’ll obviously hit productivity bottlenecks.

As such, part of the solution also comes from adapting our organization and architecture. This is why, in parallel to scaling our knowledge, we are actively investing in reducing the amount of knowledge that is required to do your job well, also known as ‘Making Doctolib Small Again’.

If you want more technical news, follow our journey through our docto-tech-life newsletter.

And if you want to join us in scaling a high traffic website and transforming the healthcare system, we are hiring talented developers to grow our tech and product team in France and Germany, feel free to have a look at the open positions.