본문으로 건너뛰기
cccskills
무료GitHub에 공개

psychological-safety

Build psychological safety in your team using Simon Sinek's Leaders Eat Last Circle of Safety model and Amy Edmondson's research. Use when a leader says "my team doesn't speak up", "people are afraid to fail", "nobody challenges bad ideas", "people only tell me what I want to hear", "I want my team to take more risks", "there's a blame culture", "people hide mistakes", or "I want to create a safe environment". Also trigger when someone describes a team where postmortems turn into blame sessions, where people stay quiet in meetings and then vent privately, where mistakes are hidden until they become crises, or where the same person speaks 80% of the time in every meeting. Psychological safety is not about comfort - it is the condition that makes high performance possible.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(1)

  • SKILL.md10.2 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Overview

Based on "Leaders Eat Last" by Simon Sinek and Amy Edmondson's psychological safety research. Sinek's insight: humans are wired to withhold their best thinking in environments that feel unsafe. The Circle of Safety - the conditions under which people feel protected from external threats - is the leader's most fundamental responsibility. Without it, people use cognitive energy protecting themselves from internal threats (judgment, blame, embarrassment) rather than solving real problems. Edmondson's research found psychological safety is the single strongest predictor of team performance - more than talent, resources, or strategy.

The Four Stages of Psychological Safety

Edmondson and Sinek's work maps to a progression:

StageDescriptionSignal
InclusionPeople feel accepted as members of the teamNew members contribute within the first week
LearnerPeople feel safe asking questions and admitting they don't knowPeople say "I don't know" without hedging
ContributorPeople feel safe doing their work and trying new approachesPeople take initiative without asking permission
ChallengerPeople feel safe challenging the status quo and authorityPeople disagree with the leader openly

Most teams that think they have psychological safety are at Inclusion or Learner. True high performance requires Challenger safety.

Workflow

Step 1: Diagnose the Current Level

Observable signals that safety is low:

  • Meeting pattern: one or two people dominate, others are silent or give short answers
  • Retrospectives: problems are stated vaguely or attributed to external factors, never to internal decisions
  • Mistakes: people hide problems until they're unavoidable, then over-explain
  • Disagreement: happens in side conversations (Slack DMs, hallway chats) but not in the room
  • Questions: people ask questions privately in 1:1s that they won't ask in group settings

Observable signals that safety is high:

  • People raise problems early, when they're still small
  • People disagree with each other (and with you) in meetings, not just privately
  • Someone says "I made a mistake" or "I don't know" without a defensive disclaimer
  • New ideas come from multiple people, not just the same two people
  • Postmortems focus on system failures, not individual blame

Run a quick check: In your last 5 team meetings, how many distinct voices contributed substantively? If the answer is 2-3 in a team of 8+, safety is low.

Step 2: Identify the Leader's Contribution to the Problem

Before prescribing interventions, the leader must assess their own behavior. Most low-safety environments are created by the leader, not by team dynamics.

Common leader behaviors that erode safety:

Response to mistakes:

  • Does the team see you respond to failures with analysis or blame?
  • When you or your team makes a mistake, do you own it publicly?

Response to disagreement:

  • When someone challenges your idea, do you engage with curiosity or defend?
  • Do you treat counterarguments as threats or as information?

Response to bad news:

  • When someone brings you a problem, is your first reaction "thanks for telling me" or visible frustration?
  • Do people wait to bring you problems until they have a solution? (This is a sign they don't feel safe raising raw problems)

Body language and signals:

  • Do you check your phone or laptop in meetings?
  • Do you visibly react to opinions you disagree with before the person finishes speaking?

Complete this honestly:

When was the last time I admitted a mistake to my team? [date or "can't remember"]
When was the last time I changed my position because of someone's argument? [date or "can't remember"]
When someone challenged me, what did I actually do? [describe]
What do I do when someone brings me bad news? [describe]

Step 3: Build Inclusion Safety (Foundation)

If people don't feel like they belong on the team, nothing else works.

Actions:

  • Onboard new team members explicitly - make introductions, assign a peer buddy, check in weekly for the first month
  • Use names in meetings. "What do you think, [name]?" signals that you know who they are and their input matters
  • Acknowledge contributions publicly: "That point [name] made last week shaped how we approached this"
  • Make eye contact and face people when they speak - physical attention is a signal of safety

Step 4: Build Learner Safety

People need to feel safe not knowing before they'll ask questions that surface real problems.

Actions:

  • Model intellectual humility publicly: "I don't know the answer to that - let's find out" in front of the full team
  • Praise questions, not just answers: "That's an important question" before answering it
  • Create a "dumb question" norm - in meetings, explicitly invite the "basic" question that everyone is thinking but no one wants to ask
  • Run "pre-mortems" before big decisions: "What don't we know yet that we should know?" This normalizes not knowing

Step 5: Build Contributor Safety

People need to feel safe taking initiative before they'll operate without constant guidance.

Actions:

  • Give explicit permission to act: "You don't need my approval to [specific category of decisions]. Just do it and tell me."
  • When someone makes a mistake while taking initiative, treat it as learning, not failure: "What did you try? What did you learn? What's the next experiment?"
  • Debrief failed experiments with the same rigor as failed execution - distinguish between bad process and bad luck
  • Publicly celebrate initiative, not just results: "I want to call out that [person] tried a completely new approach here, even though it didn't work as expected"

Step 6: Build Challenger Safety

This is the hardest and most valuable stage. It requires the leader to be genuinely comfortable with dissent.

Actions:

  • Assign devil's advocate roles in major decisions - making it a role removes the personal risk of being "the difficult one"
  • Use "two-hat" meetings: first half, generate ideas freely; second half, critique them. Keep the phases separate so people don't self-censor in the first half
  • When someone challenges you, respond with questions first: "Tell me more about that" or "What are you seeing that I might be missing?"
  • Change your position visibly when you're persuaded: "I was wrong about that. [Name]'s point changed my thinking." This is the highest-signal behavior for challenger safety

Step 7: Psychological Safety Health Check

Run this with the team quarterly (anonymous survey or group exercise):

Psychological Safety Check - [team] - [date]

Rate each statement 1-5 (1=never, 5=always):

1. I feel comfortable raising a problem before I have a solution.
2. I can disagree with [manager name] or senior team members without negative consequences.
3. When mistakes happen, we analyze the system, not blame the person.
4. I can say "I don't know" without it reflecting poorly on me.
5. New ideas are welcomed, even if they challenge how we currently do things.

Average score: [x/5]

Lowest-scoring statement: [this is where to focus]
One action we'll take in the next 30 days: [specific, behavioral]

Anti-Patterns

1. Confusing psychological safety with conflict avoidance Bad: "We have a great culture - we never have conflict." Good: Low-conflict teams are often low-safety teams where disagreement goes underground. Healthy psychological safety produces more productive conflict, not less. The goal is conflict that makes decisions better, not silence that protects them.

2. Responding to bad news with problem-solving before acknowledgment Bad: Someone says "we're going to miss the deadline" and you immediately go to "OK what are our options." Good: First: "Thanks for telling me early. What happened?" The problem-solving matters, but if people learn that bad news triggers immediate interrogation, they wait longer to share it next time.

3. Praising psychological safety without modeling it Bad: Saying "I want you to speak up if you disagree" but visibly bristling when someone does. Good: People watch behavior, not words. The leader's reaction to the first challenge in the room determines whether everyone else will challenge. One dismissive response can undo months of stated intent.

4. Safety as a morale initiative, not a performance tool Bad: Running psychological safety workshops as an HR requirement and treating it as culture work unrelated to outcomes. Good: Edmondson's research is unambiguous: psychological safety predicts team performance. Frame it as a performance lever, not a feelings exercise. Teams that feel safe make fewer mistakes, learn faster, and produce better outcomes.

5. Group surveys without action Bad: Running a psychological safety survey and not acting on the results. Good: Surveying without acting is worse than not surveying. It signals that the data doesn't matter. Every survey must produce at least one visible action. Share what you heard and what you're going to do about it.

Quality Checklist

  • Diagnosed current safety level using observable meeting and behavior signals
  • Leader's own contribution to the problem assessed honestly
  • Starting at the right stage (don't skip to Challenger if Inclusion is broken)
  • At least one specific leader behavior change identified, not just team interventions
  • Quarterly health check or survey scheduled
  • Follow-up action taken on survey results within 30 days
  • Postmortems and mistake conversations reviewed for blame patterns

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Rate any product, feature, or experience on the 11-star scale (Brian Chesky's Airbnb thought experiment). Use when user says "rate this experience", "11-star", "star rating", "experience audit", "how good is this", "experience rating", "product audit", "quality assessment", or wants to evaluate product quality and identify improvement paths. Also trigger when user wants to benchmark a feature, assess where a product stands, or map out what "great" looks like - even if they don't explicitly say "11-star".

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

qa-aman/claude-skills212026년 10월 19일 업데이트

Generate A/B copy variants grounded in Eugene Schwartz's awareness and market-sophistication stages and John Caples' tested-headline discipline. Every variant declares its angle, the awareness stage it targets, and a falsifiable hypothesis, and the skill recommends which pair to test first and what delta counts as signal. Use when the user says "A/B test this", "write variants", "give me options", "test different angles", "copy variants", "ab copy", "test this headline", "multiple versions", "which version is better", or wants to test copy before publishing. For reviewing copy that already exists, see copy-review. For sample size and stopping rules, see growth-experiment. For diagnosing a page rather than its words, see page-cro. For full paid ad sets by platform, see ad-campaign-writer.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

qa-aman/claude-skills212026년 10월 19일 업데이트

Design statistically rigorous experiments to test data science hypotheses. Use when the user says "design an A/B test", "run an experiment", "test this hypothesis", "is this difference significant", "how many samples do I need", "randomized controlled trial", "causal inference", "uplift test", "holdout group", "significance test", "power calculation", "avoid p-hacking", or needs to determine whether an observed effect is real before making a product or model decision. For lean build-measure-learn product experiments without the statistics, use experiment-design instead.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

qa-aman/claude-skills212026년 10월 19일 업데이트

Write measurable acceptance criteria for requirements or user stories. Use when the user says "write acceptance criteria", "definition of done", "how do we test this", "fit criteria", "given when then", "Gherkin scenarios", "what does done look like", "testable conditions", "how will we know this works" - even if they don't explicitly say "acceptance criteria".

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

qa-aman/claude-skills212026년 10월 19일 업데이트

Build a strategic account plan for winning, retaining, or expanding a named account. Use when the user says "build an account plan", "strategic account planning", "how do I grow this account", "account expansion strategy", "whitespace analysis", "QBR prep", "key account review", "map the stakeholders in this account", "land and expand plan", "how do I break into [company]", or wants a structured strategy for a specific account.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

qa-aman/claude-skills212026년 10월 19일 업데이트

Write paid ad copy for LinkedIn, Google, Meta, and YouTube. Produces multiple variants per platform, each targeting a different Eugene Schwartz awareness level and Cialdini persuasion principle. Use when the user asks for ad copy, ad variants, "write LinkedIn ads", Google ads, Meta ads, paid social copy, ad headlines, or wants creative for a paid campaign. Reads brand voice, ICP, and positioning from knowledge/. For organic social posts, see linkedin-post or social-calendar. For the landing page the ad points at, see landing-page-writer. For testing variants, see ab-copy-writer.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

qa-aman/claude-skills212026년 10월 19일 업데이트

qa-aman의 스킬 모두 보기

이 스킬의 문제 신고