6 min read

Positions, Roles, and Capabilities

Table of Contents

Most organizations treat position, role, and capability as synonyms — different words for the same thing. They are not. Each describes a different dimension of how people and work fit together, each belongs to a different owner, and conflating them produces predictable failures: misaligned compensation, misassigned work, and — most damagingly — mislabeled problems that the wrong intervention cannot fix.


Position

A position is a formal slot in an organization’s structure. It defines two things: the area of expertise it belongs to and the mastery level it requires — a software engineer at L5 and a principal engineer at L7 hold different positions, not different roles. It is what someone is hired into, promoted into, or exits from. Compensation is anchored to position — pay bands, grade structures, and benchmarking all operate at this level.

Positions are stable by design. They are anchored to area of expertise and mastery level — not to organizational charts or the roles assigned on top of them. The organization can restructure, reassign roles, and change reporting lines without the position itself changing. What would change the position is a change in the area or the mastery level it requires.


Role

A role is a functional assignment — a defined set of responsibilities someone takes on in a given context. Where a position is singular and stable, a role is plural and fluid. A single person can hold many roles simultaneously, and those roles are not confined to the position’s area or level.

A senior engineer might hold a technical lead role in one team and a mentoring role across several others. A product manager might hold an incident commander role during a production crisis. Neither changes the position or its compensation.

This fluidity is intentional. Roles are the mechanism through which positions are activated in day-to-day work. They allow organizations to distribute responsibility without restructuring every time the work changes shape. But because they are fluid, they need to be managed deliberately — role accumulation, role ambiguity, and role conflict are real and common failure modes.


Capability

Capability is what an individual can actually do. It belongs to the person — not to the slot they occupy or the responsibilities they have been assigned. It relates to position and role, but it does not automatically correlate with either.

This is where the concept of mastery becomes important. Mastery, in the sense Daniel Pink develops in Drive, is the intrinsic drive to get better at things that matter. It is not time-served. It is not the natural outcome of occupying a slot for long enough. It is built through deliberate effort, genuine challenge, and feedback.


How the Three Relate

Three different things, three different owners.

The organization owns the position. It defines the area, sets the mastery level requirement, and anchors compensation to it.

The context owns the role. A team, a product, a project, or an incident creates the need for a role, and that need can cross the area and level lines that a position draws.

The individual owns their capability. It is theirs to develop, demonstrate, and — where the organization is paying attention — have recognized. No organizational chart can grant capability. It can only describe what the position and roles require.


The Gap Problem

There are three kinds of gap, and each behaves differently.

A position gap is a compensation problem. When capability and position are misaligned, the compensation is wrong — in either direction. If capability falls short of what the position requires, the organization is paying for a mastery level it is not getting. If the roles someone holds require a higher mastery level than their position — and their capability meets that requirement — they are undercompensated. Neither situation is sustainable.

A role gap is an enterprise problem, but it is asymmetric. A person whose capability exceeds what a role demands is not a problem — there may even be value in the headroom. But a person whose capability falls short of what a role requires is a problem that must be addressed. The severity scales with the role: gaps at senior levels affect more people and more decisions, but the same logic applies to critical operational roles, where a capability shortfall can disrupt delivery regardless of where the role sits in the hierarchy. The higher the impact of the role — whether by scope or by operational criticality — the more the organization suffers from the gap.

A personal gap belongs to the individual. The enterprise places someone in a position whose mastery level matches the roles it actually needs filled — not the full extent of their capability. From the enterprise’s perspective this is a rational fit decision; it is not paying for capability it does not intend to use. From the individual’s perspective, it is capability that cannot be deployed and is not compensated. The enterprise is not failing here — but the individual needs to be clear-eyed about the arrangement and decide whether it suits them.


📞

How does your organization handle the distinction between position, role, and capability? Do the three stay clearly separate, or do they tend to collapse into one another? Get in touch — I’m always interested in how different organizations approach this.

📡

There’s more to say on this. Follow my RSS feed to catch it when it lands.