How to Write a Role: Method, Examples and Pitfalls

A role describes work. A job description describes a contract, and ends up in a drawer. A role lives in the org chart, changes when the work changes, and one person usually holds four or five of them.

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 frame below rests on roles as they were actually written, 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. It repeats what the name already says 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 the day a decision stalls because nobody knows who calls it, and not before.

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.

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, and 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, and 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 job, a role named after a responsibility stays holdable. 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, and it gets assigned to nobody. Six months later it still sits in the org chart, still empty, and 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

The point is covered above, and it belongs here too 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, and a holder appointed by default 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

Election without candidates formalizes assignment when several people fit a role. For facilitation roles the circle elects, such as facilitator or secretary, see the governance meeting.

The definition then keeps moving. 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, never a scheduled annual review.

Where the RACI matrix fits

It clarifies who does what on a given deliverable, with four labels per row of a table. It works well on a project, and it complements role definitions rather than replacing them. A RACI describes a split at one point in time, dies with the project, and gets rebuilt from scratch on the next one. A role outlives both the projects and the people who hold it.

If you are starting from nothing and your roles do not exist yet, a RACI over two or three recent projects makes a good starting inventory: it exposes the decisions that always climb to the same person, and the ones nobody owns. Then convert the recurring rows into accountabilities.

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.

What concretely helps definitions survive:

• 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 role documentation covers every option, and the guide to implementing Holacracy gives the order to set them up in.

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, and the relationship only runs in that direction.

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, and the org chart stops describing the real work.

Where to start

Take one role, the one causing the most boundary trouble right now. Write its purpose in a sentence that does not copy its name, 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. You will have the format, and the next twenty-nine roles will go much faster.

For the wider picture, the article on roles versus job descriptions explains why this format replaces a chart of positions, and the features page shows how Rolebase connects roles to meetings and decisions.