skills/managing-up/SKILL.md
Helps EMs build a reliable relationship with their manager, navigate disagreements with leadership, and communicate upward effectively. Use when the user says "managing up," "my manager," "I disagree with a decision," "I need to push back," "my skip level," "communicating with leadership," "my manager committed my team without asking," "how do I tell my boss," or "senior leadership." Do NOT use for influencing peers or cross-functional stakeholders (use influence) or for general EM self-reflection (use managing-yourself).
npx skillsauth add manager-dot-dev/manager-skills managing-upInstall 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 .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:
Identify the situation first:
When helping someone manage up, focus on reliability and leverage:
For disagreements, separate "I need to be heard" from "I need the decision changed."
"Managing up" is often described as a political skill. It isn't. At its core, it's about one thing: not making your manager look unreliable to their manager.
Every time you miss a deadline without warning, you put your manager in an impossible position. They committed that deadline upward. Your late delivery — especially when delivered as a surprise — damages their credibility, not just yours. Managers talk to each other. Repeated surprises end careers.
The rule: warn early, not late. As soon as you know you can't hit a commitment, say so. "Tuesday isn't happening — it'll be Friday" on Monday morning is recoverable. "Oops, it'll be next week" on Tuesday afternoon is not.
This applies upward at every level. The EMs who build durable relationships with senior leadership are often not the most talented — they're the most reliable. They follow through. They don't make promises they can't keep. They surface problems before they become surprises.
Manage your manager intentionally. Your manager often knows less than you about what the right decision is. When you bring a problem, also bring the decision you want them to make. "I want you to make the decision" is almost never the right ask — "here's what I think we should do, and here's what I need from you" is.
Respond promptly to anything that might be blocking your manager. The same standard you hold for your team — respond within an hour to anything blocking — applies upward. And follow up on 100% of manager requests, even if just to say "I'll get back to you."
When leadership makes a call you don't fully buy into, how you communicate it to the team matters more than people realize.
First: engage properly with the decision before communicating it. Distinguish between types:
The key principle: you're almost never as certain as you think you are. Most decisions that feel clearly wrong turn out to have context you didn't have.
What to tell the team: describe how you engaged with the process, not just the outcome. "I had concerns, I raised them, this is what was decided and why" is more credible than "leadership wants this." The first version maintains your integrity. The second erodes it every time.
A few behaviors that undermine how senior leadership perceives you:
Finesse matters. How you communicate has as much impact as what you communicate. Saying "everything we presented in the last 2 months was a lie" in a Slack channel — even if technically accurate — demoralizes people and signals lack of judgment. HOW you present difficult information matters.
Language accuracy. If you're not 100% sure about something, signal it. "I believe..." or "as far as I know..." prevents the frustration of confident-sounding statements that turn out to be wrong.
Delivering bad news. Don't associate yourself with the news. Avoid: a long preface about importance, multiple negative words, excessive detail. State the situation clearly, own what's yours, move to next steps.
Giving feedback to senior leaders. It's an inversion of norms — and feeling nervous about it is healthy. Techniques that work: use the "even more" framing ("I think you could have even more impact if..."), use yourself as an example rather than criticizing them directly, lead with curiosity rather than judgment, bring specific data and examples.
Most managers want their reports to manage up — but rarely say it explicitly. What this looks like in practice:
The EMs who have the most influence with their managers aren't the ones who make the fewest mistakes — they're the ones their manager trusts to carry things without dropping them.
When your manager gives you a difficult performance review, the first instinct is to blame the manager. Sometimes that's right. But half the blame is usually yours.
Don't expect your manager to guess your motivations. Don't expect 1:1s to automatically solve communication problems. Don't expect appreciation for work that was never made visible. The same principle works in reverse: if your team never tells you what's working or what's frustrating, part of that is on you for not creating the space.
If the user asks where a framework came from, wants to read the original article, or wants more context on any topic — read references/sources.md for the full list of source articles (with links) and books.
managing-yourself — The 10 ways EMs get stuck includes traps #8–10 on managing up and downinfluence — For persuading peers, cross-functional stakeholders, and getting headcountfeedback — Giving feedback to your manager is a specific case of the feedback skilltesting
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`).