What belongs in a role-specific onboarding guide for a recurring position?
Quick answer
A role-specific onboarding guide should capture the information every person in the position needs: its purpose, responsibilities, recurring work, tools, decision boundaries, key relationships, and where to find current references. Put team-specific differences in clearly labeled add-ons. Focus on how the role works rather than a week-by-week schedule, and assign someone to maintain the guide.
The question, the details, the next step.
What should go into the guide itself, rather than being left to a manager to explain?
Document information that is stable, reusable, and important for doing the role. A practical outline is:
- Role at a glance: purpose, main responsibilities, and how the work contributes to the team. Distinguish the role from neighboring positions.
- How work flows: recurring tasks, typical inputs and outputs, handoffs, and what counts as ready for review or complete.
- Tools and information: relevant systems, what they are used for, and where to find instructions or request access. Point to maintained references for details that change often.
- Decisions and escalation: what the role can decide, when to consult or seek approval, and whom to contact when blocked.
- People and partnerships: the roles or teams the position works with, why, and how they coordinate.
- Ways of working: role-specific recurring meetings or communication conventions.
- Reference material: definitions, examples, templates, and pointers to current procedures.
Managers can use conversations for judgment, context, and individual goals. The guide should make routine expectations findable without scripting every situation.
How do I make it specific to the role without writing a separate guide for every team?
Use a shared core plus clearly labeled variations. The core covers what is consistent across people in the position. Add short sections for differences that affect the work, such as a team’s customer group, approval path, tools, or recurring deliverables. Label each variation with its scope, such as “For [team or location].”
For example, a shared guide for a project coordinator might say: “Track agreed actions, owners, and due dates in [project workspace]; raise unresolved dependencies with [role].” A team add-on might say: “For [team], also prepare [recurring handoff] using [template location].” These placeholders need to be filled with locally confirmed details.
Avoid copying the whole core into each add-on. Keep temporary or individual differences in a manager conversation or personal work plan. If a difference becomes a normal part of the role, update the core or make the variation explicit.
How should I explain recurring work and decision boundaries so the guide is usable?
Describe recurring work in a repeatable pattern: trigger or input → action → output → handoff or decision. Give a short example or link to a template, and say who receives the result.
For decision boundaries, state the ordinary case, when to consult someone, and whom to contact. For instance: “You may update [routine record] when [condition]. Check with [role] before changing [shared commitment]. If [exception] occurs, bring the relevant details to [role].” Replace the brackets with confirmed local information.
Don’t invent approval rules or suggest an example covers every exception. If the team has not agreed on a boundary, mark it as a question to resolve before publishing. Point to current procedures rather than creating a second, potentially conflicting copy.
Can you give me a reusable outline that stays manageable and easy to maintain?
Use this copyable structure; keep each section as short as its purpose allows:
[Role name] onboarding guide
- Purpose: This role exists to [contribution]. Main responsibilities: [responsibilities].
- Recurring work: [Task or output] — input: [ ]; reference or steps: [ ]; recipient or handoff: [ ].
- Tools and access: [Tool] is used for [purpose]. Instructions or access: [location or contact].
- Decisions and escalation: Decide [ordinary decisions]. Consult [role] about [boundary]. For [exception], contact [role] with [useful context].
- Key relationships: Work with [role/team] to [reason]; coordination method: [method or reference].
- Team-specific notes: [Scope] — [difference and where to find details].
- Reference shelf: [templates, glossary, current procedures].
- Guide owner and review trigger: [role or name]; revisit when [role, process, or tool changes].
Before sharing, ask someone familiar with the position to check that responsibilities, handoffs, and boundaries reflect current practice. Ask someone unfamiliar with the role to find a particular answer using the guide. Fix confusing headings or missing pointers, and resolve uncertain expectations before presenting them as settled.
A practical checklist
State the role’s purpose and distinguish its responsibilities from adjacent roles.
Describe recurring work with its inputs, outputs, and handoffs.
Name relevant tools and point to current access instructions or references.
Clarify ordinary decisions, consultation points, and escalation contacts.
Label team-specific variations without duplicating the shared core.
Assign a guide owner and a practical trigger for review.
A few more useful answers
Should the guide include a first-week or first-month schedule?
Not if the goal is a reusable description of the role. Keep scheduling in a separate onboarding plan so the guide can focus on responsibilities and working practices.
What if a process changes frequently?
Explain what the role needs to know, then point to the maintained source rather than copying changeable steps. If the pointer is unclear or the source is unavailable, flag that gap for the guide owner.
Who should review the guide before it is reused?
Ask someone responsible for the role’s current work to check the details, and someone unfamiliar with the role to check whether the structure is understandable. Resolve uncertain expectations before presenting them as settled.