An overall approach could be to mix how employees self-identify skills and consume training with as much oversight and refinement as you require from HR, line managers, or L&D specialists. The way this works depends on the types of things you plug into your skills operating system, and how they are all related to each other. For example, in the full product provided by my company we implement the following key concepts:


We start by providing a huge set of role and skill definitions, with ready-made mappings between them — based on various open data sets along with the curation that we have performed over many years. This starting point includes more than 12,000 separate role definitions, over 65,000 skill definitions, and more than a quarter of a million mappings between roles and skills. (Note: The data set is available in 54 different languages).


Each organization decides two main things to begin with. The first decision is whether to expose the entire data set to their employees, or whether to limit to a smaller subset of roles and skills that are deemed to be appropriate to the core business. Both approaches have their advantages and disadvantages. For example, if your business is focused on a narrow field, such as software development, you may question why an employee being able to claim, say, pastry chef skills would ever be desirable — you may regard that simply as noise that gets in the way of your analysis. However, the opposing school of thought (especially in a larger and more varied organization) might be that you don’t want to artificially limit the potentially rich profiles and capabilities of your employees. Even a highly tech-focused company like Microsoft might employ chefs for executive dining rooms and board meetings, and wouldn’t it be a shame if an underperforming project manager missed the chance to practice a highly successful career move to the executive catering suite?

The second decision is whether to start with definitions and mappings that may be, say, 80% accurate or applicable and to let bottom-up input work its magic, or whether to take a more tightly controlled top-down approach from the offset. Again, both approaches have their advantages and disadvantages, but I tend to favor the former. This means an organization can get started quickly, and the roles can adapt in response to the real knowledge of the workforce. A big problem I have seen with a too-tightly controlled approach is that by the time an organization has spent a lot of money and effort in defining the ‘perfect’ set of roles, the world has moved on — new roles and skills have emerged, while existing ones have become obsolete.


Regardless of one’s starting point, I think the key next step is to tap into the collective knowledge of the workforce to keep the roles and skills evolving in line with the everyday practicalities of the business. This, however, is not as simple as it seems.

The first thing that needs to happen is to make the data available to all employees (if we really value their input), but that’s where we find the first few challenges. Some of these are practical, such as providing apps and user interfaces securely to our users. Others include issues around getting employees to engage and motivating them to continue that engagement. As a warning, if all one does is to develop a portal or web application that one expects employees to log into, then the initiative stands a high chance of failure at the first hurdle. Such a system will be perceived as ‘yet another HR system’ that represents an additional burden to employees who don’t view this as key to their already busy work life. Then, if you add typical issues such as forgotten passwords and other technical problems, the solution is set to fail and become another silo that is used only by HR (to no good effect).

Then, assuming employees have overcome access barriers and begin to use the solution, the next challenge is to keep them there and keep them providing useful input. In short, it’s a case of engagement — there needs to be some sort of benefit in it for the employees.

Our approach to these challenges is to first recognize that employees simply do not want to log in to external systems to provide input on a regular basis, especially if the benefits of doing so are either unclear or perhaps don’t pay off in the daily short term. I may be generalizing slightly, but if it’s difficult enough to get employees submitting timesheets or even expense claims, then you can start to see the challenges. The first thing I recommend, therefore, is to remove technical barriers such as demanding that users log in to new web applications. The solution we practice is to instead surface the employee-facing apps inside the productivity applications used by employees every day to do their jobs. I’m talking, of course, about products such as Microsoft Teams, Slack, Webex, Google Workspaces, and Office 365. These modern collaboration platforms provide the ability to host ‘apps’, one of which would be the employee-facing skills solution. This removes the need for employees to switch to a specific application just to tell us about their skills and roles. It is also a secure approach and does not depend on usernames, passwords, web addresses, and other things that are easily forgotten.

The second thing I recommend is to give serious thought about what we want the employee to be doing for us, and how to motivate them to do just that. Put simply, our aim is that individual, high-performing employees should claim roles and skills, which we can then view in the aggregate across all employees to help us determine ‘what good looks like’ for any one role. In that respect, we are using their input to shape and refine the skill definitions, the role definitions, and the mappings between them. If ever we wanted our existing AI developers to define what it really means to be an AI developer, then this is surely the way to do so.

But what of the incentives and motivations needed to make this happen? Well, there are some simple approaches such as showing leaderboards around skills and skill-based goals which could be classed as gamification. But these tend not to be motivations for everyone so there are also some more thoughtful approaches, such as enabling any employee to find other employees by the skills those people have claimed. Imagine using some sort of ‘people search’ facility to find a person who can help you with, say, presentation skills or data analysis skills. In the short term, you might be happy that you found some help, but you might also come to the realization that if you want to be found by others when opportunities arise, then it might be a good idea to show what skills you have.

Other approaches include the ability for employees to see career paths, set skill-based goals, and to measure their progress in terms of skills. I’ll touch on a few of these (and other things) in the next sections.


One big advantage of taking the holistic skills operating system approach is that you can immediately plug in training, and then map relevant items to skills.

Put simply, imagine a world where each role in your organization has been defined and mapped to the skills needed to perform well in that role. The creation (or curation) of training material to help someone perform well in a role is almost too obvious — you might simply need to use the list of skills for the role as the ‘objectives’ or the ‘outcomes’ for the training program. The skills are used in what instructional designers variously called objective domains or objective hierarchies.

There should be no doubt, given this approach, that the training program is useful and relevant to the people studying it, and you have avoided the ‘ivory tower’ problem where training providers and courseware designers create material which they think is relevant, but which are often viewed less favorably by the students.


Then, let’s view this from the perspective of the employee. If they can see the definitions of roles that they would like to work towards, what better information can we give them to start with than a list of skills they will need to be able to perform well? And if we then include the concept of career goals (and put some control into the individuals’ hands), they can set their own skill-based goals and actively work towards their desired role. Of course, we may want some top-down control as well, so it also makes sense that a manager or an HR professional can also set goals for employees, in the same way.

Furthermore, when the employee views their goals, wouldn’t it be great to show them the training that will help them achieve those skills?


As a simple example, let’s assume we have the role of Web Developer. Then imagine that we have mapped all its skills, one of which happens to be JavaScript. As mentioned, we may have training material in the form of courses, presentations, or even YouTube videos that are mapped to this skill. Then let’s assume that Kristie has seen the role, that she has set a goal to gain the JavaScript skill, and that she has consumed the training material. She might well feel that she now possesses the skill, and so marks her goal as complete and adds the skill to her professional profile. In some cases, we might be satisfied with this, especially if we can see learning logs and similar evidence of study. But in other cases, we might want formal validation. Well, in a full skills operating system, we can link the assignment of a skill with a rubric of some sort. This might be feedback and 360-degree assessments by managers and colleagues, or it might be a test or exam. These days, there are many test and validation providers who enable organizations to access robust exams and tests. We can use links to these exams (or even API access in some cases) to validate (or partially validate) that our employees really do possess the skills they claim to.


As you will have grasped from previous posts, there are many other things we can include in a skills operating system. They all follow the same pattern, which is to map whatever they might be to the atomic skills you maintain in your system. We’ll use one last example here to illustrate where this approach can lead.

A lot of noise has been made in recent years about talent mobility and things like internal opportunity boards within an organization. I’m a bug supporter of this concept, as I really see the value for organizations in repurposing existing resources rather than jumping straight to recruitment every time there is a perceived need.

As a brief aside, did you know that two of the worst predictors of job success are academic qualifications followed closely by whether a candidate has performed a similar role in a different organization? Just think about the implications of that — the worst predictors of success are qualifications and experience! When you then realize that these two things are precisely what job adverts ask for, and that they are mirrored by what candidates supply on their resumes, it’s enough to revolutionize the entire recruitment industry. And what is the best predictor of success? Put simply, it’s whether the candidate already works for the organization but perhaps in a different role. If we stop to think why, it’s probably to do with things like understanding company culture, familiarity with processes, existing personal relationships, familiarity with mission statements, and so on.

That’s probably a subject for another blog, so I should get back to my point. The idea is that if we can annotate or link opportunities to the skills required, then we ease the internal mobility and reduce friction immensely. And I’m not just talking about formal jobs — we can even include things such as volunteering, community initiatives, short-term projects and secondments, participation in focus groups and steering committees, and even social activities. The list of opportunity types goes on, but the key point is that we can define participation by the skills required to be effective. And then employees can find those opportunities which match the skills they possess.


In summary for this blog post, it’s likely that most organizations require a mixed top-down and bottom-up approach to skills if they are to progress, and if they are to avoid the existential problems around HR and L&D.

Indeed, when done effectively, you can use the analytics generated to attain a holistic view (or even detailed view) of your workforce, and you can use that to plan training, upskilling, cross-skilling, recruitment, and so on.

When you have interactions between employees, roles, opportunities, goals, career pathways, mentors, training, and more, then you will find that you truly have a skills operating system.

This blog was originally published at https://skilledhuman.org/blog13.aspx