Subscribe to our newsletter
Stay up to date with our latest news and products
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!
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.
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.
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.
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
At the same time, one can imagine a common track that everyone must master, which includes necessary knowledge of Git, review processes, and other activities where everyone needs to be leveled.
This way, a new collaborator would spend a few days almost following the tracks, learning about each technique, tool, and important library, so that when they take on a task, they already have the necessary foundation to advance with confidence.
A Competency Matrix is a tool widely used in industries and other segments, with the main objective of crossing the competencies that the company needs with the competencies of the employees.
From my observations, it fits best in companies where people from a certain department need to know delimited processes. For example, in a laboratory, an administrative department employee should know how to issue reports for agreements, follow up on health plan payments, etc., i.e., a more limited amount of knowledge.
It also proposes to monitor soft skills and other relevant subjects for a specific position. But it seems limited in dealing with an environment with so many changes, as happens in a technology team.
Some companies use Mind Maps to manage knowledge, including, for example, proficiency levels in languages and hobbies. In my experience, with more than half a dozen people, it becomes difficult to keep all the information organized and easy to follow.
While in an administrative department of a laboratory, one person needs to know four or five systems and handle about 12 processes, in a technology company it is common for a developer to know more than 60 "things," which makes this area so unique.
Dealing with knowledge in a technology company can be a challenging task, but when done well, it can generate great results in the short term. There are some techniques and tools to help you and dedication and continuity is necessary for the results to be felt by everyone.
After observing these issues over the years and trying out different systems, spreadsheets, scripts, and even Notion to keep knowledge organized, I suggested creating something new with a specific focus on these problems.
So we developed Roadmap, a tool for managing knowledge and learning paths. The project is currently in BETA but can already be used and is free for teams of up to 50 people.
Roadmap has made it easier for us to understand the main players, training needs, knowledge bottlenecks, and manage learning paths to keep our team constantly evolving.
Interested? Visit learningroadmap.io to create your account and try it out. I look forward to your feedback!
Dedicated software development leader with 20 years of experience in dealing with dozens of projects in diverse industries, Tiago has acquired throughout his career great knowledge in solving problems using the right technologies and has developed tremendous technical skills in many platforms.
How about enjoying the Web Summit Rio side events, participating in groups, connecting with interesting peers, and even discovering stunning spots?
We compiled an objective list of the current side events and groups, so you can get much more of your days in the wonderful city.
What is the cost to develop the app? How many days or months are required from each professional on the team? How much do I need to know about each task to arrive at a realistic estimate?
Developing a system is a project full of details, and estimating its size before making a proposal or starting its development is essential. An error in understanding the duration and work required in a long project can mean failure, including the annulment of any financial results.
Continuous Integration and Continuous Delivery is the automation of the building, testing and deployment processes. These practices have proven to make coding more efficient. Learn more about it here.
Stay up to date with our latest news and products