Roles and Responsibilities: Examples, Template, and How to Define Them
Roles and responsibilities define the contribution a role is expected to make and the work it must own. A role describes the seat in the team; its responsibilities describe the recurring outcomes, decisions, and duties attached to that seat. Write both before assigning names, then confirm decision boundaries, handoffs, and a review date. The copyable role card and fictional example below turn that definition into a working agreement.
On this page
- What roles and responsibilities mean
- Role vs. responsibility
- Copyable role card template
- How to define roles and responsibilities
- Fictional eight-role team example
- Roles vs. RACI vs. org chart
- Review checklist
What roles and responsibilities mean
A role is a stable bundle of expected contributions within a team. It can be a job, a project role, or a temporary duty. A responsibility is an outcome, recurring duty, or decision that the role is expected to own. The distinction matters because a person may hold several roles, while the same role can pass from one person to another without being rewritten from scratch.
The U.S. Office of Personnel Management describes a position description as the official record of the major duties and responsibilities assigned to a position. That is a useful discipline outside government too: write the work, authority, and relationships of the seat, then record the current assignee separately. Do not reduce a role to a list of disconnected tasks. A useful definition answers four questions:
- What outcome exists because this role exists?
- Which recurring work does it own?
- Which decisions can it make without escalation?
- Which roles provide inputs or receive outputs?
Role vs. responsibility
The role is the noun; the responsibility is the outcome-oriented sentence. “Content lead” is a role. “Approves the editorial brief before production starts” is a responsibility. A task such as “send Tuesday email” may support that responsibility, but it is too narrow and time-bound to define the role.
| Item | What it answers | Good example | Weak example |
|---|---|---|---|
| Role purpose | Why does this seat exist? | Turn qualified customer problems into a validated product direction | Help with product |
| Responsibility | What result or recurring duty does it own? | Maintains the prioritized discovery backlog | Attends meetings |
| Decision authority | What can it decide? | Approves research scope up to 20 participant hours | Makes product decisions |
| Task | What action happens now? | Draft interview guide for sprint 14 | Manage research |
| Metric | How is the result checked? | Findings reviewed within five business days | Do a good job |
A responsibility should start with an active verb and name an observable output or standard. Use “maintains,” “approves,” “publishes,” or “verifies,” not “supports” unless the support itself is defined. Avoid personality traits, inflated seniority, and verbs that make several roles appear to own the same final decision.
Copyable role card template
Copy one card per role. Complete it with the people who perform, depend on, and approve the work. The role owner drafts; adjacent roles challenge the handoffs; the team lead resolves overlap.
| Field | Copyable prompt | Example |
|---|---|---|
| Role ID | Stable identifier | PROD-02 |
| Role title | Name of the seat | Product Research Lead |
| Purpose | This role exists to… | Turn customer evidence into testable product decisions |
| Key outcomes | Three to five results | Evidence repository is current; study findings are reviewed |
| Recurring responsibilities | Verb + object + standard | Publishes a findings brief within five business days |
| Decision authority | May decide… up to… | Selects study method within the approved research budget |
| Must escalate | Decision boundary | Any collection of sensitive personal data |
| Inputs | Role + artifact | Product Manager — research question |
| Outputs | Role + artifact | Design Lead — prioritized findings |
| Backup | Role, not person | UX Researcher |
| Assignee | Current person | Jordan Lee (fictional) |
| Verified | Date + reviewer role | 2026-08-28 — Product Director |
This is a roles and responsibilities template, not an employment contract or a substitute for legal, compensation, or HR review. Keep confidential performance information outside the shared card. If the team needs reporting lines, use an org chart template; if it needs task-by-task assignment, use a RACI chart.
How to define roles and responsibilities
1. Start with the team outcome
Write the customer or operational outcome the team owns. A list of job titles without a shared outcome encourages local optimization. In the fictional launch team below, the outcome is “release a reliable self-serve onboarding flow and verify adoption within 30 days.”
2. Inventory recurring work and decisions
Collect deliverables, approvals, operating duties, and risk controls. Group them by the result they protect. Separate routine tasks from responsibilities: “update dashboard every Monday” is a task beneath “maintains the agreed adoption metrics.”
3. Draft roles before assigning people
Name each seat and its purpose. This exposes missing ownership without allowing seniority or habit to settle every question. One person may hold two small roles, but write two cards so the team can split them later.
4. Give each responsibility one primary owner
Several roles may contribute, but one role owns the continuing result. “Shared responsibility” often means no one knows who must notice drift. Shared execution is fine; unbounded shared ownership is not.
5. Define authority and escalation together
An obligation without authority is a trap. State what the role may approve, the threshold at which it must escalate, who decides above that threshold, and the expected response time.
6. Test every handoff with an artifact
“Works closely with design” is not a handoff. “Provides a prioritized, evidence-linked problem brief to the Design Lead before concept review” is. Name the sender, receiver, artifact, condition, and timing.
7. Review the draft against real scenarios
Walk through a late launch, a quality defect, a privacy concern, and an absent owner. If two people both believe they decide—or everyone believes someone else does—the card is unfinished.
Fictional eight-role team example
The following example is entirely fictional. “Northstar Labs” is preparing a self-serve onboarding release. The team has eight roles; each owns a different continuing result.
| Role | Purpose | Primary responsibilities | Decision boundary | Main handoff |
|---|---|---|---|---|
| Product Sponsor | Protect business outcome and funding | Confirms outcome; resolves scope exception | Approves changes above 10% budget | Signed outcome brief to Product Manager |
| Product Manager | Maintain validated direction | Prioritizes problems; accepts release scope | Cannot waive security or accessibility gates | Prioritized brief to Design and Engineering |
| Research Lead | Maintain credible customer evidence | Plans studies; verifies findings | Escalates sensitive-data collection | Findings brief to Product Manager |
| Design Lead | Make the journey usable and testable | Owns interaction model; records design decisions | Cannot approve inaccessible exceptions | Reviewed specification to Engineering Lead |
| Engineering Lead | Deliver an operable implementation | Owns technical plan; reviews production readiness | Escalates architectural risk and extra capacity | Release candidate to Quality Lead |
| Quality Lead | Protect release criteria | Defines test evidence; reports unresolved defects | Does not set product scope | Gate report to Product Manager and Sponsor |
| Go-to-Market Lead | Prepare accurate launch communication | Coordinates message, enablement, and channel plan | Cannot promise unapproved features | Approved launch brief to Support Lead |
| Support Lead | Prepare customer response and feedback | Builds support guidance; classifies early feedback | Escalates safety, privacy, and outage issues | Triage report to Product and Engineering |
Now test one scenario. Two days before launch, quality finds a keyboard-navigation defect. The Quality Lead owns the evidence and reports the failed criterion; the Design Lead specifies the accessible behavior; the Engineering Lead owns the fix plan; the Product Manager decides whether the release scope can change; the Sponsor becomes the decision-maker only if the change exceeds the agreed budget or business boundary. No role card tries to make one person own all five actions.
Roles vs. RACI vs. org chart
| Artifact | Primary question | Unit | Use it when |
|---|---|---|---|
| Role card | What does this seat own and decide? | One role | Defining durable expectations |
| RACI matrix | Who executes, approves, is consulted, and is informed for this deliverable? | Deliverable × role | Coordinating bounded project work |
| Org chart | Who reports to whom? | Position and reporting line | Showing formal structure |
| Stakeholder map | Whose interest and influence affect the work? | Stakeholder or group | Planning communication and engagement |
These artifacts connect but do not replace one another. Role cards supply stable role definitions. A RACI matrix assigns those roles across project deliverables. An org chart supplies reporting context. A stakeholder map includes people outside the delivery team. For repeatable operational steps after ownership is clear, document the sequence in an SOP.
Review checklist
- Every role has a one-sentence purpose linked to the team outcome.
- Every continuing result has one primary owner.
- Responsibilities begin with active verbs and name observable outputs.
- Decision authority includes a boundary and an escalation destination.
- Handoffs identify sender, receiver, artifact, and timing.
- Backup coverage is defined for critical responsibilities.
- Reporting lines live in the org chart, not inside every responsibility.
- Project assignments live in RACI, not in permanent role cards.
- Assignee and role are separate fields.
- A verified date and next review trigger are recorded.
Review by trigger: a changed team outcome, a hire or departure, a repeated handoff failure, a new compliance obligation, or a project retrospective that exposes ambiguity. Add a quarterly check for critical roles even when nothing appears to have changed. Archive the prior version so a changed responsibility is visible rather than silently overwritten.
Documenting role agreements in AFFiNE
AFFiNE can hold the role table in a page and place a visual working copy on an Edgeless canvas for manual review. Link each role to supporting decisions, SOPs, or project pages, and record the verification date beside the assignee. Use comments or a review meeting to resolve overlap before publishing the agreed version.
Keep the claim narrow: AFFiNE does not automatically infer roles, generate a correct RACI matrix, approve decision rights, synchronize an HR system, or maintain reporting lines for you. It does not promise a downloadable Word, Excel, PowerPoint, or Visio role template from this article. The team remains responsible for accuracy, access control, approval, and maintenance.
Sources and editorial method
This guide uses role and position guidance for the definition boundary, W3C guidance for accessible diagrams, and official project-method material for the distinction between role definitions and assignment matrices. The team example, names, thresholds, and records are fictional teaching data. Accessed August 30, 2026.
- U.S. Office of Personnel Management, Introduction to the Position Classification Standards — duties, responsibilities, and position descriptions.
- European Commission, PM² Project Management Methodology Guide — project roles and the responsibility assignment approach.
- W3C Web Accessibility Initiative, Complex Images — text alternatives for diagrams and complex images.
- W3C, WCAG 2.2 — accessibility requirements including non-text content and use of color.
Frequently asked questions
What are roles and responsibilities?
A role is a stable seat or contribution expected within a team. Responsibilities are the recurring outcomes, duties, and decisions attached to that role. Define the role independently from the current assignee so ownership survives staffing changes.
What are examples of roles and responsibilities?
For a Product Manager role, responsibilities might include maintaining a prioritized problem backlog, accepting release scope within an agreed boundary, and giving Design and Engineering an evidence-linked brief. “Attend stand-up” is a task, not a defining responsibility.
How do you write roles and responsibilities?
Start with the team outcome, inventory recurring work and decisions, create role purposes, give each result one primary owner, define authority and escalation, name handoff artifacts, and test the draft against real scenarios. Record the assignee and review date separately.
What is the difference between a role and a responsibility?
The role names the seat; a responsibility states an outcome or recurring duty owned by that seat. “Quality Lead” is a role. “Defines release evidence and reports unresolved defects” is a responsibility.
