How do I introduce a new team member to a project already in progress?

Start with a brief project-entry note, not a replay of every meeting or a pile of links. Give them enough context to understand the work and find a useful place to start:

1. Purpose: What is the project trying to achieve, and for whom?
2. Current state: What is complete, underway, and still waiting to happen?
3. Key decisions: What choices have shaped the work, and what was the reason, if known?
4. Open questions: What is unresolved, uncertain, or dependent on someone else?
5. Point of entry: What is one manageable next contribution, and what should they review or ask before starting?

Keep the first note focused on helping them get oriented. If a detail is unknown or still being decided, say so rather than presenting an assumption as settled.

Separate what you can confirm from what you are piecing together. For each important decision, write the choice, its reason if recorded, and whether it is still in effect. For example: “The team chose [option] because [recorded reason]. Status: [confirmed / being revisited].” If you do not know the reason, write “Reason not recorded” and identify who might clarify it. Don’t turn a guess into project history.

For current state, describe observable work rather than broad impressions. “Draft is complete; review is pending from [role or team]” is more useful than “We’re nearly done.” If relevant, include the next checkpoint using a date placeholder such as [date], and name dependencies or open questions without implying they are resolved.

You can point to existing materials by their names or locations, but don’t make the new person infer the whole story from a long link list. Say what each item is for, such as “Use [document name] for the latest agreed scope.”

Choose a bounded contribution that helps the person learn the project while giving them a clear way to ask for context. Avoid assigning a task that depends on unstated decisions or access they may not yet have. Explain the intended result, what to look at first, who can answer questions, and how or when to check back.

For instance, assuming the project needs a review of existing materials, you might invite them to read [named materials] and list questions about [specific topic] before taking on a larger piece of work. That is an illustrative option, not a recommendation about every project. If a task’s scope or decision owner is unclear, mark that as something to clarify together before they proceed.

Use this template and replace each bracketed prompt with confirmed information. Keep it short enough to scan; add detail only where it helps the new colleague understand the work or take their first step.

Project: [name]

Purpose: We are working toward [intended outcome] for [audience or need].

Current state: Completed: [work]. In progress: [work and owner, if useful]. Waiting on: [dependency or response, if any]. Next checkpoint: [date or event, if known].

Key decisions: [Decision] — [reason, if recorded] — Status: [still in effect / being revisited]. Unknown or unrecorded reasons: [state plainly].

Open questions or constraints: [what is unresolved, who may clarify it, or what is not yet known].

A useful first point of entry: Please [bounded first contribution]. Start with [named material or context]. Check with [role or person placeholder] about [specific question]. We can review [your notes or first output] at [time or checkpoint].

Where to find more context: [material name] — [what it contains]; [material name] — [what it contains].

Before sharing, check that the status and decisions are current, the first step is clear, and uncertain details are labeled. Then ask the new colleague what context is missing; their questions can show where the briefing needs clarification.