How can I onboard someone into a role with many informal processes?
Quick answer
Build a short, editable orientation guide around the work the person needs to do: recurring tasks, where to find materials, who to ask, and examples of how decisions are usually handled. Label each item as a requirement, a common practice, or an open question. Verify details with the people involved, invite the new colleague to flag gaps, and set a date to review the guide so informal customs do not become misleading rules.
The question, the details, the next step.
Our role has lots of routines that nobody formally documented. How do I start without writing a huge handbook or making every habit sound mandatory?
Start with the situations the person will encounter in their first few weeks, not with an inventory of everything the team does. Make a one- or two-page orientation outline with links or locations for fuller materials. For each routine, explain when it comes up, what the new colleague needs to do, and who can answer questions.
Label the status plainly:
- Required: a step the person is expected to follow.
- Common practice: what people usually do, with room for judgment.
- Unconfirmed: something to check before relying on it.
Only call something required when an appropriate team owner confirms it. If you are unsure, write “common practice” or “confirm with [role/name]” rather than turning hearsay into a rule. Keep the guide editable and give it an owner and a review date.
What should go into the outline? I want it to help with actual work, not just list people and links.
Organize it around work moments. A useful outline might look like this:
Role orientation — [role/team]
- Purpose and first priorities: [what this role supports]; [initial focus to confirm with manager].
- Recurring work: [task], [when it tends to happen], [usual starting point], [who to ask if blocked].
- Finding things: [where current templates or working files are kept]; [how to identify the current version, if the team has a convention].
- Hand-offs: [what information is usually passed along], [recipient or role], [how timing is agreed].
- Decisions and exceptions: [what the role can decide], [who to consult when an unusual case comes up].
- People to meet: [role/name], [what they know], [best team-agreed way to reach them].
- Open questions: [uncertainty], [person to confirm with], [date to revisit].
Include a filled-in, illustrative example alongside the blanks. For instance: “When a weekly status update is due, the usual approach is to gather the current task notes, draft a brief update, and ask the receiving team lead to clarify any unclear hand-off. Confirm the timing and recipient with the team.” This shows how to describe a routine without claiming it is your team’s actual process or a mandatory rule.
How do I collect and check all these unwritten details without overwhelming teammates or the new hire?
Ask a few people who do or receive the work to walk through one recent, ordinary example. Use the same prompts: What triggered the task? Where did you start? What did you hand off? What tends to vary? Who should confirm an exception? Capture differences rather than forcing one account to represent everyone.
Then review the draft with the person responsible for the work and, where useful, the relevant manager. Ask them to mark each statement as confirmed requirement, common practice, or still uncertain. Avoid recording personal opinions as team-wide rules. Give the new hire the guide in small portions tied to upcoming work, and invite them to note missing terms, links, or decision points. They should not have to infer that an undocumented custom is compulsory.
Can you give me a simple way to maintain it so it stays useful after onboarding?
Add a lightweight maintenance section at the end: Owner: [role/name] | Last checked: [date] | Next review: [date] | Feedback route: [team-agreed channel or person]. After a task or hand-off, update the guide only when a detail has been confirmed; otherwise add it to open questions. When something changes, note the date and what changed rather than silently leaving conflicting instructions in circulation.
Use this final check before sharing: Can a new colleague find the next step for a likely task? Can they tell a requirement from a custom? Is there a person or role for exceptions? Are uncertain details visibly marked? If not, keep the gap explicit and assign someone to confirm it. The guide is a map to local knowledge, not a promise that every situation has a fixed procedure.
A practical checklist
Choose the first few work situations the new colleague is likely to face.
For each routine, record when it applies, a usual next step, and who can clarify it.
Label details as required, common practice, or unconfirmed; verify before calling anything mandatory.
Include an illustrative example and a clear route for questions or exceptions.
Name an owner and review date, and update only confirmed changes.
A few more useful answers
Should I document every informal process before the person starts?
No. Prioritize routines they are likely to encounter soon, then add details as work reveals useful gaps. Mark what is not yet confirmed instead of delaying the guide until it feels complete.
What if teammates describe the same routine differently?
Record the variation and ask whether it depends on context, individual preference, or an agreed requirement. Until clarified, avoid presenting one version as the universal rule.
How can I stop the guide from becoming a rigid rulebook?
Use status labels, describe the situation in which a routine is common, and keep exceptions visible. Review wording with the people who own the work, especially when a custom might be mistaken for a requirement.