skills/difficult-situations/SKILL.md
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).
npx skillsauth add manager-dot-dev/manager-skills difficult-situationsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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.
.agents/em-context.md or .agents/reports/[name].md automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.Keep the first answer concise and useful. Do not dump the whole framework unless the user asks for depth.
Default to:
For difficult situations, prioritize safety, clarity, and sequence:
If the situation may involve harassment, discrimination, threats, layoffs, or termination, advise involving the appropriate company process rather than improvising alone.
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:
The goal is to protect the team environment without creating a public shaming event. Both things matter.
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:
The line is: you can think critically about your manager's decisions. You can't commiserate about them with your reports.
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:
What you shouldn't do:
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.
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:
What you owe them:
What you don't owe them:
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:
For the people who stay:
For yourself:
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.
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 surfacetesting
Score an Engineering Manager's coverage across all 12 cells of the EM Grid based on their calendar and Slack. Use this skill whenever someone wants to understand where they're spending their management energy, find blind spots, get a monthly self-reflection on their EM focus, or hear phrases like "score my EM grid", "where am I spending time as a manager", "what are my blind spots", "analyze my calendar as EM", "which EM areas am I neglecting", "how balanced is my management focus", or "check my EM grid coverage". Always pull live calendar data — never ask the user to describe their week manually.
development
Helps engineering managers write messages, announcements, and stakeholder updates that land well — produces a 3-Step Writing Framework (Prepare / Write Simply / Run a Garbage Collector), the Async Re-Explanation Trap (calling out missed messages), and the Compression/Decompression model for diagnosing why messages are misunderstood. Use when the user says "draft a message," "write an announcement," "communicate this change," "how do I word this," "message for my team," "write an update," or "how do I communicate X." Do NOT use for verbal feedback or difficult conversations (use `feedback` or `difficult-situations`).
development
Helps engineering managers build a functional PM–EM partnership and become more product-oriented — produces a 3-pattern PM–EM dynamic model (PM-Led / Engineering-Led / Fake Balanced), a true partnership definition, the "It's Important to Me" card for navigating disagreements, tips for getting engineers closer to customers and usage data (launch vs. landing, session recordings, customer conversations), and an explicit responsibilities exercise. Use when the user says "PM relationship," "PM drives me crazy," "product manager," "roadmap disagreement," "PM overrides me," "PM–EM partnership," "I want to be more product-oriented," or "how do I get engineers closer to customers." Do NOT use for general roadmap prioritization (use `roadmap-planning`) or when urgency is being manufactured by a PM (use `managing-urgency`).
testing
Helps engineering managers work effectively with Software Architects, Staff Engineers, and Principal Engineers — covers the EM's side of the relationship (responsiveness, proactive consultation, giving credit), how to advocate for architect time, pre-consultation preparation, and the two architecture team models (Centralized vs. Decentralized). Use when the user says "architect," "staff engineer," "principal engineer," "technical design review," "working with senior technical people," "getting architecture help," or "how do I get more architect time." Do NOT use for managing staff/principal engineers who report directly to you (use `managing-high-performers` or `delegation`).