EN
A modular pipe network assembled on a tray, with parts sorted by type.

A list of skills is not an architecture

A catalog identifies which skills exist and how to find them. An architecture adds the relationships needed to interpret expectations, assess evidence, guide development, and identify paths between roles.

PRYSMAP5 min read

The distinction is not about size. An organization may maintain hundreds of well-defined terms and still have no clear sense of what they mean within a role. It may also start with only a few skills and build enough relationships to support real decisions.

What a list does well

Catalogs solve concrete problems. They reduce duplication and synonyms, assign identifiers, group concepts, and make them easier to find. Without that foundation, each part of an organization ends up naming similar capabilities in different ways.

ESCO, the European classification of skills and occupations, describes itself as a multilingual dictionary. Its concepts include terms, descriptions, and relationships that allow them to be used in employment, education, and analysis services. Its public utility illustrates two distinct layers: classifying entities and connecting them so that other decisions become possible. European Commission, “What is ESCO?”

A company does not need to replicate that scale. It does need to recognize the limits of an isolated row. “Risk management” may be correctly defined and categorized, but that alone does not indicate the depth a role requires, the evidence that would demonstrate mastery, or how much of the capability could transfer to another context.

Two models that look similar from a distance

In the inventory model, each skill occupies a row. It may have a description, category, and tags. When a new role appears, the usual response is to assign it a set of rows. If more precision is needed, variants are created: junior, senior, strategic, or specialized risk management.

That approach appears straightforward. It can also fragment a single capability with ease. Differences in the work become hidden inside new names. Comparing roles becomes difficult because progression is represented as if each stage were a separate skill.

The relational model preserves a shared set where appropriate and locates the differences elsewhere. It connects a skill to levels, observable manifestations, tracks, roles, expectations, and evidence. The questions change:

  • What remains the same across two roles?
  • What level, degree of autonomy, or scope does each require?
  • What observations support that distinction?
  • What relationship enables a development or mobility decision?

Level acquires meaning through a relationship

SFIA combines professional skills with seven levels of responsibility. These levels describe changes in responsibility, accountability, and impact, and provide a basis for mapping organizational structures and career paths. The framework emphasizes that competence is demonstrated in real work situations, not through theoretical knowledge alone. SFIA, “How SFIA works”

This example should not become a universal rule. SFIA originated in digital disciplines and has its own architecture. Its contribution here is to show that level is not merely an adjective added to a skill’s name. It is a relationship to the kind of responsibility being exercised.

Within a track, several roles may share exactly the same skills. Their differences lie in the expected depth, autonomy, complexity, scope, leadership, impact, and evidence. This avoids creating a separate catalog for every position and preserves an intelligible progression.

Beyond a track, the architecture needs a different kind of relationship. Some skills will be shared; others will be new. Between them lies a less comfortable area: demonstrated capabilities that need adaptation before they can transfer to another context. A list usually shows where terms match. An architecture must also represent the distance between them.

Relationships carry assumptions

Connecting a skill to a role does not prove that a person has mastered it. Linking a skill to a category does not explain how to assess it. Assigning an expected level does not prescribe a development plan.

Each relationship answers one question and leaves others open. A category improves navigation. A level distinguishes degrees of performance. An expectation places that degree within a contribution. Evidence supports a conclusion about a person. Transferability estimates what might remain applicable in a new context.

When the model confuses these functions, decisions inherit the error. A system may infer a gap because evidence is missing. It may recommend training when the real constraint is a lack of authority. It may declare two roles “close” because they share terminology, even when the conditions in which the skills are applied are incompatible.

Architecture does not eliminate these risks. It makes them visible and gives the organization a place to discuss them.

A modular wooden railway track forms a loop with switches and a bridge; a railcar rests on one section.

Remove a relationship to test its value

There is a practical way to examine an architecture: mentally remove each connection and see which decisions no longer hold.

Without categories, maintenance and navigation deteriorate. Without observable manifestations, a skill retains its name but loses an assessable object. Without levels, progression is difficult to distinguish. Without role expectations, a score has no reference point. Without evidence, proficiency becomes an assertion. Without relationships among roles and tracks, mobility and succession depend on superficial similarities.

This test also helps avoid unnecessary complexity. A relationship is worth maintaining when it clarifies an interpretation, prevents an inconsistency, or supports a consequential decision. If no one can explain what would change if it were removed, the model may simply be accumulating structure.

A useful architecture is not the one with the most nodes and connections. It is the one that provides a path, without hidden leaps, from a definition to a decision. Maintaining that usefulness requires distinguishing signals that justify a correction from those that require structural review.

  4. The cover of Sorting Things Out on a wooden table beside a small paper box.

    Sorting Things Out: every taxonomy describes and decides

    The book Sorting Things Out examines how categories and standards organize the world while distributing visibility, work, and consequences. Reading it through the lens of a skills architecture extends that inquiry to the decisions a taxonomy makes possible.