When to split, merge, or retire a skill
Splitting, merging, and retiring a skill correct different failures. Even if the catalog looks tidier after the change, the choice depends on which distinction in the work must be preserved and which decisions will change.
An architecture deteriorates when every difficulty adds another entity. It also deteriorates when the pursuit of simplicity eliminates differences that matter.
The size of the catalog offers no universal answer. The question is whether its units represent variations in contribution that change assessment, assignment, or development.
- Split: one entity contains manifestations that progress separately. The risk is fragmenting an integrated practice.
- Merge: two entities use the same evidence and never change a decision. The risk is erasing distinct responsibilities.
- Retire: the entity has lost its work or its ability to differentiate. The risk is mistaking low frequency for obsolescence.
Split when one label conceals different trajectories
“Data management” may combine model design, access governance, and analysis for decisions. A broad definition does not prove that they should be separated.
Look for cases in which someone consistently demonstrates one part but not another. Review whether each manifestation requires different evidence, responsibilities, or progression. Then determine whether the distinction changes a real decision.
Splitting improves interpretation when it stops averaging contributions that advance along different paths. It increases maintenance and requires explicit relationships between the new pieces.
After a split, neither piece should automatically inherit all previous evidence. Some episodes will support both; others, only one. Migration must preserve that limit so a conceptual separation does not create two artificially complete histories.
Review the level as well. Sometimes the entity seems to contain two skills because the expectations conflate technical progression with breadth of responsibility. Correcting the anchors may resolve the problem without splitting the catalog.
Merge when the distinction preserves only history
Two skills may have different names because they originated in different teams. If they always appear together, use the same evidence, and produce indistinguishable expectations, the separation adds little.
Test several roles in the track. Ask assessors to associate different behaviors with each entity. Examine whether an intervention or assignment would change depending on which one was selected.
Merging is wrong when frequent collaboration conceals separable responsibilities. The fact that two contributions occur together does not mean they should be assessed as one.
Preserve historical traceability. If earlier data used both entities, document how it will be interpreted after the merge and which comparisons will no longer be valid.
Merging does not require deleting familiar terms either. They can remain as search aliases or transition language while the canonical entity changes. This preserves access without maintaining two assessments that no longer distinguish decisions.
Retire when the entity no longer represents work
A skill may lose demand because a tool absorbed the task, another capability incorporated its manifestations, or the standard changed.
Low frequency is not enough. Some contributions occur rarely and protect against significant risks. Before retiring one, review obligations, critical scenarios, and historical uses.
When the work disappears, define the destination of its evidence and relationships. Part of the history may retain value for auditing or mobility; another part should no longer feed current recommendations. Retiring a skill means closing its uses, not hiding it from the visible catalog.
There is also a fourth option: make no change. An isolated signal may arise from poor examples, an ambiguous definition, or a lack of training among the people using the architecture. Repairing those conditions costs less than migrating the entire system.
NIST maintains the NICE Framework through components such as categories, work roles, competency areas, and task, knowledge, and skill statements. The current version separates those components and their relationships to enable updates. NIST, NICE Framework: Current Versions (opens in a new tab).
The framework belongs to cybersecurity and does not prescribe a general enterprise taxonomy. Its design shows why an architecture needs distinct entities and maintainable links.
The decision travels through the entire system
Splitting changes levels, assessments, and historical data. Merging may change an entry expectation. Retiring does not authorize deleting evidence that must still be retained for a legitimate purpose.
The change needs an owner. Someone must update relationships, materials, assessments, and development paths, as well as communicate the date on which the new configuration takes effect.
NIST clarifies that its work roles group work and are not synonymous with jobs or occupations; it connects them to tasks, knowledge, and skills. The distinction helps prevent a catalog change from becoming nothing more than a renaming of jobs. NIST, Getting Started with the NICE Framework (opens in a new tab).
Document the signal, the cases reviewed, the decision, its effects, and the effective date. A maintenance routine makes it possible to accumulate those signals without reopening the entire catalog. Test the configuration with work different from the work that prompted the review.
Before completing the migration, also confirm that the people using the architecture can explain the new distinction without reverting to the old name. Operational understanding is part of the change, not a later task.
The final criterion is operational. An architecture improves when it recognizes differences that change decisions and removes distinctions that no one can sustain with evidence. If the adjustment merely produces a tidier structure, what sufficient reason remains to make the change?
To extend this reading, see When to create a new role and when to redesign an existing one, which develops a complementary dimension of the problem.
Keep exploring
What must remain common and what can vary across areas
Even when two areas work differently, they can still share an architecture. Adaptation stops being local when it changes meaning, comparability, or the rights attached to use.
Designing the interfaces between teams is also designing capability
On the eve of a launch, an incomplete interface can immobilize capability that each team does possess.
The organization can have the right skills and the wrong operating model
An organization can have the right skills and still fail to produce the expected capability. Even when the inventory is accurate, the rules of work may prevent those skills from being used.
When to create a new role and when to redesign an existing one
Should the organization create a new role or redistribute the work? The answer depends on the stability, distinctiveness, and accountability of the missing contribution.
How to maintain an architecture without turning it into a permanent project
Maintaining an architecture starts with distinguishing a signal worth recording, a small change with a clear owner, and a structural decision that deserves deliberate review.
Generalists, specialists, and hybrid roles: what the architecture should decide
Does the organization need breadth, depth, or integration? Generalist, specialist, and hybrid are possible answers, not identities the architecture should fix permanently.