Conducting skill interviews

Steven Forth is a Co-Founder of TeamFit. See his Skill Profile.

For our work, we are often asked to investigate the skills used by an organization. We use this to seed the skill graph (the connected set of skills that grounds our people insights work). This is especially important when we are on-boarding a company that operates in a new discipline for us. We recently needed to do this for the mining industry and we are currently working with a group that is developing a competency model for the skills needed to develop adaptive responses to climate change.

We have several ways to do this. We can ingest a set of documents describing work in the industry and let our inference engine process these to identify skills and their relationships. We can invite people in the organization or industry to upload their LinkedIn profiles which we then process for skills and roles. We can analyze the public projects of organizations that work in an industry. We have done this for both design companies and civil engineering companies in the past. We also conduct a variety of different skill surveys. Some are open to the wider world, others are focused on a specific industry or function and sometimes the surveys are for a specific organization.

The most enjoyable way though, is to conduct a series of skill interviews, where we sit down and talk with people, and follow the path of skills across an organization. It took us a long time to figure out how to conduct these interviews effectively. At first we would just ask people what their skills are. This works well with some people. They can wax eloquent about what they do, the skills they bring to bear, and how they developed those skills. Unfortunately, it turns out that very few people can actually describe their skills. This has nothing to do with expertise. Some very accomplished people. In pretty much every role that we have worked with, people struggle to describe their skills and how they do what they do. We had to develop a different approach.It turns out there are several ways to enter into a skill conversation. We generally use on of the following three entry points.

• Tell us about a typical day

• Who do you work with?

• What are you working on?

Tell us about a typical day

Most people are happy to do this and do not have much trouble with it. Some people start with when they get to the office, but many people like to begin with when they first wake up. For many of us, work bleeds into all parts of our life!From this conversation, we get to activities and from activities it is a short step to tasks. Sometimes that is as far as we need to go as our inference engine is able to map from tasks to skills. When one studies existing competency models, one finds that many of them are phrased in terms of tasks and the set of tasks and the set of skills blur into each other.

Who do you work with?

Some people are very social and think of work primarily in terms of their social relationships. I am one of these in fact. Part of my own learning style is 'social' and I work in companies mostly to have the chance to work with other people. In our interviews, we generally start by asking who the person works with, what they do with this person, what skills that person brings to the work (many people who struggle to describe their own skills are articulate about the skills of other people they work with).Skills are embedded in social relations. The skills of the people we work with amplify our own skills and an accurate picture of my own skills needs to include the skills of my close collaborators and how I work with them.These connections between skills, mediated by people, and connections between people, mediated by skills are one of the main reasons that we think of skills as a skill graph (and why graph theory is a core skill for us).

What are you working on?

This is a project centric approach, which is in fact where we started with our skill platform. If you ask me in general what my skills are I am not sure how or where to begin. There are so many places I could start it is easier not to start at all. When you put this in the context of a specific project, one that I worked on with other people, the task becomes much easier.

This is also a useful entry point as it connects skills to work. A free floating list of skills, no matter how comprehensive, does not tell you much if you are not sure how they are applied. The third node in the skill graph, along with with skills and people, is applications. These applications can be jobs or roles, but one of the most important things to know is how a skill is applied on a specific project. This becomes even more powerful when one can map this to the outcomes of the projects.

We are using all three of these conversational strategies to redesign the skill profile experience. Even with all of the platforms capabilities around skill extraction and inference individual insights are important. We want people to be able to have conversations about skills with each other and with the platform. These conversations can be organized around activities and tasks, around people or around projects and roles.

Because skill development is so closely related to learning, we also want to ask people "How do you learn?" We use some version of this in our hiring interviews as learning is central to our culture. Unfortunately, for many people this is even more difficult a question than 'What skills do you have?" Over the next few years, as learning becomes a more important part of our platform, we will be looking at how to structure the critical conversations we all need to be having about our own learning.

Another approach to getting into skills and competencies is ethnographic studies. When there is time and budget, organizational ethnographers can be placed in observational or participant observation roles in an organization. This is one of the best ways to get at the behaviours in a workplace. Behaviours are an important part of our default competency model. The new competency model environment is highly configurable, but the default configuration looks like this.

Job

↳ Roles

↳ Behaviours

Skill and Learning Resources can be attached at any level. For generic competency models, not specific to a company, Jobs are generally not included. Ideally, Jobs are composed of roles plus some additional skills and domain knowledge. Roles are composed of behaviours and skills.

Teasing out the behaviours that matter most to a role is not as easy as it sounds. So far, we are not able to do this algorithmically, and we feel that the best way to get at this is through observation. When this is not possible, interviews with subject matter experts, and observation about what they say and do not say, has to suffice.

Interested in skills and competency models, and would like to share your insights?

Please take our short survey on How are skill and competency models being developed and deployed.

Interested in our work on skills and competencies? Schedule a Demo