| name | difficult-situations |
| description | Provides situational playbooks for high-stakes edge cases that don't fit the standard management toolkit — produces step-by-step guidance for inappropriate team behavior, an engineer badmouthing your manager, letting someone go when circumstances are hard, manager quitting guilt, and handling layoffs (for both those leaving and those staying). Use when the user says "don't know how to handle this," "someone said something inappropriate," "engineer said something offensive," "developer talks badly about my manager," "letting someone go when their situation is hard," "I feel guilty about leaving my job," or "handling a layoff." Do NOT use for standard underperformance management (use performance-reviews) or giving direct feedback (use feedback). |
| metadata | {"version":"2.1.2"} |
Difficult Situations
Before Starting
Check for EM context first. If .agents/em-context.md exists, read it. If a specific person is mentioned, check .agents/reports/[name].md.
If .agents/em-context.md does not exist, ask for a minimal manager profile first and save it before giving detailed advice: role/title, team size, team mission or ownership area, and current challenge or priority.
If a specific person is central to the conversation and .agents/reports/[name].md does not exist, ask for a minimal profile for that person first and save it before giving detailed advice: title/level, tenure, strengths, and current challenge or growth area.
If the conversation reveals durable new context later, update .agents/em-context.md or .agents/reports/[name].md automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.
Response Style
Keep the first answer concise and useful. Do not dump the whole framework unless the user asks for depth.
Default to:
- State the likely diagnosis or recommendation first
- Ask at most 2-3 targeted questions only if the missing context changes the advice
- Give the next concrete action and, when useful, exact wording the manager can use
- Mention the relevant framework briefly, but do not explain every part of it
- Offer a deeper version only after the direct answer
How to Use This Skill
- Offensive or inappropriate remark posted in a team channel → Inappropriate Remarks in Team Channels
- Engineer is venting about or criticizing your manager to you → When an Engineer Talks Badly About Your Manager
- Letting someone go but their personal circumstances are terrible → Letting Someone Go When the Timing Is Terrible
- Feeling guilty about leaving your own job → Quitting as a Manager: The Guilt That Comes With It
- Planning or executing a layoff → Handling Layoffs
Default Response Shape
For difficult situations, prioritize safety, clarity, and sequence:
- Situation read: what is at stake and who could be harmed.
- Immediate action: what to do first, especially if delay sends the wrong signal.
- Private follow-up: who needs a 1:1 and what to say.
- Documentation / escalation: what to record and when to involve HR, legal, or leadership.
- Repair path: how to stabilize trust after the acute moment.
If the situation may involve harassment, discrimination, threats, layoffs, or termination, advise involving the appropriate company process rather than improvising alone.
Inappropriate Remarks in Team Channels
When something offensive or inappropriate is posted in a team channel — a homophobic remark, a racist joke, a comment that demeans a colleague — you have to act. Not acting is a decision too, and the team is watching.
What to do:
- Don't ignore it or wait. The longer you wait, the more the silence reads as endorsement.
- Address it in the channel first, briefly. Something like: "That's not the kind of thing we share in this space." Keep it short and non-escalating in public.
- Follow up 1:1 with the person who posted it. Don't pile on publicly, but the private conversation needs to happen. Be clear about what the expectation is going forward.
- Check in with anyone who may have been affected. A quick, private message — not a formal HR conversation, just: "I saw that and I want you to know it's not acceptable and I'm handling it."
The goal is to protect the team environment without creating a public shaming event. Both things matter.
When an Engineer Talks Badly About Your Manager
A developer tells you in a 1:1 that your manager is incompetent, made a bad call, or is screwing over the team. Or they say it in a way that's clearly trying to get you to take a side.
This is a loyalty test dressed as a venting session.
What to do:
- Don't agree, even if you partly do. Validating criticism of your manager — to a direct report — breaks the chain of trust in both directions. You become the person who talks about your manager with your team.
- Don't dismiss it either. "I hear that you're frustrated with that decision" is honest. "My manager is fine, you just don't understand" is dishonest and condescending.
- Redirect toward what's actionable. "I can't speak to what's behind that decision, but I can look into how it affects your work and whether there's a way I can advocate for something different."
- If there's a genuine grievance, take it seriously. Separately from the conversation, evaluate whether the concern is legitimate. If it is — raise it through the right channels.
The line is: you can think critically about your manager's decisions. You can't commiserate about them with your reports.
Letting Someone Go When the Timing Is Terrible
The engineer is a father of four. They just bought a house. Their spouse is dealing with a health issue. You know about it all.
There is no clean version of this. The decision about whether to let someone go should be made on whether they're in the right role — not on the circumstances of their personal life. If you make exceptions based on personal circumstances, you'll never be able to make this call, and the team and the individual both pay the price of the right decision being deferred indefinitely.
What you can do:
- Be generous on the timeline where possible — a few extra weeks of notice, a longer formal transition period
- Be generous on the severance or support you advocate for internally
- Be honest in the conversation: name what isn't working clearly, and be humane in how you frame it
- Be available after — a good reference, an introduction, a recommendation
What you shouldn't do:
- Keep someone in a role they're not succeeding in because you feel guilty about their circumstances
- Avoid the conversation indefinitely while both parties know what's coming
The hardest version of this job is making a decision you know is right while knowing it's going to hurt someone. That discomfort doesn't go away. Carrying it is part of the role.
Quitting as a Manager: The Guilt That Comes With It
When a manager leaves a job, the guilt structure is different from when an individual contributor leaves.
You feel responsible for your team — people who trusted you, whose careers you influenced, some of whom joined because of you. Leaving feels like abandonment, especially if the team is mid-project, mid-difficulty, or in a period of instability.
Some honest realities:
- You're not betraying them. Your team members would leave for better opportunities without feeling they were betraying you. You're allowed to do the same.
- Your replacement will be fine. Teams don't collapse when good managers leave. Strong teams outlast managers.
- The guilt is a signal of care, not obligation. Feeling it means you took the role seriously. Acting on it by staying in a role that's no longer right for you doesn't serve the team either.
What you owe them:
- A thoughtful transition — no disappearing act, no pretending nothing is happening
- Honest conversations with people who deserve to hear it from you directly
- A strong handoff — documentation, context, introductions
What you don't owe them:
- Staying indefinitely
- A timeline that's dictated by guilt rather than what's best for your next chapter
Handling Layoffs
Layoffs are logistically and emotionally hard. Some things that reduce the harm:
Why secrecy during planning is necessary — and painful. You can't communicate details you don't yet have. In the absence of specifics, people fill the void with fear. Premature disclosure creates ruptures that can be permanent. This secrecy is uncomfortable but it protects people from worse outcomes.
Be a fair witness to the difficulty. It feels arbitrary and unfair — because it often is. People who didn't contribute to the business problem lose their jobs because of it. That's genuinely hard, and feeling bad about it is appropriate. What's not appropriate is letting that feeling drive decisions about who stays and goes (see "Letting Someone Go When the Timing Is Terrible" above).
For the people being let go:
- Be direct and clear. Tell them in person (or live video). Don't bury the message.
- Give them what they need to understand what comes next: severance, benefits continuation, timeline, reference availability.
- End the conversation cleanly. Prolonged attempts to process it together usually make it harder, not easier.
For the people who stay:
- Acknowledge what happened. Don't act like nothing changed. People who survived a layoff are processing loss and uncertainty — they need honesty about what comes next more than reassurance that everything is fine.
- Be honest about what you know and what you don't. "I don't know" is more credible than false certainty.
- Give them space for the grief. Productivity will dip. That's normal.
For yourself:
- You may be implementing a decision you didn't make and didn't want. That's a real burden. Find a peer or mentor to process it with — outside your team.
Dive Deeper
If the user asks where a framework came from, wants to read the original article, or wants more context on any topic in this skill — read references/sources.md for the full list of source articles (with links) and books.
Related Skills
feedback — Most difficult situations require a direct feedback conversation firstperformance-reviews — The formal letting-someone-go process lives heremanaging-yourself — How to lead under pressure and absorb team fear during hard moments1on1s — The place where most of these situations first surface
