Skip to content

Role Card or Participation Card

Reference artifact — instantiates Role Expectation Architecture

A single-role, at-a-glance card — this position, the few things you do, the near ones you don't, and whom you serve — small enough to hand someone the moment they step into the seat.

A Role Card (or participation card) is the pocket-sized, one-role reference: it names the position, lists the handful of behaviours that define it, marks the adjacent things the holder must not do, and states whom the role serves — all compressed onto a single visible surface. Its defining idea is radical compression for publication. Where a charter or position description is the exhaustive source of truth, the card is the piece you can actually hold, hand out, pin up, and read in ten seconds. It deliberately trades completeness for glanceability, and it covers exactly one role — not a grid of many.

Example

A weekend community festival runs on 300 volunteers, most of whom show up once and have never done it before. A binder of job descriptions is useless at 7 a.m. in a muddy field, so each role gets a lanyard card instead. The Zone Lead card says, in six lines: keep your zone's stalls supplied and safe; be the person a vendor or guest flags when something is wrong; you may authorize a break-relief swap and a minor layout change; you do not handle cash, medical calls, or press — radio Channel 2 for those; you report to the Site Duty Manager. A brand-new Zone Lead reads it in the time it takes to clip it on. The card does not make anyone an expert — it makes the boundary legible in the moment: what is mine, what is explicitly not mine, and whom to call for the rest. The pattern echoes the position-specific job aids of the Incident Command System, where a card per role lets strangers slot into a command structure fast.[1]

How it works

Compression is the method. The card selects the three-to-seven behaviours that most define the role, plus the two or three adjacent actions the holder will be tempted toward but must not take, and prints both alongside a single "whom I serve / whom I call" line. The don't-list carries as much weight as the do-list: the card earns its keep by drawing the boundary against neighbouring roles, not by describing the whole job. And it is built to be published — worn, posted, pinned — rather than filed, so its form follows the moment it will be read in.

Tuning parameters

  • Do-list length — how many behaviours make the cut; too few and the card is vague, too many and it stops being a card.
  • Prominence of the don't-list — how much space goes to explicit non-responsibilities and neighbour boundaries; raise it wherever role bleed between adjacent positions is the main risk.
  • Standalone versus distilled — whether the card is authored fresh or is a strict digest of a fuller charter it must stay synced to.
  • Physical form — lanyard card, wiki box, pinned message, printed placard; match it to where the role is actually performed, in the field or at a desk.
  • Audience face — a card written for the holder (what to do) versus one written for others (what they may expect of this role); the two emphasize different sides of the same boundary.

When it helps, and when it misleads

Its strength is placing the role's boundary exactly where and when it is needed — in the hand, at the moment of acting — and its brevity is what gets it actually read; it is the fastest way to make a role recognizable both to a newcomer and to everyone working around them. Its failure modes follow from the same compression: a card mistaken for the complete definition invites confident errors on everything it omitted, and cards drift silently from the fuller charter unless one is the acknowledged source. Its classic misuse is treating the card as authority it does not carry — reading "may authorize X" as a grant when the real permission lives in another instrument entirely. The discipline that guards against this: mark the card explicitly as a summary of a canonical source, keep the don't-list honest, and re-issue it when the role changes rather than letting a stale card quietly mislead.

How it implements the components

The card fills the identity-and-publication slice — who the role is and where its boundary is shown — not how decisions route or how the seat changes hands:

  • role_position_anchor — the card names and fixes the single recurring position it stands for.
  • expected_behavior_bundle — its do-list, and its pointed don't-list, is the compressed bundle of behaviours that constitute the role.
  • role_boundary_publication_surface — the card is the surface: a portable, postable artifact that makes the boundary public and glanceable.

It does not assign who is Accountable across decisions (authority_and_permission_scope, accountability_and_review_path) — that is the RACI or Decision Participation Matrix; it does not plan how the seat is covered or handed on (handoff_substitution_and_succession_path) — that is the Role Rotation or Deputy Schedule; and it is the digest of, not a replacement for, the fuller Role Charter or Position Description.

  • Instantiates: Role Expectation Architecture — the card is the archetype's most compressed and most public expression of a single role.
  • Consumes: Role Charter — the card is the pocket distillation of the charter's fuller contents.
  • Sibling mechanisms: RACI or Decision Participation Matrix · Role Rotation or Deputy Schedule · Role Charter · Position Description or Office Mandate · Swimlane or Service Blueprint · Role Review Retrospective · Handoff Checklist · Onboarding and Role Shadowing Runbook · Delegation Letter or Authority Envelope · Conflict-of-Interest Disclosure · Role Compatibility Check

Notes

A card is a view, not a source. Because it looks authoritative — printed, worn, official — a stale or free-standing card is dangerous in a way a stale binder is not: people act on it immediately without checking. Keep every card pointed at the canonical role definition it summarizes, and treat re-issuing the card as part of changing the role, not an afterthought.

References

[1] The Incident Command System (ICS) used in emergency response issues position-specific job aids — compact, often laminated cards — so responders who have never worked together can occupy a defined role at once. They are a real, widely used instance of the role-card pattern. ↩