How do I explain a team's working norms without overwhelming a new person?

Include a norm if a newcomer is likely to need it to complete an early task, coordinate with someone, or know what to do when something goes wrong. Keep the first handout focused on those situations—not every habit people have developed.

A useful test for each candidate norm is: “If a new person did not know this, could work stall, cause avoidable confusion, or leave someone waiting?” If not, it may be a preference or a detail to share later. Also distinguish requirements from suggestions. For example, “Add the project name to the task title” might be a team expectation, while “I find a short message easier to scan” is an individual preference. Don't present the latter as a rule unless the team has actually agreed to it.

Write each norm as an action someone can take, then add the reason or a small example. Replace “communicate proactively” with something observable, such as: “If your work is blocked, tell [team or contact] what you need and when you need it.” Replace “be respectful of calendars” with the team's actual scheduling practice, if one has been agreed.

Use language that tells the newcomer what to do without implying they should already know unwritten rules. Where a norm depends on a team decision, name the decision-maker or point to the place where that decision is recorded. If you are unsure whether something is agreed, leave it out or label it as a question to confirm rather than stating it as a requirement.

Here is a copyable outline. The details in brackets are placeholders; replace them with your team's actual agreements rather than assuming these examples apply.

How we work: a quick guide

1. Communication: For [type of update], use [team channel or tool]. Include [useful context]. For urgent matters, [agreed route].
2. Work and handoffs: Record [status, next step, or owner] in [shared location]. When handing something over, include [what is done, what remains, and any open question].
3. Questions and blockers: Ask [person, role, or channel]. If progress depends on someone else, say what input is needed and by when, if known.
4. Decisions and changes: Record [relevant decisions or changes] in [shared location]. Ask [decision-maker or team] when ownership is unclear.
5. Preferences and more detail: These are the team's current expectations. [Optional preference] is a preference, not a requirement. See [location for fuller guidance] for details.

Keep each section short enough to scan. If the full explanation needs exceptions, background, or several steps, summarize the immediate action here and link by document name or location. Check that the destination exists and is accessible to the newcomer before you rely on it.

Present it as a starting point for coordination, not a test. Say what the handout covers, where to find the fuller information, and whom to ask when an example does not fit. Make room for the newcomer to say which parts are unclear or missing; that feedback can reveal where the team is relying on unwritten assumptions.

For example: “This is a short guide to the habits that help us coordinate. You don't need to memorize it. Use it when you start a task, and ask [role or person] if a situation doesn't fit. The longer notes are in [location]. We'll clarify anything that's unclear.” Before sharing, check that every “must” reflects an agreed expectation and that the named contact and reference location are current.