Process for Constructing Areas
Areas of functions are bringing terms and groups of terms in knowledge, expertise with tools & technologies, activities, domain experience and operational role as applicable for the area.
Guidelines are followed while creating the construct.
A high level category is created. For example, Information Technology, Accounts, or Finance. This high level category may be part of a master from which it is added as a child without a header.
A category may have headers under them. Headers typically are for things like Tools and Technologies, Roles, Concepts, Domains etc. These typically will be discrete and not searchable.
It is possible that high level categories further have high level categories under them, for example as is the case in Information Technology.
Under the headers, masters, parents, and children are added. Once the skills are added, properties are assigned to them.
There are two nodes that are key in all categories:
Areas
Roles
Again, whether the two need to be distinct and separate or should be merged into one another will depend on the category itself. Here are two examples of Areas:
In Application Software Developments, areas include .Net Development, ECommerce Application Development, and Game Software Development
In HR, areas include General HR, Recruitment, Compensation and Benefits.
Roles are treated differently from Titles.
Typically Roles can be Individual Contributor, Manager, Independent Operator, Functional Head etc. Roles typically indicate operational responsibility with consideration to people, resources and processes. Particularly soft skills expected of different roles will vary. Within roles, indicative titles are included. For example, in HR for the role of Individual Contributor the typical titles could be Recruiter or Headhunter.
NB: We consciously do not include prefixes such as Assistant, Senior, Junior, Director, VP etc.
When we construct the branches for a node within an area or role we take into consideration the different elements of the skills profile including knowledge, tools and technologies, concepts, domain, certifications, and role. This is an important framework. The terminology and importance of these vary based on categories or occupations. For example, when we are considering sales we are adding a branch that asks “What products or services do you sell?” From a framework perspective, this is a domain but we do not use the word domain because this is not a terminology people are familiar with.
Likewise, in the case of recruiters we have a node that asks “What levels of candidates do you recruit?” This, again, is a domain.
While constructing the branches, there are three possibilities: 1. Skills are added from master as children
2. Skills from another branch are added as a virtual node
3. Nodes are associated using associations
Let's use an example of a construction process. If I were to create an area called Graphic Design, I need to decide which concepts a graphic designer should know.
What tools would they use? Graphic design tools like Photoshop are primary for this area so we would add it to the master of graphic design tools as a child to this area. They may also use presentation software like Powerpoint and Google SlideShow. This may already be a node under Office Software. Therefore, we will make this node a virtual node of Tools used in Graphic Design.
Is Domain applicable? It is, so we will add the Master of Areas of Graphic Design which includes terms like Calendar, Logo, Icon, Web page, Banner Ads etc. We will add this under “What type of designs do you create?”. After adding it, we will create proxies for these nodes like Logo Design, Icon Design and so on so that in search there is clarity.
Are there different roles played? Yes, so we will also add roles and under that, roles of Individual Contributor, Manager/Supervisor. We may choose to add some common titles used for the roles like Graphic Designer for Individual Contributor.
The reason the titles are included is because an user may search for a title and not an area or role.
This is the construct for an area which has many of the framework’s elements. However, there are also those of which we may not have such wide coverage. For example, delivery people. NB: We are using the role or title here and not an area, because this phrase is more commonly used. There is no need to stick to a hard and fast rule for construction. This is reflective of the nature of the skills space, where there is no clear definition of “Area” or “Occupation”. For delivery people, we won't have concepts. We may have domains such as courier delivery, food delivery, etc. We won't have activities (because it is obvious) and we won't have tools and technologies (because it is obvious again, that they need to use the mobile app). However, we would have soft skills such as aptitude, personality traits, and language proficiency. So, the construction considers the nuances of each of the Areas or Occupations.
Two things here:
Designations and seniority
Differentiation of levels within an organization like Junior Developer, Developer, Senior Developer. This could be based on the number of years of experience and/or proficiency level in skills. ISOT does not force these choices for the respective roles or titles. This means that Org A may create a Role Skills Profile for senior developer and choose 12+ years’ experience in development for this RSP whereas Org B may choose 5-12 years’ experience for a senior developer.
2. Choice of specific skills
ISOT recommends skills groups for Areas and Roles, it does not recommend specific skills for a role. These are typically localized i.e. organization specific. For example, for project management, ISOT recommends project management tools. Org D may be using Jira as their project management tool whereas Org E may be using Primavera.
IMPORTANT: By now, some of the utilities of ISOT construct would have become clear, not just normalization of skills terms. These include:
Articulation of skills profile covering different dimensions of the skills profile
Exploration of the possibilities of application of the different groups of skills in different occupations or areas
Helping in decisions on trade offs when taking decisions on skills profile for recruitment and other activities. For example, a hiring manager may indicate they want Solr as one of the skills for a data analyst. In this instance, we could find some profiles where there is a good match on other skills dimensions such as domain, concepts etc. even if Solr is not there but ElasticSearch (another search engine) is
Last updated