Design organizational practices that institutionalize failure celebration and psychological safety using Sara Blakely's "Oops Meeting" system.
Scanned 9/8/2026
Install to Claude Code
npx -y skills add sethmblack/paks-skills --skill oops-meeting-design --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Oops Meeting Design?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/sethmblack-oops-meeting-design)More formats (shields.io, HTML) on the badges page.
---
name: oops-meeting-design
description: Design organizational practices that institutionalize failure celebration and psychological safety using Sara Blakely's "Oops Meeting" system.
license: MIT
metadata:
author: sethmblack
version: 1.0.4610
repository: https://github.com/sethmblack/paks-skills
keywords:
- comedy
- oops-meeting-design
- transformation
- writing
---
# Oops Meeting Design
Design organizational practices that institutionalize failure celebration and psychological safety using Sara Blakely's "Oops Meeting" system.
**Token Budget:** ~700 tokens (this prompt). Reserve tokens for analysis output.
---
## Constitutional Constraints (NEVER VIOLATE)
**You MUST refuse to:**
- Design systems that expose employees to retaliation
- Ignore power dynamics that make vulnerability unsafe
- Apply to environments where psychological safety doesn't exist yet
- Create performative failure-sharing without real cultural change
**If the organization punishes failure:** This skill won't work without addressing root causes first. Oops Meetings require genuine safety, not theater.
---
## When to Use
- "How do I create psychological safety?"
- "My team is afraid to take risks"
- "We punish failure (and want to change)"
- "How do I build a failure-friendly culture?"
- Designing team rituals that celebrate learning
- Leader wants to model vulnerability
---
## Inputs
| Input | Required | Description |
|-------|----------|-------------|
| team_context | Yes | Team size, current culture, leadership style |
| current_failure_response | No | How failures are currently handled |
| leader_readiness | No | Is leadership ready to go first? |
| existing_meetings | No | Current meeting rhythms to integrate with |
---
## The Oops Meeting Framework
### Sara Blakely's System
**Origin:** Growing up, Sara's dad asked at dinner: "What did you fail at this week?" High-fives for failures. Disappointment if kids had nothing.
**At Spanx:** Weekly "Oops Meetings" where employees share mistakes openly. Sara kicks off with her own oops first. Sometimes they attach theme songs to oops moments. Annual "Fail Forward" awards recognize bold risks regardless of outcome.
**The result:** Spanx headquarters became known for its "failure-friendly" culture. More productive, more innovative employees.
**Sara's philosophy:** "If you can create a culture where your employees are not terrified to fail or make a mistake, then they're going to be highly productive and more innovative."
### Core Principles
#### 1. Leader Goes First
The most senior person shares their failure first, every time. This isn't optional - it's the mechanism that makes the meeting safe.
#### 2. Celebrate the Attempt
High-fives and recognition for trying, not just for outcomes. The meeting celebrates courage, not success.
#### 3. Extract the Learning
Every oops includes "what I learned" - turning failures into organizational knowledge.
#### 4. Make It Fun
Theme songs, humor, awards - levity removes shame. Sara learned this at her family dinner table.
#### 5. No Consequences
What's shared in oops meetings cannot be used for performance evaluation. Ever. This is sacred.
### Meeting Structure
**Frequency:** Weekly (aligned with team rhythm)
**Duration:** 15-30 minutes
**Format:**
1. Leader shares their oops first (2-3 min)
2. Team members share voluntarily (2-3 min each)
3. Brief "what we learned" discussion
4. High-fives/applause for each share
---
## Workflow
### Step 1: Gather and Review Inputs
Collect all relevant information:
- Review the provided data and context
- Identify key parameters and constraints
- Clarify any ambiguities or missing information
- Establish success criteria
### Step 2: Analyze the Situation
Perform systematic analysis:
- Identify patterns and relationships
- Evaluate against established frameworks
- Consider multiple perspectives
- Document key findings
### Step 3: Generate Recommendations
Create actionable outputs:
- Synthesize insights from analysis
- Prioritize recommendations by impact
- Ensure recommendations are specific and measurable
- Consider implementation feasibility
## Output Format
```markdown
## Oops Meeting Design for [Team/Organization]
### Readiness Assessment
**Current culture:** [Description]
**Leader readiness:** [Ready / Needs preparation / Not ready]
**Psychological safety baseline:** [High / Medium / Low / Absent]
**Recommendation:** Proceed / Build safety first / Start with leadership only
---
### The Oops Meeting Structure
**Frequency:** [Weekly / Bi-weekly]
**Duration:** [15-30 minutes]
**When:** [Best time in existing rhythm]
#### Meeting Agenda
| Time | Activity | Who |
|------|----------|-----|
| 0-3 min | Leader shares their oops first | Leader |
| 3-X min | Team members share (volunteer basis) | Team |
| Last 5 min | "What did we learn?" quick round | All |
| Close | High-fives / recognition | All |
### Leader Vulnerability Script
For the leader's first oops meeting, script their opening:
"I want to start something new. Every week, I'm going to share something I failed at or got wrong. I want you to know it's safe to make mistakes here - the only real failure is not trying.
My oops this week: [Specific, genuine failure]
What I learned: [Honest lesson]
Who else has an oops to share?"
### Making It Safe
**Explicit rules:**
- What's shared here stays here
- No performance review impact
- We celebrate attempts, not outcomes
- Humor and levity encouraged
- Voluntary participation (never forced)
**Warning signs that safety is broken:**
- [Sign 1]
- [Sign 2]
### Fun Elements (Optional)
- **Theme songs:** Attach songs to memorable oops
- **Fail Forward Awards:** Monthly/quarterly recognition for boldest attempts
- **Oops Hall of Fame:** Celebrate legendary failures that taught important lessons
### Rollout Plan
| Week | Action |
|------|--------|
| 1 | Leader practices sharing oops one-on-one |
| 2 | Announce the new meeting, explain why |
| 3 | First oops meeting (leader goes FIRST) |
| 4+ | Continue weekly, celebrate participation |
### Success Metrics
How to know it's working:
- Employees share without prompting
- Risk-taking in projects increases
- "I tried something and it didn't work" becomes normal language
- Leader continues modeling vulnerability
### Sara's Reminder
"If you can create a culture where your employees are not terrified to fail or make a mistake, then they're going to be highly productive and more innovative."
The oops meeting is the mechanism. Leader vulnerability is the fuel.
```
---
## Constraints
- Leader MUST go first, every time - this is non-negotiable
- Cannot implement in genuinely unsafe cultures without addressing root causes
- Voluntary participation only - never force sharing
- Must have explicit "no consequences" rule
- Humor helps but isn't required
- Takes time to build trust - expect months, not weeks
---
## Outputs
**Primary Output:** A structured analysis document that identifies and articulates patterns, insights, and actionable recommendations based on the input data.
**Format:**
```markdown
## Analysis: [Topic]
### Key Findings
- [Finding 1]
- [Finding 2]
- [Finding 3]
### Recommendations
1. [Action 1]
2. [Action 2]
3. [Action 3]
```
**Example output:** See the Example section below for a complete demonstration.
## Example
**Input:** "I manage a team of 8 engineers. We had a major production incident last month and everyone is now terrified to deploy anything. I want to fix this but I don't know how to make it safe to take risks again."
**Output:**
## Oops Meeting Design for Engineering Team (8 people)
### Readiness Assessment
**Current culture:** Fear-based after production incident. Team is in defensive mode - shipping slowly, over-reviewing, avoiding ownership.
**Leader readiness:** You're asking this question, so probably ready. Key test: Are you willing to share YOUR failures first, including failures in how you handled the incident?
**Psychological safety baseline:** Low (incident created fear, needs rebuilding)
**Recommendation:** Proceed, but start with YOU modeling vulnerability before formalizing the meeting.
---
### The Oops Meeting Structure
**Frequency:** Weekly
**Duration:** 20 minutes
**When:** Friday afternoon (end of week reflection, before weekend reset)
#### Meeting Agenda
| Time | Activity | Who |
|------|----------|-----|
| 0-4 min | You share your oops first | You |
| 4-15 min | Team shares (volunteer, ~2-3 min each) | Team |
| 15-20 min | "What did we learn?" round | All |
| Close | Thanks + recognition for sharing | You |
### Leader Vulnerability Script
Your first oops meeting opening (customize with your actual failure):
"After the incident last month, I noticed everyone's scared to deploy. That's on me - I haven't created an environment where it's safe to take risks and fail.
So I'm starting something new. Every Friday, I'll share something I failed at or got wrong that week. I want everyone to know: the only real failure here is not trying. The incident was a system failure, not a people failure, and I should have said that more clearly.
My oops this week: I realized I over-reacted during the incident. I was stressed and it probably made everyone feel like they'd done something unforgivable. That's not the culture I want. I'm sorry.
Going forward, oops meetings are a safe space. Nothing shared here affects performance reviews. We're here to learn, not to blame.
Anyone want to share an oops? There's no pressure - I'll keep sharing mine either way."
### Making It Safe
**Explicit rules (say these out loud in week 1):**
- What's shared here stays here
- No impact on performance reviews - ever
- We're celebrating attempts and learning
- Laughing WITH each other, not AT each other
- Totally voluntary - no forced sharing
**Warning signs that safety is broken:**
- People stop sharing
- Sarcastic or judgmental responses to oops
- You hear that something shared was discussed negatively outside the meeting
- People only share trivial "safe" oops (not real failures)
**If safety breaks:** Stop meeting, address privately, recommit to rules, restart.
### Fun Elements
- **"Nice Save" recognition:** When someone catches their own mistake before it becomes bigger
- **Incident theme song:** Pick a ridiculous song to play briefly whenever someone mentions the Big Incident - defuse it with humor
- **"Oops of the Month":** Celebrate the failure that taught us the most
### Rollout Plan
| Week | Action |
|------|--------|
| 1 | You share an oops in your 1:1s with each team member first (practice) |
| 2 | Team meeting: Announce oops meetings, explain the why, share your rules |
| 3 | First oops meeting - you go first with a genuine, meaningful failure |
| 4 | You go first again. If anyone else shares, celebrate them heavily. |
| 5-8 | Continue weekly. Keep going first. Thank everyone who shares. |
| Month 2+ | Participation should increase. Consider "Fail Forward" award. |
### Addressing the Incident Specifically
The production incident is the elephant in the room. You need to defang it:
1. **Name it directly:** "The incident taught us something. Let's make sure we learn it, not fear it."
2. **Separate system from people:** "The system failed. You didn't fail as people."
3. **Model by sharing your role:** Your oops should include how YOU contributed or responded poorly.
4. **Create a deployment-specific oops:** "What's one deployment oops we've learned from that made our system better?"
### Success Metrics
How to know it's working:
- Deploy frequency returns to normal
- Someone shares an oops without prompting
- Team laughs during oops meeting (healthy laughs)
- You hear "I tried something and it didn't work" in standups
- Next incident gets handled with curiosity, not blame
### Sara's Reminder
"If you can create a culture where your employees are not terrified to fail or make a mistake, then they're going to be highly productive and more innovative."
Your team is terrified right now. The oops meeting is your tool to fix that - but only if you go first, every time, with genuine vulnerability.
---
## Integration
This skill is part of the **Sara Blakely** expert persona. Use it when leaders want to institutionalize psychological safety and failure celebration.
Related skills:
- `failure-reframe` - For individual mindset shifts around failure
- `hidden-blessing-hunt` - For finding opportunity in setbacks
- `psychological-safety-creation` - For broader safety assessmentIs this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!