Understanding Competencies from the Ground Up
Lee Iverson is the CTO at Ibbaka - view his Skill Profile
One of the biggest failings of many corporate competency frameworks is a lack of engagement with employees and managers. The people who are meant to use these documents ignore them and do not find them relevant to their actual work. I would like to suggest that this is often due to lack of engagement with the ground truth of people’s work during the development process and a misalignment of goals around what these models should be used for.
At Ibbaka, we’ve examined and produced or helped to produce a large number of competency models and frameworks used in a variety of corporate contexts. They often include a number of components: job descriptions, behaviour norms and breakdowns of jobs into “reusable” pieces such as roles. Sometimes, but not always, they include some description of what they are intended to be used for within the organization. This description, I would argue, is absolutely critical, since it is often the misalignment between the goals of those producing these frameworks and the possible value of these frameworks for employees and managers that is the source of the disconnect.
Why build skill and competency models?
Why build a competency model? The most commonly cited reasons are:
To illustrate how corporate values and priorities should translate down to the level of a job or role,
To provide a reference point for performance review processes,
To assist employees with career development and planning,
To ensure that job and role responsibilities are clear, open and easily understood (i.e. who is responsible for what, or what should be in a job description for recruiting?), and sometimes
To outline a set of target competencies that represent opportunities or new directions for an organization and to understand alignment between these and existing capabilities.
As you can see, this is a broad set of goals and there is no inherent guarantee that one or more of these goals will produce a competency model that will also serve the others. For example, a model built around corporate values and priorities may have little relevance other than as a “goal alignment” reference document for employees and managers. It would be powerful if we could establish a process for model building that would be able to fulfill all or most of these goals at once.
At Ibbaka, we are refining a process that can achieve the more “corporate” of these goals (e.g. 1, 2 and 5) without sacrificing relevance for actual employees and their managers as they plan and work. Ours is a bottom-up, data-driven approach to developing these frameworks that can achieve all of these goals.
Building skill and competency models the Ibbaka way
Our process can be broken down into a set of stages:
Goal Alignment
Skill Inventory
Skill Survey
Competency Levelling
Socialization and Refinement
Goal Alignment
The first stage of any Ibbaka consulting engagement is a goal alignment process in which we interview key stakeholders within the organization in order to understand the primary goals for developing such a framework. Sometimes the “higher-level” goals are irrelevant to an organization (e.g. more mature organizations may not need a model to reinforce values and priorities, but may need to understand the relationship between what their people are doing and what they might be asked to do). Without a clear understanding of stakeholder needs and pain points, it is difficult to design a model that is fit for the intended purpose.
We frame this using Roger Martin’s Strategic Choice Cascade, which we have modified to be relevant to HR and learning and development. See A simple template to apply Roger Martin's Strategic Choice Cascade to Talent.
The final stage of this part of the process is to present these goals to stakeholders to ensure that both all parties agree on the problem to be solved. These goals, or winning aspirations, provide essential design constraints. If value alignment and/or corporate priorities are to be represented in the structure of the framework, the nature of those should also now be clear.
Skill Inventory
At the same time as we are doing this, we gather data. This part of the process is designed to answer the paired questions: what are people in the organization actually doing, and what is the relationship between an employee’s job title, assigned role(s) and their skills? It is this part of the process that largely represents Ibbaka’s greatest divergence from traditional methods for doing this work.
At Ibbaka, we consider reusable, decontextualized skills as the atomic building blocks of work, capability and competency. See Building skill and competency models together. We use existing competency frameworks, job descriptions and other documents to create an inventory of skills that should be reflected in the framework. These are grouped together in a way that is relevant to the client context, often extending common groupings that might align with Talio’s standard skill categories (e.g. social skills, design skills, domain knowledge, technical skills, organizational skills, tools etc.) or could be broken down based on the inventory.
Ibbaka Talio has a variety of AI-assisted tools that enable the extraction and inference of skills from text, documents and links. If we have an existing set of job descriptions for the organization that reflect current practices, we use those, even if they are out-of-date or were tailored for particular recruitments (e.g. we can use old job ads or even descriptions for similar jobs on services such as Indeed, LinkedIn or ZipRecruiter). We can also merge this data with references to or actual inclusion of other competency models that reflect either common patterns of work in related areas or best practices for organizing relevant work. The addition of this data in the inventory can be especially useful when one of the goals is to assess readiness and/or recruitment priorities for new opportunities.
What we produce at the end of this process is an inventory of all skills that we know are likely to be either used or needed in the execution of the organization’s responsibilities.
Skill Survey
With this information we prepare one or more skill surveys for all employees, asking for information about their current work (i.e. their current job or roles) and how these skills map to the work that they are actually doing. With the skill inventory above, we can present this survey as a set of skills that could possibly be relevant to every employee and ask a simple, easy-to-answer question for each skill.
In many cases, there can be more than one hundred skills in the inventory, and even a yes/no question for each would be tedious and uninteresting. That is one of the reasons we have grouped skills in the inventory, with a goal that each group be thematically connected and have between 5 and 15 skills. This allows us to not only provide a kind of pacing in the survey, but also to try to discover skills that might have been missed by the inventory process.
Our current ask for each group of skills in the inventory is
Which of the following <skill group> skills are you using in your current job?
Rather than treat this as a simple yes/no question we ask for answers along a simple scale – from “Not Used” to “Requires Expertise.” This allows us to group these skills by both necessity and required skill level.
This is a simple, intuitive choice to make for most employees and with the thematic groupings described above it is possible for an employee to assess a large number of skills quite quickly. To cover skills that might have been missed in the inventory, we also ask “
Are there any other <skill group> skills you are using in your current job?
for each such group.
The scaled choices and open response then allow us to answer three questions about each of the skills and their relationship to the respondent’s job or role:
Is the skill essential for the job/role or is it either a “should have” or “nice to have” skill?
What level of expertise is needed for this job/role? and
Which skills that are not in the inventory are required by a role?
We then break down the survey responses by the respondent’s job or roles and thus develop a list of skills for each job or role that is reflective of the work people are actually doing. This is the baseline for all of the rest of the work that needs to go into the development of a competency framework or model, and is also where the framework actually meets employees and managers most directly.
Competency Levels
By this point, we should have a clear idea of the goals of the framework (in terms of needs and pain points) and a good baseline skill map of each of the existing jobs and roles. If we have imported or created other competencies to address corporate needs not currently being met (e.g. climate adaptation or a new line of business) then aligning these roles and responsibilities with either existing or new jobs within the framework must now be done. This stage of the model can best be described as giving structure to the work being done or needing to be done.
A number of key decisions must now be made, the most important of which is the shape of the model in terms of levels of structure above the skills. The model could be organized around a shared set of roles and responsibilities – which aligns very well with most job descriptions. It could also be just roles and behaviors – especially if value alignment is high on the list of priorities.
My preferred default is to structure around roles and responsibilities, with jobs being described in terms of a set of roles and responsibilities, each of which has a set of skills. This aligns well with how people think about their jobs and makes it easy to produce recruiting copy and job ads.
If the roles as defined are comprehensive and designed for reuse across jobs and projects or teams, then the framework may not even need to be organized around job titles at all, but simply reference them from the roles and then describe each job in terms of roles and additional responsibilities. This approach resonates especially well with organizations and individuals who value flexibility and adaptability in their work practices.
Many framework designers like to represent the model in terms of roles or competencies that have different competency “levels” that align with job level (e.g. Customer Success as Basic, Advanced or Leader). This leveling of roles or competencies may not be necessary if the primary focus is on career development and planning, since then the questions that need to be answered revolve around:
“what skills do I need to develop to be ready for a promotion or lateral move,”
“how can I demonstrate readiness,” and
“how can I develop those skills in projects or with a mentor or through targeted learning?”
Often these competency levels are intended to illustrate the progress from lower-level job responsibilities up towards upper management, but I would argue that this can obscure the real challenges of figuring out how to prepare for advancement or a career shift. In that case, describing jobs and roles in terms of a set common responsibilities and skills each having specified levels of expertise (as opposed to the job-specific tasks often described in job postings) will allow one to more easily compare one’s own skills and expertise against needs for other jobs or roles, and to focus career planning on skill development. This is, in fact, how we represent competency models in Ibbaka Talio.
That said, the organization of common skills across jobs into well-defined roles, tasks, responsibilities or behaviors is the most challenging part of this process. This stage can either be based on the existing job descriptions and imported elements, or built from the ground up by finding and describing common subsets of skills. The goal is to build an inventory of common roles and responsibilities and their associated skills that become the constituent components of either the jobs, roles or competencies that are the largest organizing structures in the model. Ibbaka Talio is designed to support either approach. Talio has tools to assist with this effort, but it is still primarily a process of human judgment and expertise.
Socialization and use
No such process would be complete without a significant effort to socialize the resulting framework within the organization. This should first be done at the level of stakeholders and management. The structure and grouping of roles and responsibilities (if any) need to be presented and agreed upon by stakeholders even before the refinement process described above. The initial structure and presentation then also needs sign-off before it is presented to users.
We put a great deal of emphasis on presentation for purpose. That usually means providing the final result in both presentation and document formats. It may in fact be necessary to present the skill and competency model in different forms for use by executive management, HR leadership, learning and development and by the end users. The goals and use cases for each of these roles often differ significantly. If these are the standalone results of our process, then presenting these to the entire company via workshops and integration with a company-wide HRIS, talent management or learning management system can be the final product of our work.
Ibbaka Talio already has a very good set of tools for managing and presenting these models and integrating them into both management and end user’s own skill presentation and management processes. From a management perspective, we can use a Talio model to answer questions about skill capabilities and gaps within a company’s workforce and allow user and managers to track skill levels over time and in different roles. In addition, we continue to deepen Talio’s ability to assist people with skill development and planning by being able to use those skill levels, identify target skills, levels and gaps and eventually to identify external learning resources and/or custom LMS or learning platform integration if that is required.
When does competency model development fail?
There are five main reasons that skills and competency models fail.
The process is driven top down, ignoring the ground truth of the skills people actually use to accomplish their work and realize their goals
The goals for the model are vague or contradictory
The same presentation model is used for too many different purposes and user personas
The model is rigid and static and does not change as work evolves, new roles emerge and new skills are required
The competency model is held in isolation from other systems and is not integrated into how people actually work
The Ibbaka competency modeling process, and Ibbaka Talio, are designed to prevent these failures and deliver skill and competency models that are relevant to each type of user, easy to understand and apply and that are able to adapt to changing nature of work.
