Job descriptions, role charters, RACI: what's the difference?

Each does a specific job. None of them is a complete substitute for the others. The mistake most service businesses make is trying to use job descriptions as the design document, which they are not.

A job description is what you post on the careers page. It exists to attract candidates and screen them. The pattern is familiar: a paragraph about the company, a list of responsibilities ("manages estimating workflow, supports sales team, ensures quality of proposals"), a list of qualifications ("5+ years experience, attention to detail, proficient in [tools]"), salary range, application instructions.

Job descriptions are good at:

• Marketing the role externally. The right tone, the right keywords, the right level of detail for someone deciding whether to apply.
• Legal compliance. Equal opportunity language. Salary band disclosure where required. Essential functions for accommodation purposes.
• Screening criteria for HR or a recruiter. A document the recruiter can hand to a candidate.

Job descriptions are not good at:

• Describing what the role actually does once filled. The bullet list of "responsibilities" is usually vague enough that two different operators in the same role would interpret it differently.
• Defining decision authority. "Manages estimating workflow" doesn't say whether the role can approve a quote, who they escalate to, or what magnitude of pricing decision is theirs to make.
• Describing how the role interacts with others. A job description is a stand-alone document about one role. The most important thing about a role is usually how it connects to other roles.
• Designing the business. A folder of 30 job descriptions doesn't add up to an operating system. It adds up to a recruiting library.

You need job descriptions. They're a real artefact, useful in their specific context. They are not the design layer.

RACI stands for Responsible, Accountable, Consulted, Informed. It's a matrix that, for a specific process, lists the steps down one axis and the roles across the other, with each cell marked R, A, C, I, or blank. The point is to make decision rights and accountability explicit, especially when multiple roles touch the same flow.

A RACI for a quoting process might look like:

RACI is genuinely useful where it applies. When you have a multi-stakeholder process and ambiguity about who decides what, a RACI in 30 minutes will surface the gaps. Two people thinking they're both Accountable. Three people thinking they're Responsible. Half the steps with nobody marked anywhere.

What RACI doesn't do: tell you what any one role is for in the business. RACI is process-centric. It describes who touches a particular process at which step. To describe what the Senior Estimator role is, you'd need to read the RACI for the quoting process, then the RACI for the proposal review process, then the RACI for the vendor management process, and piece together the role from the union of all those RACIs. That's possible but it's the wrong direction. The role should describe itself coherently in one document. The RACIs should be downstream views, not the source of truth.

Use RACIs where they earn their keep: for a handful of critical cross-functional processes where decision rights are genuinely contested. Don't use RACIs as the design system for the business as a whole. They're not built for that.

A role charter is what's missing from most service-business documentation. Once you have an honest role charter for each box in your role-based org chart, the business is genuinely designed. Until then, it's staffed but not designed.

A role charter answers six questions in writing:

Two to three pages per role. Reviewed annually. Owned by the person currently in the role plus their manager. The charter becomes the single source of truth for what that role exists to do.

Four reasons.

1. They survive the person. The charter describes the role, not the current occupant. When the role changes hands, the charter persists. The successor inherits a defined position, not a custom-shaped job inherited from the previous holder.

2. They unlock honest performance conversations. "How are you doing against your charter?" is a different conversation from "How are you doing as a person?" The charter is the anchor. Performance review with a charter is structured; without one it's a vibe.

3. They make the business legible to outsiders. A diligence team reading your charters in 30 minutes understands the business's design. A diligence team reading 30 job descriptions and a couple of RACIs is going to ask a lot more questions and trust the answers less. (We covered this lens in The Five Operational Gaps That Cap Exit Value.)

4. They become the spine of your Playbook. Each role charter points to the procedures, decisions, and documentation specific to that role. The Playbook's navigation is organised by role; the charters are the entry points. Without charters, the Playbook becomes a flat document library nobody can find their way through.

A working sequence.

1. Settle the org chart first. Role charters that get written before the org chart is locked have to be rewritten when the structure shifts. Lock the structure. (See the org chart article.)
2. Start with leadership roles. Owner, COO, function heads. These charters are the most strategically important and the most likely to surface design issues. Errors here cascade. Errors at the IC level usually don't.
3. Write each charter twice. First draft: what the role SHOULD be. Second pass: what the role IS today, with deltas flagged. The deltas are the change-management work for the next 6 to 12 months.
4. Validate with the current role-holder. Their lived experience surfaces edge cases the abstract design misses. They also need to agree with the charter or it won't be used.
5. Then propagate down. Direct reports of each leadership role next. Then their reports. Don't try to write all 30 charters in one quarter; the leadership team can't absorb that pace and the quality drops.
6. Review annually. One review cycle per role per year, ideally tied to the performance review. Without the cycle the charters drift out of date and become decorative.

The single most common failure mode.

You sit down to write the Senior Estimator charter. The current Senior Estimator is Sarah, who is excellent at her job and has been there fourteen years. The instinct is to write the charter around what Sarah actually does. Within an hour you have a document that reads as a slightly formalised version of Sarah's resume.

The problem: Sarah's job is custom-shaped to Sarah. It includes vendor relationships she has personally because she's been there fourteen years. It includes pricing intuition she developed across thousands of jobs. It includes mentorship she provides to junior estimators that's based on her personality. None of this is wrong. All of it is unrepeatable.

If you write the charter around Sarah, the charter describes a role that no realistic future hire could fill. The succession problem stays unsolved. The next person who sits in the Senior Estimator chair inherits a charter they can't meet, gets reviewed against it, comes up short, and either leaves or quietly redefines the job.

The fix: write the charter for the role, then ask "what would Sarah's specific contributions look like as enhancements to the role, not as definitions of it?" Some of Sarah's extras become things the next person grows into. Some of them get explicitly documented as Sarah's personal contribution that we don't expect to replicate. Some of them get distributed across other roles before Sarah ever leaves. None of them get embedded into the charter as if they were the baseline.

This is hard. It requires looking at your best people and intentionally not writing the design around them. Founders find it especially uncomfortable for the roles their own contribution sits in. The Owner charter is the hardest one to write honestly, for exactly this reason.

If you have to choose one document to invest in, choose the role charter.

Job descriptions are a downstream artefact: once you have a charter, the job posting writes itself in 20 minutes. RACIs are a complementary artefact: they describe how roles cooperate on specific processes, but they're a view of the design, not the design itself. The role charter is the design itself. It's the document that, if missing, leaves the whole structure soft.

If you've followed this series through, the picture compounds. The role-based org chart establishes the shape. The role charters describe what each box does. The Playbook holds the operational knowledge organised around those charters. The dashboard surfaces whether each role is producing its outcomes. The whole thing is a designed operating system. The team works inside it. The business doesn't depend on any one person staying.

This is the work, in 12 articles, and it's the work of Codified Operational Intelligence™. The role charter is one specific piece, but it's the piece that turns the org chart from a poster into a working design.