Position Description or Office Mandate¶

Role-defining document — instantiates Role Expectation Architecture

The founding document that establishes a position exists, states what its holder is responsible for and owes to others, and makes the role recognizable independent of whoever currently fills it.

A Position Description or Office Mandate is the authoritative, standing statement of what a role is — its purpose, the responsibilities its holder carries, and what other parties may rely on it to deliver. Its defining move is to describe the office, not the officer: the document is written to outlast any individual, so a colleague, a candidate, or a successor can tell what the role is for before anyone particular occupies it. This is what separates it from every other artifact in the archetype — a delegation letter grants a person authority, a role card is an at-a-glance summary, a RACI maps interfaces — whereas this is the single source of truth that says the position exists and defines the core of what it does. ("Position description" is the HR/job form of the artifact; "office mandate" is its public-sector or governance form.)

Example¶

A public library system decides its outreach is failing under-served neighbourhoods and creates a new Community Engagement Librarian post. Before hiring, the branch director drafts the office mandate. Purpose: extend programming into neighbourhoods the branches currently miss. Core responsibilities: design and run a monthly slate of community programs, build standing relationships with local organizations, and represent the library at neighbourhood forums. What the role owes others: a published quarterly programming calendar the branch managers can plan staffing around, and a single point of contact the partner organizations can reach.

The mandate is finished and posted before a candidate is chosen. That ordering is the point: applicants can now judge whether the role fits them, branch managers know exactly what deliverable they can build on, and partner organizations know who owns the relationship — none of which depended on who eventually got the job.

How it works¶

Anchor the position. Name the office and state its reason to exist, as something the organization needs rather than a description of a favoured person.
Bundle the expected behaviours. Enumerate the core responsibilities the holder is expected to carry — the recurring work that defines the seat.
Scope the service owed. State what downstream parties may rely on the role to produce, so obligations are explicit rather than assumed.
Write it to transfer. Keep it person-independent, so the same document briefs a candidate, orients an incumbent, and hands cleanly to a successor.

Tuning parameters¶

Specification grain — a broad remit versus an enumerated duty list. Broad stays adaptable but blurs edges; enumerated is clear but rigid and invites "not in my description."
Standing vs. staffing — described generically for the office or tailored to the current incumbent. Generic transfers cleanly; tailored fits the person but breaks at handoff.
Activity vs. outcome framing — listing what the holder does versus the results they owe. Outcomes travel better across changing context; activities are easier to check.
Service breadth — how many downstream parties the role explicitly owes something. Wider closes coordination gaps but raises overload risk.
Revision cadence — a living document revisited on a schedule, or a fixed charter changed rarely. Living tracks reality; fixed is stable but drifts into fiction.

When it helps, and when it misleads¶

Its strength is that it dissolves role ambiguity — the strain and dropped work that come when people cannot tell what a position is for or what they may expect from it — and gives every other role artifact a common reference to derive from.^[1]

Its failure modes are quiet. A description left un-revised goes stale and becomes organizational fiction that nobody actually follows; over-enumeration hardens into a shield ("not my job") that defeats the coordination it was meant to serve. The classic misuse is to write it after a hiring decision, reverse-engineered to justify a favoured candidate, so the document ratifies a person rather than defining an office. The discipline that guards against this is to keep it the acknowledged source of truth — drafted before appointment, revisited at review, and re-synced whenever the derived artifacts (role card, RACI, delegation) change.

How it implements the components¶

This artifact fills the definitional slice of the archetype — what the position is and owes — and hands the rest to other mechanisms:

role_position_anchor — names the office and its reason to exist, establishing that the position stands independent of any holder.
expected_behavior_bundle — enumerates the core responsibilities the holder is expected to perform.
obligation_and_service_scope — states what the role owes downstream parties: the deliverables others may rely on.

It defines what the position is, but not the authority that comes with it (that is the Role Charter and Delegation Letter or Authority Envelope), who is eligible to hold it (Role Compatibility Check), or how it interfaces with neighbouring roles (RACI or Decision Participation Matrix).

Instantiates: Role Expectation Architecture — it supplies the person-independent definition every other role artifact points back to.
Sibling mechanisms: Role Charter · Role Card or Participation Card · Delegation Letter or Authority Envelope · RACI or Decision Participation Matrix · Onboarding and Role Shadowing Runbook · Swimlane or Service Blueprint

Notes¶

This document is meant to be the source that lighter artifacts derive from — the role card, the RACI row, the delegation letter all restate a slice of it. That makes drift the standing risk: when the mandate is updated but the derivatives are not (or vice versa), the organization ends up with several disagreeing descriptions of the same role. Treat it as the canonical copy and re-sync the derivatives on the same change, or the single source of truth quietly becomes several.

References¶

[1] Role ambiguity — the well-documented condition in organizational role theory where a position's expectations are unclear to its holder or to those around it, associated with strain, conflict, and dropped or duplicated work. A clear position description is the standard first-line remedy, which is why the definitional components lead here. ↩