The optimal IT development team 8 - knowledge levels

I also touched on the agile principles and Scrum and how to get started with using them in practice. Then, I talked a bit about communication, collaboration, and the importance of getting to know each other. After that, I delved into how you can implement the CI/CD mindset in your team and how it can contribute to keeping the team's deliveries always up-to-date. Then I published an article that focused on conflict management and stressful situations, what can be done to prepare for them, and how to handle them in different ways. In conclusion, I wrote a bit about how you can inventory areas of responsibility and competencies in a simple yet effective way. Now, I would like to further explore this and examine how you can easily assess knowledge levels within different competency areas.

Now that we have inventoried both areas of responsibility and competency areas, the next step is to examine our team's knowledge levels. There are several purposes for this exercise, and here are the most obvious ones:

• Clarify where we need to strengthen the team's competencies and where we already have satisfactory levels. This can be used both externally with management and other stakeholders, as well as internally within the team.
• Clearly identify within the team who is responsible for what and what competencies different individuals in the team possess. This makes it easier to know whom to contact in different situations.
• Create individual development plans and clarify internal career paths.
• Provide a better foundation for both salary discussions and development conversations with the immediate supervisor.

There are many different ways to create effective scales, but perfection may never be attainable. Instead, strive to create a scale that is useful and practical. I have found it challenging to work with a scale that is too coarse and has few values. An example of such a scale could be:

1. Beginner
2. Intermediate
3. Expert

It may work if you want to quickly get an overview of a team's competency levels, but it provides insufficient information about where we should focus our resources to strengthen the team. Also, remember to explain the different levels and what they actually entail. The more concrete, the better. The following is an example of a ten-point scale that I have used on several occasions:

1. Heard of the area but never worked within it.
2. Familiar with the general concept of the area but have minimal personal experience.
3. Have some theoretical knowledge of the area but very little practical experience.
4. Possess some theoretical knowledge of the area and have worked on it to some extent.
5. Have a good understanding of the area and have worked on it. However, not completely independent.
6. Have extensive knowledge of the area and can work fairly independently. Actively seek information.
7. Have extensive knowledge of the area and can work completely independently.
8. Almost an expert in the area and actively contribute to assisting others.
9. Expert in the area, deliver presentations/seminars, and assist others both within and outside the company.
10. Leading authority in the area. Often sought after to deliver external lectures and more.

However, even with this ten-point scale as a starting point, it can still be a bit challenging to get everyone on board and achieve a fair assessment that everyone can agree on. The method that I have found to be most successful is to have individual meetings with each team member, where we collaboratively determine the level for each competency area within both primary and secondary areas of responsibility. A fun twist to this exercise is if you choose to evaluate the competencies yourself before the meeting and then ask each person to do the same for themselves. This can lead to interesting discussions.

Also, keep in mind that the scale can be made relative without any concerns. By that, I mean that you can compare competencies among team members. A concrete example of this is if you are sitting with a person on the team who believes they are at level 8 in a specific area, such as Python programming, but you believe it should be at most a level 6. In that case, you can compare with another person on the team who is highly skilled in Python and ask the person you are sitting with how they perceive their competency compared to the other person. Often, the response will be that the other person is highly competent, and it automatically leads to some self-reflection where the individual realizes they should probably be at level 5 since the highly skilled person is at level 8.

Once you have compiled all the areas of responsibility, competency areas, and evaluations, it is good to consolidate this information in a shared space so that everyone can access it easily. Also, remember to update the information regularly as things change, especially when new team members join or when someone leaves, but also when the allocation of responsibilities changes due to other reasons. You may need to create different views to present a clear understanding of each individual's competencies, but the most important one is perhaps the one to be used internally by the team. One pitfall is to be overly detailed when compiling the lists. Remember that it should be manageable and adaptable as things change. It can become cumbersome if you have hundreds of competencies listed.

But believe me, if you and the rest of the team invest a little time in getting this as good as possible, you will also reap significant benefits in the future. Think about the four points I listed at the beginning of this article. You will be able to satisfy all of them. To further enhance the value of this work, you can also consider creating an alternative view for all competencies, namely one that displays a specific competency, such as Python programming skills, and then shows which team members possess that competency and at what level. This view differs from the team's view as it focuses more on each individual's responsibilities and capabilities within the different competency areas listed, while the other view emphasizes a specific competency and lists all team members who possess that competency.

Last but not least, I want to emphasize the importance of being able to demonstrate to the salary-setting manager the exact areas of responsibility you are accountable for and the competencies you possess. This indirectly clarifies internal career paths and, in comparison to previous lists, shows how you have developed since then. This information is crucial for both the manager and yourself in upcoming salary discussions and development conversations. But enough about that. In the final article of this series, I will take a closer look at how we can implement DevOps in the team.