The Support skills matrix
I know kung fu! Also MariaDB.
Troubleshooting any reasonably complex software product is going to require several related skillsets. Maybe you’ll need to know about Postgres databases, Windows and various Linux distributions, and Terraform. Maybe you’ll need to be able to investigate SSO configurations for OIDC and SAML. Maybe your product integrates with dozens of other third-party technologies, any combination of which a customer might have deployed. At some point, things get sufficiently complex that it’s nearly impossible for a single support engineer to know everything there is to know about troubleshooting. But that’s fine, and expected. That’s one reason you have a team, after all! Everyone is going to have overlapping skill sets, and if you receive a support ticket for something you’re a little fuzzy on, say VPNs in MacOS, there’s probably someone else on the team who knows more about it.
Enter the skills matrix
At that point, however, the problem becomes ‘who is that person, and how do I find them?’ On small teams, it’s easy to know that Jeff is our Windows guru, Jane knows Oracle, and Paulette spent years reading firewall logs. But as a team gets bigger, even knowing who knows what becomes an insurmountable task. All you can do is ask around until you find the SME (subject matter expert), all the while the support ticket you’re trying to address is waiting for a response. That’s where the skills matrix comes in, and why it’s one of the most effective knowledge-sharing tools you can deploy to your team.
The skills matrix provides one central location for engineers on your team to go to find out:
Who knows about technology X?
Who is the acknowledged SME on the team for X?
What skills are lacking on the team that I should consider learning next?
Building your team’s skills matrix
The example below is a good starting point, but you’ll certainly want to make some changes to it for your own team. At a bare minimum you’ll need to change the list of applicable skills, as it will vary significantly from team to team, even in the fairly constrained world of B2B SaaS. Spend some time with other team leaders to build up a comprehensive list of technologies and related skillsets that are important to support engineers on your team. Before finalizing the list, however, be sure the rest of your team has a chance to look it over and suggest changes, to make sure that everyone in the support organization is bought into the skills matrix as a useful tool.
Once that’s done, the fun part begins. Fill in your own row first, then give everyone on the team a chance to do the same for their own row in the spreadsheet. Give everyone a week or so, then look it over yourself. It’s important that everyone gets a chance to self-evaluate their own skills, but make sure that this self-assessment is based in reality. If you or a team lead have questions about any individual’s list of their own skills, discuss it directly with them.
As for the SME designation, nobody should be determining that on their own. My recommendation is to speak directly to everyone who is proficient or learning a given skill to ask them who they think is the most knowledgeable on the team. Usually a consensus will become clear very quickly. If you think designating SMEs on your team will cause more friction than it’s worth, due to disagreements about people’s skillsets or general ego, you don’t have to use that category! But if that’s your team dynamic, I’d suggest you try to alter it. Ego has no place in a well-functioning support team.
Finally, the skills matrix must not remain unchanged over time. Engineers should be updating their own skills list regularly. Make it a part of your quarterly checkins with engineers to ensure they’re updating the skills matrix with new things they’ve learned, and always keep an eye out for opportunities to nudge team members to pick up new skills. For your own part, the list of applicable skills is also not static! Over time your company’s product may expand in functionality, may integrate with more third-party tools, may be available for more operating systems. Make sure you keep the full list of support-relevant skills updated as the product changes.
Further customization
Once you’ve done that, here are a few other ideas to make this spreadsheet more effective for your team:
Add a summary field to each skill to count the number of SMEs, the number of proficient engineers, and/or the number of engineers without this skill
Add a summary field to each engineer to count the number of skills in which they’re an SME
Add additional status fields beyond ’no knowledge/learning/proficient/SME’
Add other folks from your organization who aren’t part of the support team but are willing and able to assist with specific tools or technologies
A sample skills matrix
Here’s the sample skills matrix—please feel free to make a copy and customize it for your own use.
Thanks for reading Andy's Support Notes 💻💥📝!