Building A Competency Matrix
Empowering team members in their career growth
A Competency Matrix informs how team members can grow from one role to another. Reviewing a matrix from left to right, a team member can understand how skills, on the Y axis, inform career growth along the X axis. Below is a slimmed down example for a software engineering matrix:
The benefit of a matrix like this is that it makes clear what is required for a person in one role to grow into the next role. During reviews, the team member can can point to their accomplishments within this matrix to aid in promotion discussions.
Getting Started
The best place to start is with an existing engineering ladder. For example, this might look like roles similar to Associate Software Engineer, Software Engineer, Senior Software Engineer, and Principal Software Engineer.
A problem with simply having a ladder with job descriptions is that they don’t clearly lay out how an engineer can grow from one position to the next. There may even be little overlap from one position to the next. This is where the competency matrix shines. Going through the process of creating one will help tighten up a career ladder and ensure there is a clear path from one position to the next.
The first step in this process is to be confident that the existing roles are still relevant to the organization. These roles will directly inform the X axis of the matrix. In the example above these are represented as E1, E2, and E3.
The X Axis
The X axis has three components: Role, Impact, and Focus.
Role is an individual title that exists on your ladder. For example, this may be Associate Engineer or Principal Engineer.
Impact is a quick visual of how an engineer’s work is expected to be felt by the wider team. A Junior Engineer, for example, may only have small contributions to a project. On the other hand, a Principal Engineer’s impact is expected to be much broader and deeper.
Focus helps an engineer understand where their energies should be directed. In this case, I’ve chosen to highlight “Self”, “Mentorship”, and “Advocacy”. For example, a freshly minted Associate Engineer will be better served to focus on their own growth versus advocating for technologies or methodologies.
The Y Axis
The Y axis has two components to it: a Theme and a Competency.
Let’s start with Competencies since they’re more granular. These are individual skill sets that engineers can grab a hold of. For example, you might choose “Code Reviews”, “Troubleshooting”, “Writing Tests”, “Identifying Risk”, or “Technical Project Management”. These are areas team members will directly focus on in order to grow into the next position on the X axis. Later on we’ll discuss clearly defining these Competencies.
Themes are more broad than Competencies. Themes capture multiple, similar Competencies under a single heading. An example of this may be Competencies of “Writing Tests”, “Writing Code”, and “Architecture & Design” being grouped under a “Development” Theme. Themes help categorize your Competencies but are, overall, less important to the matrix than the Competencies.
Competency Scaling
The last part of the Competency Matrix is the most important: the descriptions of the Competencies as they scale from a junior role to more senior roles. It’s important, as well, that these individual scales tie in to job descriptions to keep everything in alignment.
When writing these, be mindful that they properly scaffold the team member from one step to the next. Each description needs to be achievable from the step preceding it. A role description starting out as “An engineer observes best-practices from team members” and immediately scaling to “An engineer advocates for and disseminates best-practices” leaves an enormous gap in scaffolding how someone grows from observation to advocacy.
An example of scaffolding may be starting with this:
Associate Engineer, Security Competency
Understands the importance of security.
Which leads to the next role:
Engineer, Security Competency
Utilizes growing security knowledge to ask more senior engineers for help on making decisions which may have security implications.
Helpful Links
I didn’t pull all of this out of thin air. Not only did I spend a lot of time brainstorming to understand the various pieces of the matrix and what might best support my team members, but I also benefited from examples of teams that came before me: