How to Define a Role: Method, Examples and Pitfalls

Defining roles means turning each piece of recurring work in a team into a role, then defining its responsibilities: why the role exists, what it decides alone and what the rest of the team can count on it for. Unlike a job description, which describes a contract and ends up in a drawer, a role describes work: it lives in the org chart and changes when the work changes. One person usually holds four or five roles. When the team grows, you split roles and group them into teams rather than adding a layer of managers.

Writing a role takes twenty minutes. Writing a role that still earns its place six months later takes a method and real discipline about wording. The method in this article comes from roles real teams actually wrote, the ones that hold and the ones that fall apart.

The three pieces of a role

Holacracy formalized the format most people borrow. The v5.0 constitution states that a role definition includes "a Purpose to express, Accountabilities to consider and enact, and/or Domains to control". Sociocracy uses the same breakdown with slightly different words, where the domain bounds a role's authority and the purpose is often called the aim.

Three pieces, and in practice only one is mandatory: the accountabilities.

Purpose

The constitution defines purpose as "a capacity, potential, or unrealizable goal that the Role will pursue or express on behalf of the Organization". The word that matters is "unrealizable". A purpose never gets ticked off. It gives a direction the role pursues without ever closing it.

This purpose, written for a Support role, works:

Customers who get a useful answer faster than they expected.

This one, which you read nine times out of ten, fails:

Ensure customer support.

The second one restates the role name and leaves every trade-off open. The test fits in one question: if you can guess the purpose by reading the role name alone, rewrite it. A good purpose settles a trade-off. "Faster than they expected" tells the Support role that speed comes before an exhaustive answer, which the role name never said.

Domain

A domain is "an asset, process, or other thing the Role may exclusively control and regulate as its property, for its purpose". It is exclusive authority rather than influence. Anyone who wants to touch it asks permission.

Domains that work, because you can tell whether a given thing belongs to them:

• The brand's social media accounts
• The published pricing grid
• The public website code repository

"Communication" fails the test. Nobody knows where that domain starts and stops, so everyone keeps asking everyone.

The domain stays optional. Plenty of roles live perfectly well with a purpose and accountabilities. Create a domain only once a decision stalls because nobody knows who calls it.

Accountabilities

An accountability is an ongoing activity other roles expect from this one. HolacracyOne is strict about the form: an accountability starts with a verb ending in -ing, which forces the continuity. In EOS, the Entrepreneurial Operating System, an accountability chart groups seats by function and lists the results each one owns.

For a Recruiting role, these three hold:

• Writing and publishing openings for vacant positions
• Replying to every application within five working days
• Keeping the pool of candidates already met up to date

These two need rewriting:

• Hiring three developers by June
• Improving the employer brand

The first is a task with a deadline. It will be true in June and false in July, so someone will have to reopen the role definition to fix it. Tasks belong in a task list, numeric goals in a set of indicators. The second states a wish without describing an activity, so on a Monday morning nobody can tell what to do about it.

Four verbs that hollow out an accountability

Olivier Compagne, of HolacracyOne, published the most common pitfalls in writing accountabilities back in 2014. Twelve years on, they are still the same ones.

Ensuring and enforcing mandate an outcome the role does not control on its own. "Ensuring 20% growth in revenue" is a goal in disguise. Describe what the role does instead: "Generating demand for our products and closing deals".

Collaborating with and working with say nothing about what actually happens. Name the exact shape of the collaboration: integrating objections, considering suggestions, passing on information on a fixed date.

Overseeing, supervising and managing put back a reporting line exactly where you were trying to remove one. Supporting, assisting or coaching describe what the person really does with their days.

Approving belongs to a domain rather than an accountability. If a role must have the last word on something, put that thing in its domain and the question is settled.

"Holacracy incites us to think differently about how authority and accountability flow between roles." Olivier Compagne, HolacracyOne

Three structural pitfalls

Wording gets fixed on a second read. Bad slicing costs you months.

The role that covers a whole job

"Marketing Manager" with nine accountabilities running from the ad budget to the annual offsite is a job description in disguise. The role is too big to share, too big to hand over, and nobody else can pick up a piece of it.

The most reliable tell is the name itself. A role named after a profession covers a whole job. Name it after a responsibility instead and it shrinks to something one person can hold alongside other roles. Split "Marketing Manager" into "Paid Acquisition", "Editorial Content" and "Events", and three different people can hold them, swap them, or deliberately leave one vacant.

Buurtzorg, the Dutch home care organization, takes this slicing a long way. Its nursing teams, capped at twelve people, share six roles on top of care itself, among them the planner, the informer, the housekeeper and the mentor who handles onboarding. Those six rotate regularly between team members. The organization employs around 14,000 people with roughly fifty at head office and no middle management.

The ghost role

It is born in a governance meeting, because someone really ought to handle the topic, yet it gets assigned to nobody. Six months later it still sits in the org chart, still empty. By then the team has learned to route around the hole.

Two fixes. Assign the role in the meeting that creates it, or drop it and keep the tension open for next time. And review vacant roles at every org chart review: a role empty for a quarter describes work nobody is doing, which is useful information on its own.

The purpose that copies the name

A purpose that restates the role name also belongs among the structural pitfalls, because the flaw spreads. Once the first role in an org chart reads "Ensure customer support", the next thirty read the same way, and the org chart becomes a list of titles with filler underneath. Write the first role with real care, it sets the tone for every role after it.

Assign the role, then keep it alive

A role with no holder clarifies nothing. A holder appointed by default, for their part, ends up with work they never chose.

Samantha Slade, author of Going Horizontal, describes assignment in two phases: everyone reconnects with the roles they already hold, then the team works through invitations and reactions before validating together. She also recommends giving a role to a single person, because a role split three ways goes blurry again.

"A role doesn't belong to a person but rather to the team, division or organization. You don't own a role, you are just caring for it for a time." Samantha Slade

When several people fit a role, the team can run an election without candidates. The team also elects its facilitation roles, such as facilitator or secretary, during the governance meeting.

A new hire receives their roles one at a time, each handed over by the colleague who held it until then. That is how role-based onboarding works.

The definition then keeps changing. A regular governance meeting is where an accountability gets amended, an oversized role gets split, an obsolete one gets archived. The trigger is a tension someone actually felt. A temporary role, such as a tiger team, has an end date written next to its purpose. When that date comes, the team that created it extends it or archives it.

Grow the team without adding management layers

A team of eight usually gets by on informal habits. Around fifteen or twenty people, the same questions come back every week: who decides on this, who was supposed to follow up, who do I ask. The usual answer is a manager for every group of five or six. With each new layer, those questions go up one more level and wait there for someone to decide.

Roles answer the same questions where they come up. As headcount grows, three moves keep the structure flat:

• Split a role when it passes seven accountabilities or when its work needs two people at once. "Paid Acquisition" becomes "Search Ads" and "Social Ads" the day one person can no longer cover both.
• Group roles into a team once they need to coordinate among themselves. The team gets its own purpose, its own governance meeting, and one role that represents it in the parent team. That role links the two levels without making anyone everyone's boss.
• Write a domain for each asset or process people keep stepping on each other's toes over: the pricing grid, the candidate pipeline, the production database. The domain records in writing who decides, so nobody needs a manager to rule on each case.

Open the org chart to the whole team, so a new hire wondering who decides on prices finds the answer in the list of domains instead of asking around.

Where the RACI matrix fits

A RACI describes a split at one point in time, dies with the project, and gets rebuilt from scratch on the next one, while a role outlives the project and the people who hold it. Before you have written your roles, a RACI over two or three recent projects makes a good starting inventory, because its recurring rows convert straight into accountabilities. To try it, start from a RACI matrix template, which comes with three worked examples and that conversion step.

Writing your roles in Rolebase

In Rolebase everything is a role: a role that contains other roles becomes a team, with nothing to convert. Every role carries a purpose, a domain, accountabilities, a checklist, indicators and free-form notes. The checklist and the indicators feed the matching meeting steps directly.

Rolebase adds a few options around the role definition itself.

• A role can be marked as a base role, a shared definition reusable in several places of the org chart. Editing it updates every place it is used, which suits recurring roles like Secretary or Facilitator.
• A role that has drifted from its shared definition can be separated from the base role and gets its own copy, leaving the others untouched.
• The "Represents its parent role" option models Holacracy's Lead Link and Rep Link, a sociocracy delegate, or any representative you need.
• The vacant roles list shows in one click which roles nobody holds.
• Archiving keeps the history of the role and everything inside it, instead of deleting.
• A generator fills in purpose, domain and accountabilities from the role name and its parent's context, for you to review and correct before accepting.

When you create an organization you pick a governance model (classic, Holacracy v4 or v5, sociocracy) and the matching base roles arrive already written. The documentation explains each role option in detail. To set them up in the right order, follow the steps to implement Holacracy.

Frequently asked questions

How many accountabilities should a role have?

Between three and seven. Below three, the role is probably a fragment that would be better folded into a neighbouring role. Above seven, it covers a job and needs splitting. Treat those bounds as a signal to re-read rather than as a rule.

Can one person hold several roles?

Yes, and that is the normal way to work. A person commonly holds four or five roles spread across several teams. That is exactly what separates a role from a job description: a role can be reassigned without touching anyone's employment contract or job title.

Does every role need a domain?

The domain stays optional. It grants exclusive authority over an asset or a process, and many roles work perfectly well with a purpose and accountabilities. Add a domain when a decision stalls because nobody knows who calls it.

What is the difference between an accountability and a task?

An accountability is an ongoing activity with no end date: "Replying to every application within five working days". A task is a one-off action with a deadline: "Publish the developer job ad before Friday". An accountability generates tasks, while a task never turns into an accountability.

How often should roles be reviewed?

Review a role when someone feels a tension about it. A monthly governance meeting gives you the space to handle those tensions as they come. An annual review always arrives too late: between two reviews the team has already worked around the problem, so the org chart no longer describes the real work.

Are roles and functions the same?

A function and a role sit at two different levels. A function is a broad area of work, such as marketing, finance or support, and usually matches a department. A role is a precise slice of that work, with its own purpose and accountabilities, held by one person. A function therefore contains several roles, while one person often holds roles in more than one function: a developer can hold "Code Review" in engineering and "Technical Interviews" in recruiting. When people use "function" to mean a person's job, the useful comparison becomes a role versus a job description.

How do you define roles and responsibilities in a team?

List the recurring work the team already does, then group it into roles named after a responsibility rather than a profession. Give each role a purpose and three to seven accountabilities, assign it to one person in the meeting that creates it, and review it when someone raises a tension. To gather every role in one shared document, start from a roles and responsibilities template with one entry per role.

Where to start

Take one role, the one causing the most boundary trouble right now. Write its purpose in a sentence that settles a trade-off the name leaves open, list three to five accountabilities as -ing verbs, add a domain only if a specific decision is blocked. Have it reviewed by the person holding the role and by whoever complains about it most. Once you have the format, the next twenty-nine roles will go much faster.

To see why this format replaces a chart of positions, compare roles and job descriptions. Rolebase also connects roles to meetings and decisions.