A stepped wooden structure with columns, platforms, bowls, and a sphere.

Track, role, and level — three concepts that should not be mixed

Track, role, and level answer different questions. When an architecture treats them as synonyms, every change in title ends up altering skills, expectations, and mobility paths that should remain separate.

PRYSMAP02.26.20269 min read

The confusion is often hidden in names that try to explain too much: Senior Data Analyst II, Analytics Technical Lead, or Expert Specialist. A single label combines a professional family, a type of work, hierarchy, and degree of proficiency. In a small organization, everyone believes they understand it. As the organization grows, questions arise that the name can no longer answer.

Do two people with different titles belong to the same career path? Does a promotion change the work, or only the degree of responsibility with which it is performed? Does someone need to learn new skills to advance, or demonstrate greater depth in the skills already shared across their track? Is a role change vertical growth, or mobility into another family?

An architecture must represent these questions separately.

Three coordinates, not three labels

One useful way to organize the problem is to treat track, role, and level as three coordinates within the same structure.

Concept	Question it answers	What it organizes
Track	Which family of work and development does this contribution belong to?	A shared set of skills and a recognizable path.
Role	What contribution is expected from this position within the track?	Responsibilities, scope, expectations, and required evidence.
Level	At what degree of responsibility is a skill applied or an expectation met?	Depth, autonomy, complexity, influence, and impact.

The terminology is not universal. A company may call a track a job family, a role a position or profile, and a level a grade, band, or proficiency level. The labels matter less than the logical separation.

This separation also appears, under different terms, in public frameworks. NIST’s NICE Workforce Framework defines a work role as a grouping of work for which an individual or team is accountable and connects it to tasks, knowledge, and skills. ESCO maintains occupations and skills as separate pillars linked through explicit relationships. SFIA describes levels of responsibility through attributes such as autonomy, influence, and complexity. None of these frameworks corresponds exactly to a particular organization’s architecture, but all demonstrate the value of not collapsing work, capabilities, and responsibility into a single category.

The track preserves the family

The track is the unit of continuity. It groups roles that belong to the same family of work and share exactly the same set of skills. This stability preserves a common path even as titles, scope, or formal structures change.

Consider a hypothetical Product Analytics track. Its skill set might include framing questions, preparing data, conducting analysis, communicating findings, and governing information. An Associate Analyst, Analyst, and Lead Analyst within that track work from the same catalog. They do not need separate lists for their contributions to differ.

The distinction lies in the expectation. One person may follow a defined procedure to answer a bounded question; another may choose an approach when information is incomplete; a third may establish criteria that guide decisions across several teams. The expected autonomy, complexity, scope, and evidence change. The family remains.

This rule also makes the boundary of a track visible. If two groups require structurally different skill sets, they may not belong to the same family even if they report to the same executive. Conversely, if their skills are essentially the same, creating a track for every title is probably duplicating the architecture.

A reorganization can move teams, change reporting lines, or combine departments without altering the nature of the work. If the architecture mirrors every reporting line, each structural change makes it unstable.

The role configures an expected contribution

A role turns the shared family into a concrete expectation. It specifies what a position within the track is expected to contribute: the problems it addresses, its scope, the autonomy with which it operates, the decisions it supports, and the evidence that would demonstrate sufficient performance.

This allows two roles to share the same skills without being equivalent. Within the Product Analytics track, an Analyst role might require solving known questions with autonomy over the method and limited collaboration with product teams. A Lead Analyst role might be expected to address ambiguous problems, influence work across teams, and define criteria for others. The catalog remains the same; the profile of expectations applied to it changes.

If the description incorporates the current occupant’s preferences, strengths, or temporary tasks, it stops representing an organizational need and becomes a biography. When that person moves, the architecture becomes outdated even though the work still exists.

Nor should a role be equated with a contractual title. A title may reflect the market, compensation, internal history, or recognition. The role must describe the contribution precisely enough to assess, develop, and compare it. Sometimes the two names will coincide; the architecture should not depend on that coincidence.

The level describes how responsibility is exercised

A level introduces progression without creating a new family. It describes differences in the autonomy with which decisions are made, the complexity that can be addressed, the reach of a person’s influence, the depth of application, and accountability for outcomes.

SFIA provides a clear example of this logic. Its levels progress from work performed under close direction to responsibilities requiring greater autonomy, influence, and complexity. The scale works across domains: it does not need a different definition of autonomy for every skill or position.

In an internal architecture, level works better as a shared reference than as a substitute for role. A role may have different expectations for different skills. An Analyst, for example, may require a high level of analysis and an intermediate level of facilitation. Reducing the entire role to level 3 would conceal that profile. Likewise, the available evidence may show that a person demonstrates a different level from the one expected; level should not become a permanent identity.

Level does not mean tenure, either. Years of experience may create more opportunities to learn, but they do not by themselves demonstrate autonomy, complexity, or impact. Seniority is a convention used in titles; a level requires observable manifestations and known rules.

What happens when the concepts are mixed

Mixing them rarely produces an isolated error. It creates dependencies that spread through the entire architecture.

Every promotion creates another catalog

If junior, senior, and lead are modeled as separate families, their skills are copied and edited independently. Variants of the same concept soon appear: communication for analysts, advanced communication for senior analysts, and strategic communication for leads. The real difference—which belonged in the expectation—is hidden inside three definitions that are difficult to maintain.

An update then forces the organization to decide which copies to change, which to leave alone, and how to explain inconsistencies that were never intentional.

Mobility looks more distant than it is

When every role has its own catalog, every transition appears to require an entirely new set. The organization stops seeing the shared foundation and overstates the gaps. Someone who has already mastered much of the track’s skill set appears to be starting from zero simply because their title changed.

Separation supports a better question: which capabilities can be reused, which expectations change, and where is evidence missing? For a move between tracks, it also reveals which skills are shared, which are new, and which require adaptation.

The organization chart becomes the capability model

If track means department and role means position, every restructuring requires the architecture to be rebuilt. The problem is not merely administrative. Assessment history, development paths, and comparisons lose continuity because the entities that supported them changed along with the boxes on the organization chart.

Level becomes a status label

When level and title are equivalent, a skills assessment can feel like a review of hierarchy or compensation. The result stops describing evidence against an expectation and begins to look like a judgment of personal worth. It also becomes harder to recognize that someone may exceed an expectation in one skill and need development in another.

How the three concepts relate

Separating the concepts does not mean isolating them. The architecture emerges precisely from their relationships.

The track defines the family and preserves its shared set of skills. The role selects the expectations relevant to a particular contribution within that family. The level helps express the expected depth, autonomy, complexity, scope, and impact. The assessment provides evidence of how a person meets those expectations in a particular context.

The result should not retrospectively change the architecture. When someone demonstrates more capability than expected, that information can guide development, assignment, or mobility; it does not automatically turn their role into another one or require the creation of a personal track. Likewise, a title’s existence in the payroll system is not enough to justify a separate entity in the model.

A metal positioning stage with rails, adjustment screws, and a cubic block.

Relating the pieces this way allows each change to occur where it belongs:

if the nature of a family of work evolves, the track and its skill set are revised;
if the contribution expected from a position changes, the role is updated;
if the organization redefines what it means to operate with greater responsibility, the level scale is revised;
if new evidence emerges about a person, the interpretation of their situation changes, not the definition of the entire structure.

Maintainability comes from this controlled independence. Each entity has a purpose, an authority responsible for changes, and identifiable effects on the others.

An intelligible architecture can be explained without titles

There is a useful test for the model: remove the job titles for a moment and try to explain each decision.

Why do two roles belong to the same track? Because they share a family of work and the same set of skills. Why are they not the same role? Because the expected contribution, scope, or evidence differs. Why does an expectation correspond to a higher level? Because it requires greater autonomy, complexity, depth, influence, or observable impact.

If every answer returns to the title, the architecture still depends on local conventions. If the model can be reconstructed through relationships and criteria, it will be better able to withstand new roles, reorganizations, and name changes.

Track, role, and level do not compete to describe the person. Together, they describe the system in which that person’s contribution can be understood: where the work belongs, what is expected, and the degree of responsibility with which it must be sustained.