Role vs. Job Description: Why Agile Teams Use Dynamic Roles

The Static Document Trap

When a team needs to hire someone, HR writes a job description. It outlines a generic title, a list of required skills, and a bulleted list of initial duties. The candidate is hired, the document is filed away in a shared drive, and it is rarely looked at again until an annual performance review. As the organisation scales and realities shift, the work the person actually does diverges entirely from that original document. This creates a “shadow structure” where no one truly knows who owns what, leading to bottlenecks and dropped responsibilities.

Role vs. Job Description Defined

To fix this structural chaos, modern organisations must separate the person from the work. A job description is a static HR document used to evaluate, hire, and compensate a person based on their general background. A role is a dynamic governance unit that defines explicit, ongoing accountabilities and decision-making domains, completely uncoupled from the specific person filling it.

Comparison: Jobs vs. Roles

Anatomy of a Dynamic Role

In role-based work structures, you do not assign a project to “The Marketing Manager.” You assign it to a specific, modular role. A well-designed role requires three distinct elements:​

1. Purpose: A brief statement explaining why the role exists. (e.g., “The brand is consistently presented across all channels.“)
2. Accountabilities: Ongoing activities the role is expected to perform.
3. Domains: Exclusive decision-making rights. If a role holds a domain over the “Website CMS,” no one else can alter the CMS without their explicit consent.

How to Write Role Accountabilities

A common mistake when transitioning to role-based work is writing accountabilities that look like one-off tasks. Accountabilities must be continuous, observable activities. Always start accountabilities with an -ing verb to signify ongoing action.​

Bad Examples (Too vague or project-based):

• “Be in charge of the newsletter.”
• “Redesign the pricing page.”
• “Sales.”

Good Examples (Ongoing and observable):

• “Drafting and sending the weekly customer newsletter.”
• “Optimising website conversion rates based on analytics.”
• “Defining target customer segments for Q3 outreach.”

When accountabilities are written this clearly, “who owns this?” is no longer a question that requires a one-hour meeting to resolve.

Building a Living Org Chart

You cannot manage dynamic roles in a static format. If you try to track these accountabilities in Notion or Excel, the documents will quickly suffer from page drift, and the team will stop trusting the system.​ Governance requires mechanics. When a team member feels a “tension” (a gap between what is and what could be) they need a system to propose a change to a role’s accountabilities. This ensures the organisational structure evolves at the exact speed of the market.

Keyroles is built precisely for this transition. It replaces vague job titles with a living, dynamic org chart. You can define purposeful roles, assign explicit accountabilities, and empower your team to keep the structure up to date as reality changes.