The Illusion of the Job Title

Most leaders are quietly exhausted by an invisible trap: the belief that a job title dictates everything a person should or can do. When things fall through the cracks on a team, we tend to assume it’s a performance issue, a lack of initiative, or a bad culture fit.

More often than not, it’s a structural illusion. We have confused the person with the position, leaving critical work unowned while high performers burn out trying to be everything to everyone.

The Source / Framework

Psychotherapist Phil Stutz highlights the danger of fusing your core identity with a static snapshot of your external role. When you treat a temporary function as your entire identity, any failure in the process feels like a personal flaw, and any change feels like a threat.

In organizational life, frameworks like Sociocracy offer a direct solution to this psychological weight: decouple the person from the function. Traditional job descriptions bundle dozens of disparate activities into a static title like “Product Manager”. Role-based work, by contrast, separates work into lightweight, explicit responsibilities that anyone with the right capability can perform.

The Reframe

The territorial behavior, boundary wars, and classic “that’s not my job” pushback on your team aren’t signs of poor character. They are signals of unmapped responsibility and a symptom of “exclusive permission” thinking.

Furthermore, holding a role defines work you do, not work you just make others do. True accountability is an active practice of performing the recurring work, not passive oversight.

Leadership Application

1. Unpacking the Core Elements

To fix these structural tensions, start by separating four distinct concepts in your organizational design:

• Person: An individual member of the organization bringing human energy.
• Capability: Something that person actively knows how to do right now.
• Role: A coherent body of work and responsibility in the system.
• Actor: Who or what (human, AI, external team) currently performs that role.

2. A Concrete Example: The Small Development Team

Imagine a software team of five people developing and operating a product. Instead of relying solely on titles like “Architect” or “Developer,” the team identifies the actual work required across three distinct role families:

• Delivery Roles: Work that directly creates value through the product, such as Product, UX, and Development.
• Stewardship Roles: Active work that protects an important quality of the system over time, such as Architecture, Quality, Security, and Documentation.
• Team-System Roles: Work that helps the team function, learn, and evolve, such as Meeting Facilitator, Decision Recorder, Onboarding Guide, and Team Improvement Steward.

In practice, a single team member can hold multiple roles. For instance, Alice might energize Product, UX, and Customer Feedback, while Diego energizes Development, Security, and Documentation. Diego holding the Security role doesn’t mean the team needs a full-time Security Engineer; it means Diego dedicates a portion of his active focus to performing security work. The roles I picked here as examples are too big. The following example shows how they could and should be a bit smaller.

3. Roles, Accountabilities, and Tasks: The Decision Recorder Breakdown

To design roles effectively, distinguish between the role’s purpose and its accountabilities. Let’s examine a specific team-system role, the Decision Recorder:

• Role (The Coherent Body of Work): Decision Recorder exists to make important decisions easy to find and understand across the organization.
• Accountabilities (Recurring Work & Ongoing Responsibilities):
  Detect significant decisions as they happen.
  Capture decisions along with their rationale and context.
  Maintain the decision log history.
  Surface obsolete or conflicting decisions over time.

4. Understanding Role Granularity

A crucial design question is deciding how broad or narrow a role should be. The guiding principle is: Split roles as far as useful, not as far as possible. A role should be small enough to delegate, but large enough to own.

• When to keep responsibilities together: Look at the Decision Recorder role above. You could theoretically split it into Decision Detector, Decision Writer, Decision Publisher, and Obsolete Decision Detector. However, these responsibilities are tightly connected. Atomizing them into microscopic roles creates handoffs, administrative fragmentation, and more coordination effort than clarity.
• When to split a role: Decompose a broad role when different accountabilities require distinct decision authorities, different capabilities, or operate at different cadences. As a product grows, a monolithic Product role might naturally be split into Customer Discovery, Product Prioritization, Product Outcomes, and Product Communication.

A Practical Takeaway

The Coaching Prompt

• What critical work is currently getting done through individual heroic effort rather than an explicit role?
• Where on your team is someone “accountable” for a result, but only doing passive oversight instead of actively performing the work?
• If you decoupled your team’s job titles from their daily focus, what 2–3 roles are they actually energizing right now?
• Are you treating any of your current responsibilities as “exclusive territory” rather than shared domains?