In the current context we often wonder how to distribute knowledge among team members and be able to have a team that is aware of its skills map, which will help us to achieve our goals.

It is common to find ourselves in product teams with expert profiles in a specific field, either technologically or in one part of the product itself, compared to others who are possibly experts in another field. This is very likely to create silos that cause the team to face situations in which, depending on the demand or objectives, the greatest weight is on one or several parts of the product at the same time, which could generate an environment where the exchange of knowledge does not flow, bottlenecks and frustration.

The practice of the “Team competency matrix” proposed by Management 3.0 can be a great partner in this purpose, although first we should reflect and ask ourselves questions about our context and where our team is at. Along these ways, we can base ourselves on the Tuckman model to learn more about where our team is and ask ourselves what stage our team is currently at. This input will be very valuable in order to know what our team lacks to advance to the next stage or consolidate the current one besides to be aware of whether this practice is adding value to us at that moment.

In the following diagram we visualize the development stages team and how they affect two axes: team performance and effectiveness or maturity. Looking at the picture it may seem that teams evolve in a linear way, but this is not always the case. It is possible for a team to get stuck in one stage of its development or even go backwards in its evolution depending on the situations it faces.

A team that is in a more primitive stage as a working group or pseudo-team will have different needs to a stage close to the potential team, so the team will demand the establishment of agreements and ways of working to move forward. For this practice, it would be optimal to look for a stage close to the potential team, or at least to have overcome the pseudo-team stage, in order to have the impact we want. It is also possible to complement it with leadership models such as David Marquet’s leadership ladders, which will offer us an input as to the leadership that is exercised.

To introduce this practice we can divide it into 3 main blocks:

In the first one we need to analyze what approach we want to give to our practice:

• Generalist approach where the objective is the self-assessment of the skills team members, whether they are professionals or not, both hard and soft skills would be included here.
• Focused on the product and the different groups or functional parts broken down by the technical competencies that exist to evolve each part of the product. For example, if we talk about a retail product we could have: the orders, inventory or logistics as domains and within each of these there would be technical skills such as ability with development frameworks, integrations with others, use of APIs, this is something that needs to be agreed and will be different from one product to another.
• Combination of both.

For the second block it is necessary to agree on the scale of knowledge level that we are going to use in our context, we could use the following in relation to colors:

• (Yellow) no knowledge, (Purple) basic knowledge, (Blue) can manage but with help, (Pink) can do it independently and (Green) expert knowledge, I can help other colleagues.
• With a focus on the product at this stage it would be perfect to define how many people are needed or required to be able to respond to each product competence.

In the third block, the following activities are grouped together:

• Each team member has previously done an internal exercise of positioning themselves in a level of knowledge of each competence and domains, which will then be shared in a space with the others in order to complete a knowledge map of the product.
• For a generalist approach, the exercise is similar but it is not so concrete; rather, the scope is much more open for each member to reflect on what skills they possess that could be useful for the team, and that would be the starting point.
• Finally, this space can be used for each member to talk about the competences they would like to develop.

This practice is also useful when we want to define a role and co-create the necessary skills. As actions that can emerge would be the use of practices such as pair programming or shadowing, also if we work by objectives or OKR we can detect how difficult it can be to achieve certain results according to our product skills map, which will make us focus on the exchange of knowledge towards one side or the other for the evolution of our product.

Finally, the outcome from this practice can be diverse, among the most remarkable: better communication and knowledge sharing flow, recognition among team members for what each person contributes, visibility of the real needs of the product team.

Image: Unsplash | Chang Duong