Your organization may have thousands of job profiles and still lack a reliable view of the skills inside its workforce.
The problem appears as soon as a skills inventory project begins. Similar work sits under several titles. One broad title covers people doing materially different jobs. Levels reflect local history rather than clear differences in scope or proficiency. New responsibilities have entered roles without reaching formal job descriptions.
Mapping skills directly onto that catalog would turn its outdated assumptions into structured data. Waiting for every job family, title, and level to be redesigned leaves the business making hiring, development, succession, and redeployment decisions without the skills visibility it needs.
That delay matters when employers expect 39 percent of workers’ existing skill sets to be transformed or become outdated by 2030, according to the World Economic Forum’s Future of Jobs Report 2025. Fuel50 research has already found that 39 percent of HR leaders describe their current mapping of skills to roles as outdated, messy, or difficult to maintain. (Explore the research.)
You can build a useful skills inventory before the entire job architecture is fixed. The practical route is to start with priority work, create enough structure to describe it accurately, and use the skills evidence you uncover to repair the architecture in stages.
A job architecture organizes work through job families, roles, levels, career paths, and often compensation structures. A skills architecture connects capabilities and proficiency expectations to that work. A skills inventory records recognized skills and the evidence of where they exist.
The three structures depend on one another without needing to be completed in sequence.
An outdated architecture can contain several errors at once. Business units may use different titles for similar work. The same title may refer to different responsibilities by location. Levels may distinguish tenure without explaining how judgment, complexity, or impact should increase. Job descriptions may emphasize tasks technology has reduced while omitting capabilities employees now use every day.
When those profiles become the sole basis for a skills inventory, the inventory inherits their weaknesses. It may assign obsolete skills to employees because of their current title, miss capabilities that entered the role informally, or create false gaps against requirements that no longer matter.
A full redesign may need to reconcile titles, levels, compensation bands, career paths, and global naming conventions. The first inventory can begin before all of that is finished.
The first inventory needs a reliable way to identify the employees in scope, group similar work, define relevant skills and proficiency, and record evidence about what people can do. That foundation can support a first workforce decision while the wider architecture work continues.
Design the first inventory around a decision rather than an attempt to document the entire workforce.
Choose an area where poor skills visibility is already slowing the business. The organization may need to find internal candidates for a transformation program, build a succession bench for a critical role family, understand the effect of automation, or redeploy employees into growing work.
That decision defines the first population, the roles that need review, the skills that matter, and the quality of evidence required. Self-reported profiles may support learning or mentoring. Succession and redeployment require clearer proficiency and stronger validation.
Starting with one decision also gives the project a test: can the inventory identify a gap, uncover capability hidden by titles, or improve a build, buy, or move decision?
| Needed for the first inventory | Can continue in the wider architecture workstream |
|---|---|
| Reliable employee identifiers | Enterprise-wide title harmonization |
| A defined business area or population | Final compensation alignment |
| Provisional role families or work clusters | Complete global career paths |
| Current outcomes and major responsibilities | Redesign of every job description |
| A governed skills language | Resolution of every historical exception |
| Shared proficiency definitions | Perfect consistency across every level |
| Evidence and validation rules | Enterprise coverage at first release |
| Named owners and an approval process | Full migration of the job catalog |
The work in the right-hand column still matters. It should not block a trustworthy view of the skills involved in the first decision.
When official titles cannot be trusted, group people around the work they perform before deciding how every job should eventually be named.
A role archetype is a provisional description of a recognizable body of work. It brings together the outcomes, responsibilities, skills, and expected proficiency that several employees or local roles share.
Several titles may collapse into one archetype when they produce the same outcomes. One broad title may need several archetypes when its holders perform different work. Employees called business analysts, for example, may focus on process design, financial modeling, systems configuration, or data analysis. One role profile would hide the capabilities that distinguish those groups.
The archetype leaves the official job code and compensation record in place while giving the inventory a more accurate structure for analysis.
Use the existing role profile as one input. Compare it with the work the business currently expects and the work it expects to need next.
Useful evidence includes operating plans, recent vacancy requirements, project documentation, performance goals, workflow changes, and input from managers and role incumbents. External labor-market signals can show which capabilities are growing; internal experts decide whether that movement applies to the organization.
The job description shows what was documented. Employees and managers show how work is performed now. Strategy shows where the role is moving.
Avoid attaching every remotely relevant skill to the archetype. Long lists create maintenance work without improving decisions.
Focus on four groups:
Define proficiency through observable differences in independence, judgment, complexity, scope, and impact. “Data analysis” at a foundational level should describe different behavior from data analysis used to set enterprise strategy. This is where a shared skills taxonomy and skills ontology prevent each team from inventing its own language and scale.
Give managers, role incumbents, and subject-matter experts something concrete to review. Ask which requirements reflect the work now, what is obsolete or missing, and which skills genuinely distinguish one level from the next.
The review should separate current from future requirements. An emerging capability may belong in development plans before it becomes an entry requirement.
Record whether each archetype and mapping is proposed, reviewed, or approved. That status determines how confidently the data can be used later.
Once the first archetypes exist, the organization can build a view of skills supply without assuming that an employee possesses every skill attached to their title.
Existing HR systems often contain synonyms, abbreviations, duplicates, local terminology, and different levels of detail. One may record “financial analysis,” another “finance analytics,” and a third the tool used to perform it.
Normalize these terms against the governed skills language first. Otherwise, an enterprise profile campaign increases the amount of information the team will later need to clean.
| Source | What it can tell you | What it does not prove on its own |
|---|---|---|
| Employee declaration | Hidden experience, interests, and capabilities | Validated proficiency |
| Resume or work history | Prior roles, projects, and credentials | Current ability or depth |
| Learning completion | Recent exposure to a capability | Independent application |
| Assessment | Performance against a defined measure | Use in every work context |
| Certification | Verified knowledge within its scope and validity period | Permanent proficiency |
| Project or gig | Application in a specific setting | The employee’s exact contribution without context |
| Manager or expert review | Current work context and observed application | A complete view free from visibility bias |
Each employee-skill record should retain its source, date, context, proficiency, and validation status. Inferred, declared, observed, assessed, and validated skills can all contribute, with their weight determined by the decision.
The role archetype says which skills the work requires. The employee record shows the evidence that the person has those skills.
Holding the role should not automatically award every requirement at the expected level. Someone can also demonstrate a capability without holding the title normally associated with it. Preserving that distinction is how the inventory begins to reveal hidden and adjacent talent that the old architecture could not show.
Ask the employees and managers involved in the first use case to review the skills that matter to it. Their corrections will show whether the archetypes, proficiency definitions, and evidence rules are working.
This targeted cycle creates a manageable set of data to inspect and improve. Once it supports a real decision, the organization can extend it to the next role family or priority.
The inventory should do more than consume job data. The patterns it reveals can show where the architecture itself needs to change.
| What the inventory reveals | What to review in the job architecture |
|---|---|
| Different titles with nearly identical outcomes and skill profiles | Whether the roles should be standardized or consolidated |
| One title covering several distinct skill clusters | Whether the role should be divided into separate profiles |
| Skills employees use repeatedly but the role does not contain | Whether the work has changed without the profile changing |
| Similar capabilities across separate job families | Whether an adjacent career path is missing |
| Little difference in proficiency between levels | Whether progression criteria explain growth clearly enough |
| An emerging skill cluster across several roles | Whether a new specialization, pathway, or role is forming |
Two roles with different names may require the same outcomes, skills, and proficiency. That pattern gives the architecture team a reason to examine whether local naming or history created unnecessary duplication.
High overlap prompts an investigation. The organization should still be able to explain why the roles remain distinct.
When people under one title need materially different skill bundles, a single profile weakens hiring criteria, development recommendations, career paths, and compensation comparisons.
Separating those populations can make the architecture more accurate while giving employees a clearer account of what movement between them would require.
If adjacent levels carry the same skills at the same proficiency, the architecture may describe seniority without explaining how the work grows. If employees repeatedly move between job families that the architecture treats as unrelated, the inventory may be exposing a real pathway built on transferable skills.
Every approved change improves the next inventory, which then produces better evidence for the next architecture decision. The two structures converge through use.
A staged build still needs clear ownership. Without it, provisional mappings quietly become permanent and different teams create new versions of the same skill or role.
The core HR record can remain authoritative for employee identity, job code, official title, level, reporting relationship, and employment status. The skills layer can govern skill definitions, proficiency levels, role-to-skill mappings, employee evidence, validation status, and change history.
Those boundaries let approved updates move between systems without creating competing sources of truth.
Use statuses such as imported, inferred, proposed, reviewed, approved, and retired. A proposed mapping may be useful for discovery. An approved mapping can support more consequential decisions.
Reviews should be triggered when strategy changes, technology alters the work, a reorganization moves responsibilities, hiring teams repeatedly rewrite a profile, or employee evidence conflicts with role requirements.
Track the share of priority archetypes reviewed, employee-skill records with traceable evidence, inferred skills accepted or corrected, duplicate roles identified, and decisions supported by validated data. Also track whether the inventory surfaces internal candidates or career adjacencies that titles previously hid.
Enterprise coverage matters eventually. Early progress should be judged by whether the inventory makes a priority decision more trustworthy.
Fuel50 can work with existing job descriptions, role data, skills frameworks, and partial taxonomies before a complete architecture redesign is finished. A phased approach can begin with one business unit, role family, or workforce decision and expand from there.
Fuel50 Skills Architecture uses the organization’s existing data, Fuel50’s skills ontology, and market signals to recommend skills and proficiency requirements for roles. Managers and subject-matter experts can review the proposed profiles so the mapping reflects the work rather than simply reproducing an old description.
Fuel50 Skills Inventory provides the governed repository behind that work. It brings together skills from multiple sources, identifies duplicates, manages additions and approvals, and records how skills and roles change over time.
Once the foundation is reliable, Fuel50 Skills Intelligence can support workforce planning, development, internal mobility, and succession. Those workflows produce more information about what employees can do and how work is changing, strengthening the next version of both the inventory and the architecture.
Treat the existing job architecture as a source to test, then repair it as the inventory produces better evidence. The wider redesign can continue in parallel.
Start with one priority area. Describe the work as it happens now. Create provisional role archetypes. Map the capabilities that explain success, proficiency, and movement. Then collect employee evidence against that clearer structure.
The resulting inventory can support its first decision while showing where roles overlap, titles hide different work, levels lack meaning, and new paths are forming.
The first inventory gives the organization better evidence for rebuilding the job architecture, one decision and role family at a time.