How to create great developers: The Skill Matrix
Some years ago, guided by the feedback of my department manager and mentor Borislav Ervaćanin, I started thinking about how unstructured our system for learning really was. He was a great mentor and was frequently pointing me to work on some skills that were not on my radar, like logging and exception handling. My thought at the time was: what’s there more to learn about this? But there was. A lot.
Having this uncanny ability to teach people, Borislav had always played it by ear, intuitively figuring out what I needed to work on next to become a good developer. Of course, not everybody had the same extraordinary ability. I certainly didn’t — I needed a mold.
A few years later, I became a department manager myself.
As a department manager my job was now to mentor a dozen other people, but I still had no mold. So, I decided I was going to describe the problem and then look for the solution on the internet. The problem manifested itself in several ways:
- Mentoring: having no baseline, it was both hard for the mentor and the mentee to envision a personal development plan for the mentee
- Evaluation: having no common system of measurement, managers could not make valid comparisons between developers
- Feedback: with no reference system nor skills to inquire about, the managers were relegated to asking about a general impression of performance from team leads and other team members
With the problem now in plain sight, I scoured the internet trying to find some general approach that addressed it, but after several hours came up empty handed.
Eventually I began to look beyond the IT sector, finally stumbling upon what in some industries was known as the “skill matrix”.
The skill matrix is a list of specific skills that an employee needs to have in order to master his position, and a description of the corresponding skill levels for each skill. Employee competency can be evaluated using these skill levels.
The idea was so simple and so appealing to me that I set out to create a mockup of such a matrix for my department. My initial draft looked like this:
I sketched it quickly, keen on getting an opinion from both managers and my department.
My department loved the idea. The feelings of surprise and elation were quite apparent, as they, for the first time, observed the map of the continent they stood on. The approval was unanimous, with many ideas on how it could be used and improved.
The managers were reluctant at first, but very quickly warmed up to the idea, and agreed to put it on a test run. We picked a few people from our departments, and evaluated them against the matrix independently.
Despite the rough descriptions, we seem to have all understood what the skills were, and what the levels were, and they also seemed to roughly fit the seniority of the people we evaluated.
There was, of course, a lot to improve, but the benefits were obvious:
- The mentors and mentees could now keep track of mentee’s current competences, and easily come up with a learning and advancement plan
- The managers could talk about concrete skills and achievements, compare them, and reward them accordingly
- The managers could ask for feedback on improvement in specific skills, rather a general performance impression
- The interviewers could use the matrix to ask questions, and score the interviewee accordingly, reducing the possible seniority/wage errors made in the interview process
- Having a shared understanding of what quality work constitutes, we could reduce friction in both communication between developers and speed up onboarding on different projects
We were happy with the conclusions and goals we set upon — to add missing skills like “troubleshooting” and “IDE competency”, and to improve some of the less obvious descriptions.
Personally, I felt it also made the case that, heavy focus on learning new technologies, might be a poor long term strategy. Technologies change with rapid pace, and technology skills have very little carry-over to any other technology skill. In contrast to that, the general skills carry-over to almost any technology skill and change very slowly over time.
The conclusion from this, I though, was simple: the path to becoming a great developer was by mastering general programming skills, and learning technologies only as needed.
Besides the benefits outlined above, the skill matrix also raised a question: was the intrinsic cognitive load of a full stack developer overbearing?
It certainly looks that way. With the natural complexity of the domains, and the complexity of the projects themselves, maybe it is time to narrow down the expertise field once again.
What do you think? Is the full stack developer a realistic idea or do we need to find new ways to split responsibilities and specialize to keep being effective at our work?
Do you think the skill matrix is a useful tool? Would you try it out?
Let me know in the comments bellow.
Next time I will discuss the balance of general, technology, team and personal skills, with regards to the skill matrix and developer advancement.
This is my first published article. Thank you Nikolina Romakov, for pushing me to write this story, and Dejan Ačanski, for discussing and reviewing it.
