In many discussions on Skills and Skill Gaps, I notice that people find it difficult to comprehend how to best organize and model Skill data. So here’s my attempt in explaining how you can best organize, structure and model skills data. And I will be using LEGO to illustrate the basic concepts of skills attributes and skill relations.
People who know me, know that I am a huge fan of LEGO. As a kid I could build and play with LEGO all day, and as an adult, I’m very happy to have 2 kids who love LEGO as well, as this gives me the perfect excuse to continue building. LEGO has the unique characteristic that it is extremely modular and flexible. With only a few bricks you can build a large number of very different things. And with many bricks, you can pretty much build anything you want.
In an earlier post, I explained how the modular design of LEGO is a great inspiration for how we could (or ‘should’) build more modular learning experiences. And how a modular design can be a great help in being able to better track and analyze that learning experience. I always refer to this as ‘data driven design’: making sure that in your design phase, you already know what you want to measure, so you can build these measurements in your design and make sure you will collect the data you need to do the analytics you want.
But there is an even much better analogy between LEGO and Learning Analytics. And that is data itself.
LEGO as (Skills) Data
Lego is often used as an analogy for data. This analogy presumes that a single piece of LEGO is a data element. That a pile of LEGO pieces is a database or datalake, that sorted and arranged piles of LEGO bricks is structured data and a datamodel, and that creating a LEGO building, vehicle or any other object for that matter is comparable with telling a data driven story.
The most interesting element of this analogy, and lesson we can learn from LEGO in general, is the following:
If you design the right level of granularity of data, your abilities to mix and match that data into any story that you want (or need) is pretty much unlimited!
This principle is not just applicable for learning experience design, but also for how you construct your skills data. Skills data after all is extremely dynamic and your skills data model needs to be very flexible. I’ll try to explain this with LEGO.
Characteristics of a LEGO Brick
Every LEGO brick that exists can be allocated specific characteristics. These characteristics (also called attributes) are fixed (or almost fixed) pieces of information that do not chance at all when you use the brick to build a structure or object. The image below is an illustration of a few of these characteristics:
Color: LEGO has bricks in specific colors, not all bricks are available in all colors and even though the color palette changes slowly over time (new colors and added and sometimes colors are removed), the color of a specific bricks always remains the same
Size: LEGO bricks exist in many different sizes and each brick can be described in terms of ‘LEGO studs’ width, length and hight.
Category: Most LEGO bricks fall under the Category of ‘Bricks’ (duhhh), but other categories include for example Tiles, Plates, Food & Drink (lego pretzels for example), Minifigure Tools & Accessories (hats, camera’s) and Trees & Plants (the iconic spruce tree for example). Each brick is linked to only 1 category.
Element-ID: If you are looking for a replacement brick because you were to over enthusiastically vacuum cleaning, or stepped on one and broke it, you can order specific bricks in a specific color using the element-ID, this is a unique number for each LEGO brick
Price: Upon ordering your replacement bricks, you can see what each individual bricks would cost. Typically these prices range from a few cents to a few euro/dollar each. Now the price is a characteristic that could evolve over time as prices are adjusted for inflation for example, or to reflect scarcity. So you could argue if this characteristic is as fixed as color or size. But these changes do not happen often.
Name: Each brick, naturally, has a name. But names are not unique as similar bricks of different colors have the same name. That is why having a unique identifier for each brick in each available color is so essential!
So if you would be managing a LEGO online store or webshop selling individual LEGO parts, these characteristics are very essential and would allow you to nicely structure and organize your large numbers of bricks.
Relationships of a LEGO brick
Whereas the characteristics of a LEGO brick (sometimes also called ‘attributes’ or when it concerns data ‘metadata’) are fairly limited by nature, the number of relationships that a LEGO brick can (potentially) have is pretty much endless. The only boundaries are the boundaries of your creativity and imagination. In the world of LEGO there is actually a 3-letter acronym for using LEGO parts in a way that is completely different from its original intend: NPU. NPU stands for ‘Nice Part Use’ and is described as “using a certain part in a different way than its intended usage, like a croissant for an eyebrow or a surfboard for a beak”.
So even the most simple and humble 2×1 brick can be used in many many different ways: In a rough cut castle wall, a modest ski lodge, a huge Eiffel Tower, and naturally in a LEGO city.
This ‘use’ of a LEGO brick in a large structure could be considered a ‘relationship’.
A relationship differs from a characteristic for the following reasons:
1. A single brick can have many different relationships, i.e. many different ways of usage
2. A single brick can play a different role in each relationship; it can be essential as with the castle wall, or foundational as with a building. It can be a visible part of the structure, or an invisible support brick.
3. A single brick changes relations as it is used and reused for new constructions.
In short, relationships are much more dynamic in terms of possibilities and in terms of changes over time as they refer to the usage of a brick, rather than the fixed (or almost fixed) characteristics.
This makes it much harder to try to capture and record relationships. Imagine that you are owning that online LEGO parts webshop. You could provide a nice organized list of available parts that you can filter by all the characteristics of each brick as we shared above: size, color, category, cost etc. And this is what you see with pretty much any webshop!
But what if you want to do something special? Something that no other LEGO parts webshop has? What if you want to enable visitors to search or browse by ‘usage’ of a brick, or in other words, search of browse by ‘brick relationships’? It will be much harder to build such a ‘LEGO brick relational database’. You would need to list all possible used of each brick, including the role they play. Your list of available bricks could be as much as several 1.000s (I am actually not sure how many different LEGO parts exist, but the LEGO Group estimates around 36.000), but realizing that every LEGO part could be used in 100s and 1.000s or more buildings and objects would make any such database really huge!
Separate Skill Characteristics from Skill Relationships
Why the LEGO brick story?
I’ve used the LEGO brick example to illustrate that with organizing skills we should realize that skills, like LEGO bricks, also have a small number of fixed characteristics (or attributes), and a potentially very large number of relationships.
And to avoid that your skills database explodes and does not allow you to manage the continuous changes, nor do crucial skills analytics, you should take care to separate the skill characteristics (or attributes/metadata) from the relations that each skill can have with learning content, roles and people.
Skill Characteristics
Skill characteristics are in essence not very different from the characteristics of a LEGO brick:
Skill Name/Title provides a short but to the point title of a skill that is as self explanatory as possible
Skill Description provides space to elaborate on what that skill actually involves
Skill ID is an essential piece of information for all large skill libraries to allow you to unequivocally identify and link with the correct skill
Skill Owner could be the person in your organization who is the biggest expert in that skill area and/or responsible for all upskilling in that skill area (much like a competence owner)
Skill Shelf Life is the expected time a skill will remain relevant, or rather the time before the skill becomes obsolete
And Skill Introduction Date is the date when the skill was introduced in the organization.
The above list is only an example of possible Skill characteristics. You could require more. As long as the characteristics you add are independent of where and how you apply the skill, and are fairly stable over time. For example labeling the 5 company wide strategic skills that were recently identified, or skills that are unique to the organization (as they for example represent the core of your intellectual property). Or the source of a skill which could be your own company data or commercial skill libraries. If you have multiple commercial skill libraries, you could use this Skill Attribute table as your single list that allows you to merge all these different libraries as well.
A final example of a skill characteristic I want to mention is that of adjacent skills. Adjacent skills are skills closely related to the ones you already have. The assumption made is that people find it is easier to learn adjacent skill compared to skills that are much more alien. For example, when I started working Microsoft Power BI as a tool to model and visualize data, I was able to quickly pick things up with very little scaffolding as I was already pretty proficient in excel and a few other data visualization tools. If you have not previously worked with excel, there is a pretty good chance it will take you more time, effort, practice and scaffolding to learn Power BI skills.
Skill Relationships
As with LEGO bricks, Skill attribute data is stable over time and fairly limited. Skill relational datasets are huge and are in constant flux as people develop skills every day, new skills are added/removed and target skill levels change.
Skills related to employees
As soon as you assess a skill with an employee, you in fact create a relationship between an employee and a skill. Depending on how you measure skills (see my learning analytics November post of the 13th to get a feel of what I would consider a very mature and forward looking skill measurement strategy) you will ideally continuously receive new skill assessment data and thus create new relational data. This includes data from people who are assessed for a specific skill the first time and people who are assessing their skill for a second time, or third or people who have their skill assessed through a different method.
Skills to roles relations
We also know that new skills are surfacing and added to skills taxonomies or models. Skills could also disappear as they become irrelevant (Consider the fact that GenAI solutions like Chat GPT can now write code for you based on your input and requirements. This could result in certain coding skills becoming obsolete!).
You might for example now want to add a skill to your skill catalog that never existed before, like the skill prompt engineering that was introduced with the release of Chat GPT a year ago. When you add a such a skill, you will also want to link that skill with all organizational roles for which the skill is relevant. Each skill to role connection is in fact another relationship. All changes to skill-role connections are changes in relationships.
Skill to level relations
In a well structured skill model, we’re not just considering if an employee has a certain skill or not, but also at what proficiency level. Are you a beginner in learning analytics? Or more advanced? The added value of having skill levels in your model is to realize that different people in different roles not all require the same level of skill. As L&D professional you might be busy upskilling yourself in ‘data analytics’ and ‘AI’, but that does not mean all L&D professionals should become data scientists and AI experts. I refer to this as ‘Right Skilling’. Right Skilling is not easy for 2 main reasons. First you need to establish in great detail what activities (also in terms of speed and quality) demonstrate what skill level, and secondly you need to establish what people in your organization should have what skill level in order to be successful. Every skill to level connection and all requirements for each level including what activities demonstrate what skill level are also relationships. The link between a skill relevant for a specific role at a specific level, is also a relationship.
Skill to context relations
You sometimes see the same skill listed multiple times in a skill catalog with a each time a minor different: we should ask the question to what extend the skill ‘data analysis for Finance’ is a different skill from ‘learning analytics’?
I think both are the same skill, but applied in a different context. This means that persons with data analysis experience in finance, could well apply the learned skills in L&D, provided that they are able to learn the context of L&D. Years ago, when I was building a learning analytics center of excellence for a large organization, we actually did recruit specialists from finance for that exact same reason.
So every skill to context connection is not a new skill, it could be considered to the another relationship of the same skill.
Skills to strategic importance relations
For a person working in your data analytics team, most data analytics related skills could be considered foundational: It is a necessity to have skills on data cleaning, modeling and visualization to do your job, and as these skills are such a foundational part of the role you could possibly even need them before you are considered for the role. In L&D however, data analytics skills could be considered more strategic: They are needed to make a transformational change into an L&D organization that works more evidence based and is able to demonstrate the impact of all L&D investment with data.
So the same data analysis skills could be foundational for one role, and strategic for other roles. The strategic importance of a skill for a role is therefore not connected to the skill, it is not a characteristic of a skill, rather another relationship. There is another clue that helps to identify the strategic importance of a skill as a relationship, rather than a characteristic. The strategic importance of skills for specific roles change over time. Skills could become more strategically important, as we’ve sees in data analytics skills in L&D roles. But skill could however also become less strategic and more foundational. I would expect that as L&D teams mature their analytics and it becomes much more of an standardized, operational and highly automated process, the data analytics skill in L&D roles would become more foundational.
Skills to urgency relations
There is always a timing element related to upskilling. Certain people have the option to take some time to develop learning analytics skills because, although it helps them already in their current role, it is more a preparation for a next role. While others might want to develop some serious learning analytics skills in the next 3 month because it is expected in their current role. If you take upskilling serious, you should set targets related to timing as well: when do you require a person, or all employees in a role, to have gained a specific skill at a specific level.
As these time related targets will differ per person and role, and again as these targets most likely change over time, you cannot consider it a skill characteristic. Urgency is again a skill related relationship.
Skill to level of transformation relations
There is an important difference between incremental skilling and transformative skilling. Incremental skilling relates to improving existing skills or developing new skills that help you become more productive in your current work, while disruptive or transformative skilling is more geared towards fundamentally changing or revolutionizing aspects of your work (or the business you are working in).
Learning analytics using GenAI for learning analytics experts could be classified as incremental skilling, while for some body who is completely new to learning analytics in the first place, learning how to do learning analytics with GenAI would for sure be much more disruptive and transformative.
Now these are just a few examples of skill ‘characteristics’ that are not fixed to a skill. And I did not even mention skill relationships like skill target levels that are set through organizational roles, but could also be set by individuals (and therefore not always align!). I also did not mention one of the key relationships when considering upskilling; the relation between skills and learning experience and skills assessment.
Design your skills model for volumes, frequent changes and flexibility
As with LEGO bricks, Skill relationships can easily outnumber Skill characteristics. And the volume of data involved in recording all these relationships will for sure outnumber the volume of data related to Skill characteristics.
Imagine an organization with 10.000 employees, with an average of 10 skills per employee, 3 skill assessments per skill, per year and 5 learning experiences per skill. These are only a few relationships from the list, but would already generate 1.5 million data records per year.
These large volumes is something to consider when you are building your skill data model.
In addition to the large data volumes, skill relational data will also change more frequently: with every completion of an upskilling learning experience, with every skill assessment, with every employee setting a personal target….new relationships are formed, or changed. And you model will need to be able to handle these changes.
But a final and crucial benefit to separating skill characteristics from skill relations that I have not yet mentioned is the flexibility it enables in reporting, dashboarding and analytics.
If you are interested in analyzing skill data only for strategic relationships to decide in what areas you want your internal experts to play a pivotal role, you can. Mind, this is NOT the same as analyzing strategic skills for the whole organization!
If you are interested in analyzing skill data only for the most urgent skill relations to help make short term investment decisions, you can. And mind again, upskilling in data analytics could be very urgent for some, and not so urgent for others!
If you are interested in understanding the more transformative upskilling area’s, so that you can adjust your learning experience accordingly, you can. And yet again, this is not the same as analytic ‘transformative skills’ as prompt engineering can be transformative for some, but not for others.
At the start of this post, I mentioned that “If you design the right level of granularity of data, your abilities to mix and match that data into any story that you want (or need) is pretty much unlimited!”
This is very true for skills data. If you organize your skills data as described in this post, using a limited number of characteristics and an extensive number of relationships, you will create a very flexible data model that enables you to do all the slicing and dicing you would ever want in a skills analytics dashboard. And in addition, it will make it much easier (or better: less complex) to do more advanced predictive and prescriptive analytics on skills!