Five related terms that get confused if you encounter them out of order: sector, sub-sector, job family, competency, and proficiency level. Together they form the taxonomy — the shared vocabulary your workspace uses to describe what people can do and where in the economy they sit.
The four levels
The taxonomy narrows from the broadest economic grouping down to a single observable capability:
- Sector — the broad part of the economy a workspace operates in (e.g., Information Technology, Financial Services, Healthcare, Cybersecurity). One sector per workspace, chosen during onboarding.
- Sub-sector — a narrower slice within a sector (e.g., under Information Technology: Software Engineering, Data & AI, Cloud Infrastructure). A sub-sector can belong to more than one sector when the same specialty is shared across the economy.
- Job family — a grouping of related roles with a common competency profile (e.g., Backend Engineer, Data Engineer). A job family can sit under more than one sub-sector — many roles span specialties.
- Competency — the leaf level: a single capability with a name, a type, a bilingual description, and four proficiency levels.
The two many-to-many edges — sub-sector to sector, and job family to sub-sector — exist because the labour market does not fit a clean tree. Site Reliability Engineering genuinely belongs under both Cloud Infrastructure and Software Engineering; forcing a single parent would distort the data.
Competency
A competency is the leaf of the taxonomy — the thing that actually gets measured. Every competency has:
- A name in Arabic and English.
- A type: Technical (domain-specific, e.g., Kubernetes, IFRS) or General (cross-domain, e.g., Written Communication, Stakeholder Management).
- A one-paragraph bilingual description.
- Four anchored proficiency-level descriptors (Beginner, Developing, Proficient, Expert).
Competencies are reusable: one competency can be linked to many job families across many sub-sectors. Competencies are what roles require, what assessments measure, and what competency profiles aggregate. The whole platform reduces, ultimately, to per-competency numbers per person.
Proficiency level
A proficiency level is one rung on the taxonomy's uniform four-level scale (Beginner, Developing, Proficient, Expert), with anchored descriptions of what work at that level looks like for a specific competency. The descriptors are observable behaviour, not abstract qualities — and they are anchored per sector, so a Proficient in a finance context references SAMA/AAOIFI language while the same level in cybersecurity references NCA ECC controls.
The four-level scale is uniform across every competency, so a Proficient in one competency carries the same meaning of "rung four of four" as a Proficient in any other — while the descriptor text makes the claim concrete for that competency.
How they nest
Sector
└── Sub-sector (a sub-sector can sit under multiple sectors)
└── Job family (a job family can sit under multiple sub-sectors)
└── Competency (Technical or General; reusable across job families)
└── Proficiency level (4 per competency, anchored per sector)
A role's required competencies picks specific competencies at specific levels. A competency profile holds one current level per competency. An assessment measures specific competencies.
What is workspace-private vs platform-global
- The global taxonomy (sectors, sub-sectors, job families, catalog competencies and their level descriptors) is platform-global and read-only. It is what makes cross-workspace benchmarking and sector-level reporting possible.
- A workspace selects its slice during onboarding — only the sub-sectors, job families and competencies relevant to its sector — and can extend it later.
- Custom job families and custom competencies that a workspace adds are workspace-private: they appear in your pickers but not in other workspaces'.
One sector per workspace
Cross-team comparison, organisation-wide gap analysis, and succession planning all assume one shared vocabulary. A workspace therefore has exactly one sector, locked after onboarding; sub-sectors, job families and competencies within it stay editable. If your organisation spans very different functions, model them as different sub-sectors and job families under the single sector rather than trying to run multiple sectors.