Managing knowledge and learning in developer teams

When we think about a software development company, we immediately think about the large amount of knowledge that exists there. People coming and going, projects starting, others needing to be kept running.

For those who see it from the outside, it seems as if the developers in a team are true geniuses, bringing all of their encapsulated knowledge, ready to be used. For those who see it from the inside, they know how many areas of knowledge and levels of understanding exist there. There are languages, frameworks, libraries, tools, methodologies, paradigms, and many other dimensions of knowledge.

Some factors make this task even more difficult, such as when a collaborator has mastery over a large part of the company's knowledge, technologies, and processes, and one day decides to leave. It is then necessary to deal with the "loss" of all that knowledge.

For this and other reasons, managing the knowledge of a developer team can be a very complicated activity. But don't get discouraged! Follow me in this post, as I will talk about a very interesting solution at the end, the Roadmap!

How to know “who knows what” in a technical team?

Taking a record of the knowledge each developer in the team has is not simple. A full-fledged developer can master several dozens of "skills", some with high knowledge dominance, some being improved now, while others are only at an exploratory level.

An initial idea is for each member to record their skills and knowledge in a shared document. Another very efficient way is the leader's vision of the team, who should observe the work dynamic to see which members know best what is being done, which can teach, and which need to study a little more.

Keeping this record up-to-date can also be challenging. Since in the technology area, it is necessary to always learn, the knowledge levels are always moving.

This task can be so complex that most companies simply cannot carry it out. A spreadsheet made three months ago no longer represents reality.

Dealing with context and volume of information

At the same time it's important to understand the knowledge of the entire team and the skills needed to handle everything the company works on. This can create a heavy cognitive overload on a new developer on the team. The volume of knowledge required to work in a company and on a project can weigh heavily on the team.

A suitable way to handle the context is to have a list of the knowledge required per project. This makes it clear that a new employee working on "Project A" will need to learn a certain list of skills. The same would apply if a developer switches projects and needs to undergo a leveling process when joining the new team.

By keeping the knowledge boundaries closer, the company saves on unnecessary training, time, and especially the amount of information in the developer's head.

How to deal with the leave of a developer in the team?

Something that often causes a balance in development companies is the departure of a good developer from the team and realizing that some of the knowledge he had, no one else has on the team.

If this is realized before his last day of work, the team will still have some time to transfer the knowledge. Not all knowledge can always be transferred, sometimes some things will be only superficial, but in general the departure occurs without a clear perception of what knowledge is being lost.

If the lack of knowledge in the team is only noticed after the departure of that collaborator, it is a big problem to handle this loss smoothly. Someone will need to learn something new (unknown to everyone on the team), and in a few days become responsible for a part of a system.

In an ideal world, we would know in detail the knowledge of that collaborator, see his peers, and create an "emergency" learning path, at least in the most critical skills.

What to learn when coming to work with the company?

Just as output can generate a demand for study within the team, the entry of a new developer into the team is a reason for learning.

The ideal is that each project has its own learning track, where it is possible to know who dominates each aspect, as well as what is the minimum level of understanding necessary for each knowledge. It may be necessary to master a framework and some critical libraries for the project, while others just need to understand the basics