Towards a company skills matrix

A skills matrix lists people along one axis, and skills along another. At the intersections are indicators of whether or not a person possesses the skill, and if they do, perhaps, to what degree. In this post, I will describe how we developed our company skills matrix.

It is important for us to have a skills matrix, so that we know:

• What skills we are short of — this enables us to recruit new people who have those skills, or provide training opportunities to our own staff
• Who has a skill at a project delivery level — this enables us to form the best teams for client projects
• Who wants to increase a certain skill — this enables us to pair these staff, on projects, with more skilled staff
• Who is currently learning a skill — this enables our staff to support each other and share knowledge
• Who is able to coach others a particular skill

Here is version one…

What JavaScript and CSS skills do we have?

Data capture

There are three approaches to assessing and capturing skills data:

1. Self assessment
2. Peer assessment
3. Machine assessment

Self assessment is a fairly common approach to surveying staff skills. Often, a spreadsheet is shared amongst a company’s staff, and each staff member is asked to grade themselves against a list of skills. One of the advantages of this approach is that an individual knows more about his or her own skill set better than anyone. It’s also easier to capture and keep the data up-to-date because the whole company is providing data. The downside is that self assessments are highly subjective, influenced by any number of personal reasons.

To reduce the subjectivity of self assessing, it is probably best to avoid using too many grades, like: poor, average, good, very good, and excellent. Binary questions are, perhaps, better:

1. I know the basics of this skill (yes/no)
2. I am confident in applying this skill to client projects (yes/no)
3. I am actively learning this skill (yes/no)
4. I am willing to teach this skill to others (yes/no)

For example, if a developer feels confident that they could be part of a team that delivers a client project built mainly with React, then they should register React as a projects skill. If they are not yet at this level, but can build applications with React, they should register it as a basic skill. If they are currently studying React, they should indicate that they are a student. If they feel able and want to teach React to others, then they should indicate that they can be a teacher.

Peer assessment goes further to make things more objective. An individual (or small group) who is familiar with all (or most of) a company’s staff, can give a more balanced assessment of everyone. Also, one individual is likely to be more consistent in defining a skills list, rather than a free-for-all, which can happen if everyone is involved. The disadvantage is that one individual cannot know every detail about everyone’s skills, and they must do all of the work to capture and maintain the data.

Another approach is to let a machine do the assessments. While developing the first version of our skills matrix, we tested an algorithm which crawled through all of our code repositories, putting every commit into an index. For each index entry, the algorithm analysed the code; determined what skills were employed to write the code; and then added the relevant tags to the entry — along with the commiter’s name, the commit date, etc. So, for example, an entry might be tagged with JavaScript and React. The index could then be queried for the total commits by each developer, for every skill, and the results tabulated. The great thing about this approach is that it is zero work. The machine constantly crawls the code repositories, updating the index every few minutes. The machine is also free of bias, just recording the facts. The big downside is that it is limited to assessing skills that are easy to quantify. Also, the algorithm must be clever enough to identify every skill.

Data visualisation and filtering

Whichever way is used to capture data, a matrix is a good way to visualise it. It’s certainly possible to create something in a spreadsheet, with pivot tables and conditional formatting. However, spreadsheets can become neglected over time, and multiple versions can appear (and diverge).

Our skills matrix will get its data from our company intranet user accounts. These accounts are owned by our staff, who may edit them as they choose. For each account, we can fetch the given skills as objects, which look like this:

{

  "name": "Chris White",

  "skill": "JavaScript",
  "basic": true,

  "projects": true,

  "student": false,

  "teacher": false

}

With objects like these, the matrix, above, is generated with d3.js.

The inspiration for the two checkboxes filters (Skill level and Skill) is an online shop. Let’s say I want to buy a pair of new shoes. The starting point of my search is with every pair of shoes in the shop. I refine my search by type, then by size, and finally let’s say I want them in the colour blue. I now have a shortlist, from which I can examine the details of the pairs I like.

Here, instead of returning a list of shoes after every refinement, we return a skills matrix. We can start will all of the data, or, if we prefer, we can begin with nothing.

Beyond a skills matrix

The data object which powers our skills matrix is both simple and versatile. Therefore, it could easily be used for generating individual skills profiles (resumes/CVs). With the addition of a timestamp property, long term trends of growing and declining skills could be measured. In fact, the data could have many uses for exploring which skills exist in our company, seeing in which direction they are trending, for promoting them outside of our company…and probably more uses I can’t think of.

Originally published at 24ma13wg.github.io.