#23 The Skills Puzzle: How a Competency Matrix Completes Your Team's Picture
Failure to properly assess your team's skills can have a detrimental effect on the entire development process and the final product. Fortunately, there is an effective tool at your disposal.
When joining a company—whether a startup, medium-sized company or large-scale organization—you will encounter teams with diverse skill levels, from junior developers to highly skilled experts. Regardless of the team composition, each member brings a unique set of competencies.
This might include expertise in building REST APIs, working with microservices, modular monoliths, relational or NoSQL databases, pipelines, specific languages, etc. The number of combinations of skills across various teams and people is almost infinite.
David: 10 years of experience in handling microservices.
Jane: 7 years of experience working with modular monoliths.
Jack: 5 years of experience with relational databases.
Jacob: 4 years of experience with REST API.
Mary: 1 year of overall experience in software development.
To ensure your project is successful, it is crucial to understand what each person on the team can do well. Try to use the team’s strengths and hide weaknesses while deciding on technologies and concepts that you will use to build the application.
While adopting cutting-edge technologies for new projects is tempting, pragmatism often yields better results. For instance:
If your team excels in Angular, switching to React will not be beneficial.
If AWS is your team's comfort zone, moving to Azure without compelling reasons could be counterproductive.
However, consider new things when:
Essential skills are missing.
Current technologies are becoming obsolete (oh, those Silverlight days!).
Potential alternatives offer significant advantages.
Stay pragmatic. The rule of thumb is to primarily use what you know and maybe add 1-2 things that fit your needs and what you want to learn.
Anyway, let’s get back to skills assessment. One popular way to handle this is using the competency matrix. It helps identify what each person knows, what they are good at, and what areas they struggle with.
How to do that?
First, the entire development team must participate in the session (or sessions; however, it is mostly just one session) when creating the competency matrix. Doing this without the presence of others is wandering in the dark, and besides, you may offend someone with an inadequate assessment of competence. This is what the competency matrix can look like:
On the left side of the matrix, list the competencies to be evaluated. Depending on your specific context, these will vary; of course, you can assess more than six.
In the central part, you will find all team members and their competency assessments. These assessments are represented using a simple color-coding system: a green box indicates an expert in this area, a yellow box shows competence with some skills, and a red box signifies no knowledge.
On the right side is a summary of the overall team assessment. To gauge if the team is competent in an area, sum up the green and yellow boxes, disregarding the red ones. Suppose most team members have sufficient skills in a particular area (as indicated by green or yellow boxes). In that case, you can factor this into your decision-making when choosing technologies.
You can make more or less accurate decisions based on the above competency matrix. For example, for your project, you can decide to use:
Rust in the backend, as everyone has some experience with it (in comparison to Java that almost no one knows.
Postgres as a database, as four people have experience with it (while only one has experience with Mongo).
REST for the API.
Treat your team's skills as a living, breathing entity—constantly evolving and adapting. Assessing strengths and weaknesses is not a one-and-done deal but an ongoing action. As the landscape shifts—new faces join, people level up, and fresh challenges emerge—your team's expertise morphs, too. Consider the case of GraphQL proficiency: Initially, you might only have one team member who is confident in this area. However, within a few months, this number could increase to three or four or extend to the entire team.
How about you? Do you look at team competencies while deciding on a tech stack, or do you treat it as unnecessary blah blah? :)