Every few years, a mid-size operator goes through a reorg — divisions merge, job families get renamed, reporting lines shift. When that happens, the competency framework built for the previous structure usually breaks. Skills mapped to job codes that no longer exist. Learning paths tied to role titles that IT has already retired in the HRIS. An IDP template that references a "Senior Field Technician II" designation that the new org chart replaced with "Technical Specialist."
The failure mode isn't a bad framework. The failure mode is a framework designed around the wrong anchor. Most competency frameworks are anchored to job titles and org-chart positions — both of which are management decisions that change without notice. A framework that survives a reorg is anchored to something more stable: the work itself, not the label the org gives to the person doing it.
The Difference Between a Job Code and a Job Family
The distinction matters more than most L&D teams give it credit for. A job code is an HR system artifact — a string in Workday or SuccessFactors that maps to a pay band, a cost center, a requisition type. Job codes change whenever HR restructures. A job family is a grouping of roles that share a common work domain, a set of core competencies, and a common progression path. Job families are much more stable.
Consider a regional energy operator with 1,800 employees across field operations, dispatch, and plant maintenance. The field operations arm might have job codes FTEC-01 through FTEC-04 — Entry Field Tech, Field Tech, Senior Field Tech, Lead Field Tech. A reorg collapses that to FOPS-I through FOPS-III. If your competency framework was built to the first set of codes, you've just invalidated half your learning path assignments.
If instead the framework is built to the job family — "Field Operations Technician," with competency domains covering electrical safety (OSHA 1910.333), equipment operation, documentation and work orders, and emergency response protocols — none of that changes when HR renames the codes. The competency anchor holds. The path still works. The reorg that consumed six months of HR's energy is a two-hour update to the code-to-family mapping table, not a rebuild of the learning architecture.
Competency Domains vs. Skill Lists: Why the Distinction Survives Operations
One of the conceptual traps in competency framework design is treating "competency" as synonymous with "skill." The two operate at different levels of abstraction, and conflating them produces frameworks that are simultaneously too granular and too brittle.
A skill is atomic and often tool-specific: "can operate the Trimble S7 total station" or "can configure route parameters in dispatch software." Skills change as tools change — upgrade the dispatch system, the skill is potentially obsolete. A competency domain is the broader capability: "field measurement and survey operations" or "dispatch and routing operations." Specific skills are evidence of competency attainment, but the domain itself is durable.
For an ops workforce, this plays out in how you build role-mapped learning paths. If your path says "complete Module 14: Trimble S7 Operations," and the operator switches to a different instrument, you need a new module and a new path assignment. If your path says "demonstrate competency in field measurement and survey operations — assessed via current instrument proficiency," you update the skill evidence without touching the path architecture.
We're not saying skill-level tracking is unnecessary — for OJT records and OSHA documentation, granular skill evidence absolutely matters. What we're saying is that the competency framework itself should operate at the domain level, with skills attached as evidence nodes, not as the structural foundation.
How Role Adjacency Shapes Path Design for Large Operators
One thing that distinguishes enterprise ops L&D from corporate learning more broadly is the importance of role adjacency — the structured relationship between adjacent job families on the same vertical or lateral track. A dispatcher who wants to move into a field ops role, or a plant maintenance tech who is on track to become a supervisor, has a learning path that crosses job family boundaries.
Designing for adjacency requires knowing which competency domains overlap between families (shared foundation, no duplication) and which are additive (new domains required for the adjacent role). In a well-built framework, that map is explicit — not inferred at the time of promotion. The supervisor track at a healthcare system's facilities ops division (four sites, ~200 facilities staff) might require completing the core facilities maintenance family competencies plus three additional domains: performance management, budget operations, and safety program ownership. Those aren't improvised when someone is promoted; they're mapped in advance and the path is ready.
When role adjacency is built into the framework upfront, IDP automation becomes tractable. An employee in the dispatcher family who has indicated interest in field ops can have an automated development track assigned against the adjacency map — not manually curated by an L&D manager who may or may not have bandwidth in any given quarter.
The Practical Architecture: What Survives a Reorg
A competency framework that survives a reorg typically has this architecture:
- Job family layer — 8–15 job families covering the major work domains at the operator (field ops, dispatch, plant maintenance, supervisory/management, compliance and safety, HR/admin). These don't change with reorgs; they change when the business model fundamentally changes.
- Competency domain layer — 5–8 competency domains per family, describing the broad capability areas. These might get updated when technology or regulatory requirements shift (a new OSHA standard, a new equipment platform), but the structure is stable.
- Skill evidence layer — the specific, observable behaviors and knowledge items that serve as evidence of domain competency. This is the layer that changes with tools, regulations, and role evolution. It is intentionally designed to be updated without touching the layers above it.
- Code-to-family mapping table — a lookup that maps current HRIS job codes to job families. This table changes with every reorg. It is the only thing that changes. If a reorg is breaking your learning paths, it's usually because this table doesn't exist or isn't maintained.
The mapping table is maintained in Workday (or SuccessFactors, or the HRIS of record) as a custom field or attribute on the position object. When HR creates a new job code, the process includes assigning it to a job family. Without that discipline, the disconnect between HR's structure and L&D's framework grows until the next reorg makes it a crisis.
When the Framework Does Break — and How to Detect It Early
Even well-designed frameworks drift. The warning signs at an operator level typically are: a rising percentage of auto-assigned paths where employees complete nothing (path irrelevance), a growing queue of manual overrides from managers ("just assign them this specific course, ignore the path"), or a mismatch between the compliance-required training calendar and what the learning paths actually surface.
One useful diagnostic: run a quarterly check on path completion rates segmented by job family. If a specific family shows sub-40% 30-day completion on newly assigned paths, either the path is wrong for the role or the assignment trigger is broken. Both are framework maintenance issues, not individual employee issues. The framework is not a document you file after an L&D offsite — it's a live data structure that requires the same maintenance cadence as any other operational system. Learning path assignments — whether delivered as SCORM packages in a traditional LMS, as xAPI-tracked activity in an LRS, or as role-mapped paths in a purpose-built ops learning layer — all reference the job family identifier, not the raw HR job code. That one architectural choice is what keeps the learning layer intact when the org chart changes.
At Kurios, role-mapped paths are built against the job family layer, not the HRIS job code. When a customer goes through a reorg, the code-to-family mapping is the only update required — the paths themselves stay intact. That's the design principle, and it's why the framework survives what org charts don't.