What is in a competency model and how are they used?
Steven Forth is a Co-Founder of Ibbaka. See his Skill Profile.
At Ibbaka, we see competency models from two or three different companies a month. In almost all cases, a great deal of thought, even passion, has been put into these models. Many of them are elaborate and have great depth and complexity. The well done ones (and most of them are quite well done) represent not only the skills an organization needs to succeed but say a great deal about its value as well. This is a wonderful thing.
Competency models can play an important role in shaping an organization. They make explicit what is needed to progress along a career path and help people know what is required for success. They can be used to inform gap analyses (this is what we need, now what do we have) or to build more effective learning and training. The best practice is to use insight into skills to get people into the right roles and onto the most effective teams.
What goes into a competency model?
There can be many ingredients, but a general list includes values, a taxonomy and generally a mapping to roles or tasks. Let's look at each of these.
Values
Some may be surprised to see values as a part of a competency model, but they are always there, at least implicitly, and as they are lurking in the background it is often a good idea to bring them to the surface. The critical question to ask in designing competency models is,
What skills are associated with demonstrating the value?
A good competency model draws a direct connection between values and skills.
The Taxonomy
Here is where things can get complicated. There are as many different ways to organize these taxonomies as there are people building competency models, and everyone seems to believe that there's the one right and authoritative way. Competency models will generally provide some way of connecting skills, attitude, knowledge and experience to roles, tasks and business outcomes. A couple of examples are shown below.
In this first example, the goal is to connect the Role, for instance, Sales Manager, to both Key Performance Indicators (KPIs) and Competencies. Competencies themselves are then defined in terms of Skills, Attitudes and Experience. Other things could be added here, such as Knowledge, Certifications and so on. Ibbaka’s Skill Graph actually goes deeper than this and connects Skills, Attitudes, Experiences to each other as well as to KPIs. We do this so that our analytical tools have more to purchase on.
In a second example, the focus is more on how a person moves up in the organization, with the skill expectations getting higher and higher. This could take several forms. The level of competency required could change, from Learner to Expert, or new skills can be added as the person moves from one role level to the next.
Regardless of the details of the hierarchy, there are some simple principles to apply to the design.
Keep it simple, try not to have more than three levels in any one part of the taxonomy (as you can see above, these models can get complex quickly, use tags and cross links rather than complex hierarchies for flexibility).
Separate experience from the skill. Experience is evidence for the skill and level of competency and not the skill itself.
Allow connections. Don't assume that the hierarchy correctly defines all of the possible connections. It should be possible to make connections that jump up and down or over and across the hierarchy. It is from these connections that insights can emerge.
Hierarchies or Facets
There are two basic ways to code competency models. One can rely on a well defined hierarchy with fixed relations. That is what is implied in the two examples above. A very different approach is to use tags, and specifically faceted tags, to organize relationships. This is a subset of a long running argument on how to organize information. Faceted systems (or what were called Colon Classifications by their originator S.R. Ranganathan) have proven to be much more flexible than hierarchies. They also make it easy for the same component, a skill say, to play multiple roles in the system. Across most of the information architecture world, facets are accepted as being more powerful than hierarchies, but this approach is only now being applied to competency models. At Ibbaka, we are adopting faceted tags as the way to build competency models. We are doing this to make sure that these models can be as flexible and adaptive as possible.
Top up or Bottom down
Competency models need to be flexible and adaptive. The nature of work is changing rapidly driven by digitization, new business models, artificial intelligence and innovation generally. The top down approach assumes that someone, often a consultant or person from HR, knows more about the work than the people doing the work. Or at the very least, are able to extract insights from people and organize them in a more formal way. This can be true, an expert in the design of competency models often sees things in ways that people caught up in the day-to-day grind cannot. Unfortunately though, too many competency models are designed in isolation from work and are experienced as something imposed top down. A different approach is to let the model bubble up from the work being done, and let social interactions plus artificial intelligence do the organizing. Many companies are uncomfortable with this though, and the bottom up approach by itself will probably not be enough to prepare organizations, or individuals, for the future. That will require a more dynamic approach in which the competency model emerges from top down and bottom up interactions.
Dynamic Nature
Competency models need to be self organizing systems. They need to by dynamic, and able to adapt to change (that's the bottom up part) and to anticipate change (good top-down leadership can help with this). The emerging best practice is to have an underlying skill model, driven by the actual roles, work and interactions, and then be able to shape this underlying model top down and, where necessary, to insert new skills and to signal their future importance.At Ibbaka, we started with the bottom up approach and are now layering on the top down component. We feel this design will blend the adaptive and self-organizing behaviours of the bottom-up approach with the guidance provided by the top-down approach.
What’s next?
Now that we have unpacked the basics, we will unpack the steps to building the competency model to suite your organization or community of practice’s needs. See: how to build a competency model
