Short answer
Use job shadowing to observe a defined work task with agreement from the host and participant. Set access, note-taking, confidentiality, and stop boundaries before the session. Record facts and exceptions in a simple grid, then debrief separately from assessment. Finish with a bounded decision to adopt, test, adapt, document, escalate, or discard what was observed.
Job shadowing is a structured, time-bounded observation of someone completing a defined part of their work. Its purpose is to understand current work in context, not to rate the host, inspect an individual, or declare one method universally better.
The U.S. Office of Personnel Management includes shadowing assignments among development activities. Its career-development guidance also distinguishes an individual development plan from performance evaluation, a useful boundary for developmental observation. Source: OPM Career Development
Adapt this checklist to your organisation's access rules, safety procedures, confidentiality expectations, and local policies.
Define the boundary before scheduling
Job shadowing differs from:
- An interview: an interview asks for explanations or opinions. Shadowing observes a defined task as it happens.
- Onboarding: onboarding may include observation, but has the wider purpose of helping someone enter a role or organisation.
- Performance assessment: do not score the host, compare people, or create disciplinary evidence from the session.
- Unplanned observation: a planned session states its purpose, limits, note rules, and conditions for stopping.
The Field Notes Framework
Use this original six-question check before arranging a session:
- Work question: What does the team need to understand?
- Participant: Who needs to observe, and why?
- Observable task: What task, handoff, or decision can be watched?
- Expected output: What should exist afterwards, such as a question for the process owner or an idea to test?
- Alternative: Could an interview, walkthrough, document review, or non-live demonstration answer the question with less exposure?
- Reason not to shadow: Would privacy, restricted access, safety, operational pressure, or discomfort require a different method?
If observation would require unnecessary access to sensitive information, redesign the session or choose a lower-exposure alternative.
Pre-session planning worksheet
Complete this before invitations are sent.
| Planning item | Record before the session |
|---|---|
| Objective | One question about work, not a judgement about a person. |
| Task and scope | The task, its start and end point, and what is excluded. |
| Roles | Coordinator, host, participant, process owner, and any required approver. |
| Timing and location | Date, duration, setting, and whether a quieter follow-up is needed. |
| Access and exposure | Systems, locations, meetings, or customer interactions that may be visible. |
| Agreement and note rules | What people agree may be observed, discussed, recorded, and stored. |
| Safety and accessibility | Relevant precautions, equipment, mobility, sensory, language, or scheduling needs. |
| Stop rules | Conditions requiring a pause, exit, redaction, or end to the session. |
Keep the objective narrow. “Understand how returns are checked before a refund decision” is more useful than “learn how the best team works.”
Role-based confirmation checklists
Coordinator
- Confirm the work question, duration, location, and expected output.
- Check that the host can permit the agreed observation.
- Explain the developmental purpose, access boundary, note rules, and stop rules.
- Arrange a short debrief while the session is still recent.
Host
- Confirm the task to be shown and steps that cannot be observed.
- Flag information or situations that should not be recorded.
- Name normal variations, time pressure, and known exceptions.
- Pause if the work becomes sensitive, unsafe, or outside the agreed scope.
Participant
- Read the purpose, note rules, and stop rules before arrival.
- Avoid interrupting customers, colleagues, or safety-critical work.
- Write what happened before writing what it might mean.
- Bring assumptions and unresolved questions to the debrief.
Use an observation grid
Record only details needed to answer the work question.
| Field | What to capture |
|---|---|
| Task | The bounded activity observed. |
| Trigger | What started it. |
| Action | What the host did or said. |
| Decision point | Where a path was selected, approval sought, or escalation made. |
| Tool or information | The tool, record, cue, or instruction used. |
| Reason given | The host's explanation, labelled as their explanation. |
| Exception | What differed from the usual path and why. |
| Follow-up question | What needs checking with another source or owner. |
Avoid names, credentials, personal circumstances, customer details, and case information unless they are necessary, permitted, and safe to record. Describe work conditions rather than speculating about people.
Brief and debrief without turning observation into assessment
Tell the host that the session is intended to capture current practice and its conditions, workarounds, and exceptions. One observation is not a universal standard or proof of cause and effect.
During the debrief, separate:
- Observed facts: actions, sequence, tools, and visible conditions.
- Host explanation: why the host says a step was taken.
- Participant interpretation: a possible meaning, clearly marked as interpretation.
- Unresolved questions: items needing more evidence.
- Process-owner verification: items requiring confirmation from the accountable owner.
Do not turn a host explanation directly into policy, training instruction, or a claim about performance.
Record the follow-up decision
Create a short decision record after the debrief:
- Decision: adopt, test, adapt, document, escalate, or discard.
- Reason: the observed condition and remaining uncertainty.
- Owner: the person responsible for the next step.
- Review trigger: a date, second observation, process-owner confirmation, or test result.
An approved and verified observation may later inform a practice card or learning resource. Keep those later stages separate from the shadowing session: Knowledge Sharing from HR Interviews: A Field Method and Organizational Learning: Turn Practice into Training.
Fictional example: checking a returns handoff
Fictional example. A retail operations coordinator wants to understand why some return requests receive a second review. They observe a store colleague for 45 minutes during an agreed period. The grid records that the colleague checks a product-condition note before deciding whether to escalate. The host says this can prevent a later dispute, while noting that another site uses a different handoff.
At debrief, the coordinator records the sequence as an observed fact, labels the rationale as the host's explanation, and asks the process owner whether the condition note is required everywhere. The decision is test, not adopt. Attendance, positive feedback, or observing a respected team does not by itself prove learning or performance improvement.
Glossary
Access boundary: The agreed limit on spaces, systems, conversations, records, or customer interactions the participant may enter or view. Define it before the session. It prevents a useful observation from expanding into access that is unnecessary for the stated work question.
Alternative method: A lower-exposure way to answer the same work question. It may be an interview, process walkthrough, document review, or demonstration using a non-live example. An alternative can be preferable when live work would create unnecessary privacy, safety, or operational risk.
Coordinator: The person who arranges the session, aligns its purpose and roles, checks practical conditions, and ensures that a debrief and decision record occur. The coordinator does not automatically own or approve the process being observed.
Decision point: A moment where the host chooses between actions, seeks approval, applies a rule, or escalates. Recording decision points can be more useful than capturing every routine movement because they reveal where conditions change the path through the work.
Exception: A departure from the usual path caused by a particular condition. It may reveal a local workaround, customer need, technical limitation, safety concern, or missing instruction. An exception is not automatically an error or evidence that the standard process is ineffective.
Host: The person whose work is observed. A host can explain choices and local context, but their explanation remains one perspective. It does not establish that the method is approved, standard, effective elsewhere, or appropriate for adoption without verification.
Observation boundary: The agreed scope of what the participant may watch and record. It includes the task, time window, people involved, information limits, and stop conditions. A clear boundary helps participants recognise when the session should pause or change.
Participant: The person observing the work. Their responsibility is to record relevant facts, respect the agreed boundary, avoid disrupting work, and distinguish observation from interpretation. They can raise questions at suitable moments or reserve them for the debrief.
Practice card: A concise record of a practice selected for possible reuse. It should retain context, conditions, exceptions, ownership, and verification status. A practice card is a later artifact, not an automatic output of a single shadowing session.
Process owner: The person accountable for confirming, changing, or maintaining a process. The process owner may determine whether an observed method is approved, local, outdated, suitable for testing, or outside the intended process.
Stop rule: A pre-agreed condition for pausing or ending the session. Examples include an unexpected confidential discussion, a safety-critical event, access outside the agreed boundary, a customer objection, or participant discomfort. The rule should be understood by both host and participant beforehand.
Verification: A separate human check of an observation, explanation, or proposed practice. It may involve a process owner, approved documentation, another site, or a controlled test. Verification keeps one session from becoming an unsupported standard.
Frequently asked questions
Is job shadowing a performance assessment?
It should not be when the agreed purpose is developmental observation. State that boundary before the session, avoid individual scoring, and focus the debrief on the work question rather than judgement of the host.
What should a participant write down?
Record the task, trigger, action, decision point, tool or information used, reason given, exception, and follow-up question. Do not record sensitive or identifying details unless they are necessary and permitted.
When should a team avoid job shadowing?
Choose another method when observation would create unnecessary privacy, access, safety, customer, or operational exposure, or when a lower-exposure method can answer the question adequately.
Does observing a strong team prove a practice works everywhere?
No. Treat the observation as an input for verification. Capture conditions and exceptions, then ask the accountable process owner whether to test, adapt, document, escalate, or discard it.