Heard, seen, respected

HSR is a practice that helps people build empathy and trust by encouraging them to truly listen to and acknowledge one another - especially in situations where there are no easy answers or quick fixes.

What It Makes Possible:

Empathy in Action: Encourages participants to “walk in the shoes” of others, fostering deeper understanding.
Cultural Shift: Helps improve the group’s emotional climate and psychological safety.
Trust Building: Strengthens relationships by validating each person’s experience.
Pattern Awareness: Helps groups recognize and shift away from unproductive interaction habits.
Compassionate Practice: Reinforces the value of responding with care rather than control or overpromising.

How It Works:

Participants take turns sharing experiences while others listen without interrupting or fixing.
The focus is on being present and acknowledging - not solving.
Over time, this builds a foundation for more respectful and resilient collaboration.

Time needed
35 minutes

Preparation

Offline format	Online format
Prepare pieces of paper (post-its)	Prepare virtual whiteboard template to collect ideas (for example Miro Board Template)
Split into smaller groups (in pairs and foursomes)	Prepare split into smaller groups (in pairs and foursomes)

Set the stage
1. Invite participants to tell a story to a partner about a time when they felt that they were not heard, seen, or respected
2. Ask the listeners to avoid any interruptions other than asking questions like “What else?” or “What happened next?”
3. Example: "Today we’ll use a structure called Heard, Seen, Respected. You’ll each recall a time when you were not heard, seen, or respected. We won’t analyze or argue with anyone’s story. The point is to understand what it feels like, and how we might be doing similar things to others without realizing it. Please share only what you’re comfortable sharing. You can keep details vague if needed."
Step-by-step and timing
1. Preparation (3 min): Facilitator describes the sequence of steps and introduces the purpose of this structure.
2. Individual Reflection (5 min): Participants silently and individually reflect on the prompt and choose a specific story or experience to share where they felt not heard, seen or respected
3. Sharing stories in Pairs (15 min): In pairs, participants take turns to share their story, the other person listens silently. No interruptions, no advice, no questions
4. Looking for patterns in groups of 4 (10 min): Each person briefly summarizes their story (~1 min per person). Look for patterns across the four stories:
  - What made people feel unheard, unseen, or disrespected?
  - What behaviors or conditions showed up in more than one story?
  - What was happening in the environment (time pressure, hierarchy, remote setting, etc.)?
5. Whole group debrief (10 minutes). Groups are sharing patterns they discovered. Further definition of the impact and agreements and actions that would help people to feel more heard, seen and respected
Hints
1. Make it safe by saying, “You may not want to pick the most painful story that comes to mind.”
2. Make it safe by saying, “Protect carefully the privacy of the storyteller. Ask what parts, if any, you can share with others.
3. Model vulnerability (within your comfort zone). Briefly share your own example at the start, so others see what “concrete and honest” looks like.
4. Normalize discomfort. Acknowledge that this can feel vulnerable: “It’s okay if this brings up strong feelings; that’s part of the work.”
5. Protect the “no fixing” rule. If someone starts advising or analyzing during pairs, gently intervene: “Let’s hold off on solutions; the gift here is listening.”
6. Respect passers. If someone chooses not to share, allow them to listen. No pressure to “go anyway.”
7. End with forward momentum.Don’t leave people sitting in the pain alone; translate insights into small, actionable changes.
Examples of use
1. DevOps Team After a Major Incident
- Scenario: A DevOps/SRE team had a heated post-incident review. Some people felt blamed and shut down. Trust was low.
- On-call engineer’s perspective: In a Sev1 incident, they suggested rolling back a recent feature. A senior architect dismissed it abruptly: “That’s not the issue; focus on logs.” The rollback was implemented an hour later by someone else, and it resolved the incident. The on-call engineer felt:
  - Afraid to speak up next time
  - Undermined
  - Ignored
- Support engineer’s perspective: During the incident, they reported customer impact details in chat multiple times, but nobody acknowledged or acted on them. They felt like “noise.”
- Outcome: Several patterns were identified:
  - Strong hierarchy in crisis (senior voices dominate).
  - No explicit turn-taking or role clarity in incident channels.
  - Lack of acknowledgment in chat (messages get lost).
- Behavior changes decided:
  - Assign a clear “incident commander” role who calls on quieter voices, summarizes and acknowledges suggestions, use explicit “heard” markers in chat (e.g., “ACK: investigating X,” “Noted, will tackle after current step”).
  - Capture ideas in a shared doc during incidents to avoid losing them.
- Impact:
  - In later incidents, more people spoke up with observations and hypotheses.
  - Post-incident reviews became more collaborative and less defensive.
2. Agile Team Retrospective on Code Reviews
- Scenario: Several developers felt that code reviews were demoralizing; others thought they were “just being thorough.” In a retrospective following stories were presented:
  - Junior developer: In a PR with 30+ comments, many said things like “This is obviously wrong” or “No, we don’t do it like this.” No positive comments. They felt embarrassed and stopped volunteering for complex tasks.
  - Senior developer: In a previous company, lack of review rigor led to production bugs. They now default to very detailed, blunt feedback to “protect quality,” not realizing tone issues.
- Outcome: Following patterns were identified:
  - Lack of appreciation for what’s done well.
  - Blunt, absolute language (“obviously”, “no”, “wrong”).
  - Asymmetric power (senior → junior) magnifies the impact of tone.
  - Written-only communication, no synchronous discussion.
- Team agreements for code review:
  - Start with at least one positive acknowledgment.
  - Phrase feedback as requests or questions (“Could we…”, “What do you think about…”) rather than commands.
  - For large or sensitive changes, discuss via quick call before or after comments.
- Impact:
  - Juniors reported feeling safer to submit WIP PRs.
  - Seniors noticed fewer “defensive” responses in PR threads.
3. Cross-Functional Planning (Product, UX, Engineering, QA)
- Scenario: In quarterly planning, QA and UX felt sidelined; engineering and product dominated prioritization. Stories presented:
  - QA lead: They raised quality risks in the last quarter planning and were told, “We’ll address this if we have time.” When quality issues materialized, they were asked why they hadn’t warned anyone. They felt invisible.
  - UX designer: UX research insights were presented but not referenced in decisions. Roadmap decisions seemed purely feature-count and deadline-driven.
- Outcome: Following patterns were discovered:
  - “If we have time” language used as a dismissal.
  - Only engineering and product are seen as “deciders.”
  - Insufficient preparation time for QA/UX inputs prior to planning.
- Agreed actions:
  - Before planning - Require short input summaries from QA and UX alongside product/engineering.
  - In planning sessions - Dedicated time for QA and UX to present risks and opportunities, explicit question for each big item: “What is the UX perspective?” “What is the QA / testability perspective?”
  - Visual Kanban including “Design Ready” and “Test Strategy Ready” states.
- Impact:
  - Shift from “add QA/UX at the end” to involving them earlier.
  - QA and UX reported feeling more respected; quality and usability metrics improved
Link with other Liberating Structures
Combine with other Liberating Structures:

Appreciative interviews

Conversation café

Generation relationships

Helping heuristics

Troika consulting
Link to Liberating Structures page
Heard, seen, respected

Heard, seen, respected

Feedback