Who should own a skills architecture

The question of ownership is often framed as a choice between central control and local autonomy. That choice is incomplete. An architecture connects definitions, relationships, levels, evidence, and uses; no single function holds all the authority needed to maintain them.

Sound governance distributes decisions without diluting accountability. Doing so requires the organization to distinguish what must remain shared, what requires domain expertise, and who is accountable when a change affects talent decisions.

Central stewardship: protect coherence

A central function—usually People or Human Resources—should steward the architecture’s language and contract. It defines the criteria for naming a skill, preventing duplicates, relating tracks and roles, versioning changes, and maintaining traceability.

Its authority does not come from knowing every kind of work better. It comes from seeing the system as a whole. The central function can detect when two areas create equivalent concepts, when one level is expressed in terms incompatible with the rest, or when a local change disrupts mobility and comparability.

When the central team begins writing technical capabilities without domain validation, it gains uniformity at the expense of validity.

Domain authority: preserve correspondence with the work

Functional leaders and subject-matter experts should be accountable for keeping content in their domain current: which capabilities matter, how they appear in the work, which differences in complexity distinguish the levels, and which changes in the work make a definition obsolete.

This authority requires evidence. Familiarity with the domain is not enough to turn personal preferences into standards. A definition must be testable against real decisions, outcomes, procedures, constraints, and situations within the role.

Nor does domain authority imply exclusive ownership. A skill shared across several tracks should not change merely because one area interprets it in a particular way. The domain proposes and validates; central stewardship resolves the cross-cutting impact.

Decision owners: require fitness for use

The same architecture may support development, mobility, selection, succession, and workforce planning. Each use imposes different requirements. Those accountable for these decisions must define the recency, precision, and degree of evidence required before a result can be used.

This layer guards against a common illusion: that a technically correct definition is automatically authorized for every consequence. Use in a development conversation can tolerate uncertainty that would be unacceptable in a compensation or exclusion decision. The owner of the consuming process must explicitly accept the limitations and must not expand the purpose for convenience.

Participants: test interpretability and legitimacy

The people described by the architecture are not passive recipients. They can identify terminology no one uses, levels that cannot be distinguished, and manifestations that depend on opportunities not available to everyone.

Their participation does not replace technical authority or turn every definition into a vote. It tests something different: whether the language can be understood, whether it represents the work, and whether its consequences can be explained to the people who will be assessed against it.

Evidence and technology governance: control what scales

When the architecture feeds assessments, analytics, or automated systems, responsibilities arise for data quality, access, privacy, bias, interoperability, and changes to the model. These responsibilities may be distributed across data, technology, risk, legal, and talent governance, but the controls must belong to the same change cycle.

A rule for resolving conflict

The framework can be summarized as a decision rule:

Central stewardship. Decides matters of coherence, structure, and versioning.

Domain authority. Decides matters of correspondence with the work.

Process owner. Decides whether the evidence is sufficient for a particular use.

Participants. Validate understanding, access, and effects.

Governance functions. Control risks related to data, technology, and consequences.

When two authorities disagree, the answer is not to find the one with greater hierarchy. It is to identify which property is in conflict. A definition may be faithful to the domain and incompatible with the shared language at the same time. Neither side should prevail until both conditions are resolved.

Governance remains incomplete until the organization can name who resolves each of these tensions, what evidence they must present, and how the decision is recorded for the next version.