Through a series of posts last week, I introduced a skills matrix as a way of looking at how to balance skills across a team.
Of course, the first assumption is that you need a balance, but that has mostly been the case in any organization work I have done.
We will consider three employees, but you should be able to see how this would apply to teams of any size.
Sue, Sam, and Steve are employees who have been working together as a team for a couple of years. In the matrix below, I have plotted their current capabilities in each of the three skill areas; Technology, Information, and People.
This matrix tells me that Sue is strong in the technical skill area, but also has very good competencies with information and people. Sam seems to be the go-to guy from a general leadership perspective, with good personal balance in the other areas. And Steve is a generally good balance of all three, with no real stand-out strength. In my world, I liked having a good mix of Steves, with just the right amount of Sues and Sams.
Now, if Sue leaves (because here ongoing technical development made her eligible for a promotion) I might not want to just look in the hiring pool and say “next!” I might prefer to look at the current balance and decide where Steve and Sam could use more help. If’ Sue’s technical abilities were a major contributor to the team’s production, then I will start looking for someone in the pool who has Sue level skills. But not just anyone.
I’ve met my share of technical wizards with the interpersonal skills of an alarm clock. I need an employee who is strong technically, has the ability to collaborate, and a general good sense with information. And I need to include Sam and Steve in the selection process.
How you assess the capabilities in each of these areas is entirely dependent on your workplace needs. You may not have much need for deep technology skills, so you may base your view on a few simple interview questions. On the other hand, you might be hiring software engineers and you may want to see their work or give them some buggy code to work through. And, of course, you have to make sure your assessments do not have any unintended bias and are validated against the needs of the job.
In the next (and last) post of this series, we’ll take one more look at the matrix, only this time from the view of team growth over time.
By the way, if you have stayed with me this long, thanks! Please share your reaction in the comments.