
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.
Helps engineering managers support direct report growth — produces a stage-by-stage model of engineering impact (Circles of Influence), a framework for non-linear career planning (Tarzan Method), diagnostic signals for stalled growth, conversation scripts for career talks, and a promotion readiness vs. timing distinction. Use when the user says "career growth," "promotion," "career path," "this person wants to grow," "career conversation," "what's next for this person," "career ladder," "IC vs manager track," "how do I help my report advance," "help someone grow," or "engineer wants a promotion." Do NOT use for formal written performance reviews or underperformance — use performance-reviews instead.
Helps engineering managers prevent and respond to engineer attrition by diagnosing retention risk, choosing the right intervention, and preparing retention conversations. Use when the user says "developer quit," "attrition," "someone is disengaged," "how do I retain," "engineer is leaving," "developer unhappy," "keeping the team," "someone seems checked out," "engineer received another offer," "retention risk," or "my best engineer may leave." Produces a five-state diagnostic, action plan, conversation script, compensation/equity guidance, zero-budget recognition ideas, and warning signs. Do NOT use when the issue is day-to-day motivation only; use engineer-motivation.
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`).
Guides managers out of the bottleneck role — provides the Team Rep pattern, Epic Ownership model, Task-Relevant Maturity framework, kingdom ownership, and three-layer assignment strategy. Use when the user wants to delegate work or says "I'm doing everything," "team isn't taking ownership," "I can't let go," "team rep," "project ownership," "I'm the go-to person," "bus factor," "I work weekends," "how do I delegate," or "engineers don't take initiative." Do NOT use for managing a specific underperformer (use performance-reviews) or deciding what work to prioritize (use roadmap-planning).
Helps engineering managers measure and improve team delivery — produces a history of why common metrics fail, the DORA four-key-metrics framework (deployment frequency, lead time, change failure rate, MTTR), DevEx's three dimensions (feedback loops, cognitive load, flow state), a translation layer from engineering metrics to business outcomes, and a list of measurement anti-patterns to avoid. Use when the user says "how do I measure productivity," "DORA metrics," "velocity," "cycle time," "developer experience," "DevEx," "how do I show our team is performing well," "metrics for engineering," "team is slow," "engineering performance," or "connect engineering to business." Do NOT use for managing an underperforming individual — use performance-reviews instead.
Covers both giving and getting feedback — structures and scripts feedback conversations (positive, constructive, or behavioral) and provides techniques for drawing honest feedback from your own team. Produces SBI-framed feedback statements, opening lines for hard conversations, scripts for real situations, ways to handle resistance, and methods for extracting real feedback from reports. Use when the user wants to give someone feedback, says "how do I tell someone," "this person is struggling," "address a behavior," "hard conversation," "someone is underperforming," "praise this person," "write feedback for," "I need to say something," "difficult conversation," "get feedback from my team," "my team won't give me feedback," "blind spots," or "what does my team think of me." Do NOT use for formal annual or performance reviews (use performance-reviews) or sensitive HR situations that go beyond feedback (use difficult-situations).
Guides engineering managers through the specific challenges of managing top engineers — produces a four-quadrant ability/confidence diagnostic, the Rock Star vs. Superstar distinction, common mistakes to avoid, a stagnation diagnostic (Diminishing XP), and a Pusher vs. Puller framework for managing burnout and team friction. Use when the user says "rockstar engineer," "superstar," "high performer," "brilliant jerk," "wants promotion," "hardest to manage," "overconfident," "my best developer is burning out," "engineer is frustrated," or "my best developer is pushing me." Do NOT use for standard underperformance (use performance-reviews) or general motivation questions (use engineer-motivation).
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).
Helps EMs assess their own effectiveness, avoid common traps, navigate bad days, and handle recurring tensions in their own mindset and behavior. Use when the user says "I feel stuck," "am I doing this right," "personal development," "EM effectiveness," "blind spots," "bad days," "sanity check on my behavior," "the same problem keeps coming back," "made a mistake with someone," or "my team isn't motivated." Do NOT use when the issue is about the user's relationship with their own manager (use managing-up) or giving specific feedback to someone (use feedback).
Covers the full meeting lifecycle for engineering managers — produces guidance on whether to schedule a meeting, how to run it well, how to protect team focus time, how to kill recurring waste, and how to evaluate a past meeting from a transcript or description. Use when the user says "too many meetings," "meetings are a waste of time," "how do I run this meeting," "meeting agenda," "meeting culture," "nobody comes prepared," "meetings go nowhere," "how do I decline meetings," "distractions," "focus time," "engineers can't focus," "context switching," "protect engineering time," "review this meeting," or "transcript."
Helps engineering managers plan roadmaps, prioritize work, and communicate priorities effectively — produces the 20% tech debt framework (and its 5 traps), a phased release pressure-test, a maintenance cost model, the Always Green delivery method, sprint anti-patterns, hidden costs of custom features, a critical deadline playbook, the Iron Law of Projects with reference-class forecasting, a "no technical projects" framing, and feature factory warning signs. Use when the user says "roadmap," "quarterly planning," "OKRs," "prioritization," "what should we work on," "planning cycle," "backlog grooming," "stakeholder alignment," "capacity planning," "technical debt," "we're always late," or "leadership doesn't understand engineering work."
Helps engineering managers identify, quantify, and reduce hidden capacity drains that make teams miss commitments even when everyone is busy. Use this skill whenever the user mentions invisible work, untracked work, support requests consuming the team, glue work, shadow backlog, sprint spillover, capacity planning being wrong, teams always underestimating, senior engineers burning out, or "we are busy but nothing ships." Produces a diagnostic, evidence plan, and concrete interventions.
Explains business financial terms and frameworks for engineering managers — produces term definitions (ARR, COGS, CAC, LTV, gross margin, burn rate, EBITDA, AARRR), translation formulas for making engineering work visible in business language, and a three-layer framework for building business credibility. Use when the user says "business terms," "EBITDA," "burn rate," "CAC," "LTV," "gross margin," "ARR," "how do I speak to business people," "I don't understand finance," "make the case for engineering work," "connect engineering to business outcomes," "talk to the P&L owner," or "business impact." Do NOT use when the user wants to connect engineering metrics (DORA, velocity) to business metrics — use developer-productivity instead.
Helps engineering managers understand and act on what drives each engineer — produces a three-driver framework (Growth, Connection, Impact), techniques for identifying someone's primary driver, driver-aligned delegation patterns, and a team composition diagnostic. Use when the user says "this person isn't motivated," "nobody picks up tasks," "I keep reminding people," "what drives my engineers," "how do I motivate my team," "what should I delegate to this person," "engineer seems disengaged," or "what growth activity should I give this person." Do NOT use when someone is actively leaving or at risk of quitting (use retaining-developers) or when the engineer is a high performer with specific management challenges (use managing-high-performers).
Equips engineering managers with persuasion techniques and positioning strategies for getting things done without direct authority — produces tactical methods (Nemawashi, Decoy Pricing, Reverse Psychology, LMDTFY, Engineered Serendipity), conversation techniques for disarming resistance (Label the Concern, Get to "That's Right"), a headcount argument framework, and a three-level visibility/trust model. Use when the user says "how do I convince," "persuade," "get buy-in," "stakeholder management," "influence without authority," "get approval," "calibration," "nobody takes me seriously," "how do I get headcount," or "organizational politics." Do NOT use when the issue is the user's relationship with their own manager (use managing-up).
Helps engineering managers assess and improve team health across morale, cohesion, delivery culture, and engagement — produces Google's 5 Factors (Project Aristotle), a 4-state team health diagnosis (Falling Behind / Treading Water / Repaying Debt / Innovating), a 5-zone intensity model, the Engagement Stack, the Trust Battery, Teamicide patterns (Peopleware), a blameless postmortem format, and a library of team activities organized by driver. Use when the user says "team morale," "team is struggling," "burnout," "engagement," "attrition risk," "psychological safety," "team dynamics," "something feels off," "team culture," "team is unhappy," "retros aren't working," "team isn't working hard enough," "ideas for team activities," or "how do I run a team offsite." Do NOT use for individual performance concerns (use `managing-high-performers`), team staffing or hiring (use `team-composition`), or individual motivation interventions (use `engineer-motivation`).
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`).
Helps diagnose underperformance, structure a performance case, decide whether to put someone on a PIP or let them go, and think through your own manager review. Use when the user says "perf review," "review cycle," "performance calibration," "write a review," "rating," "meets expectations," "performance improvement," "PIP," "promotion case," "end of year review," "mid-year review," "underperformer," "struggling employee," or "should I let them go." Do NOT use for delivering day-to-day feedback (use feedback) or for evaluating a new hire candidate (use hiring).
Helps engineering managers diagnose team skill gaps and make better hiring and assignment decisions — produces the Dungeon Party archetype model (Warrior, Tank, Healer, Wizard, Rogue), the Barrels and Ammunition framework for understanding throughput limits, the Commandos/Infantry/Police phase model, and a minimum team size guideline. Use when the user says "team balance," "what roles do I need," "who should I hire next," "team is missing something," "skill gaps," "team is slow despite headcount," "this person thrived before but struggles now," or "what type of engineer should I hire."
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`).
Helps engineering managers respond to high-urgency requests and use deadlines effectively — produces a five-question framework for evaluating unreasonable deadlines, guidance on scope/staffing/intensity decisions under pressure, Parkinson's Law applied to engineering, and five common deadline mistakes to avoid. Use when the user says "urgent deadline," "everything is on fire," "we need to ship fast," "fake deadline," "unreasonable timeline," "crisis mode," "working weekends," "Parkinson's Law," or "leadership is pushing for faster delivery."
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).
Helps structure the interview process, calibrate the hiring bar, counter interview bias, and decide between promoting internally vs. hiring externally. Also covers evaluating a new hire's fit during their first 90 days. Use when the user says "interview," "hire," "job description," "JD," "interview loop," "debrief," "hiring bar," "offer," "reject," "sourcing," "recruiter," "headcount," "should I hire a junior," "promote from within," or "new hire isn't working out." Do NOT use for ongoing performance management of an established team member (use performance-reviews).
Helps engineering managers break down knowledge silos and build sustainable documentation and collaboration practices — produces a four-root-cause diagnostic for silos, an Engineering Guilds framework, a minimum-viable documentation approach using ADRs, a structured onboarding model, and a cross-team request decision framework. Use when the user says "knowledge silos," "reinventing the wheel," "nobody reads docs," "onboarding is bad," "teams don't talk," "documentation culture," "cross-team friction," "information doesn't flow," or "new hires struggle to ramp up."
--- name: em-context description: Foundation skill for engineering managers. Use when setting up context about your team, org structure, management philosophy, and current priorities. All other EM skills read this first. Also use when creating or updating a direct report profile. Trigger phrases: "set my team context," "update my EM context," "here's my team setup," "my team is," "my org is," "add a report," "update report profile," "create a profile for." metadata: version: 1.3.0 --- # EM Co
Helps engineering managers navigate role transitions — produces a four-type framework for first management roles (Apprentice, Successor, Pioneer, New Boss), an acquisition integration model, guidance for counseling engineers on the management track, a Blue Tape List method for new roles, a broken team turnaround process, and the Dopamine Shift framing for new managers. Use when the user says "new manager," "first management role," "took over a team," "managing former peers," "new team," "just became a manager," "inherited a team," "starting fresh as a manager," "second time as manager," "acquisition integration," or "should my engineer become a manager."
Prepares agendas, diagnoses struggling 1:1 relationships, and gives frameworks for running effective 1:1 meetings with direct reports. Use when the user wants to prepare for, run, improve, or follow up on a 1:1, or says "1:1 agenda," "prepare for my 1:1," "1:1 notes," "what should I talk about with," "my direct report," "check in with my report," "make my 1:1s better," "1:1 template," or "my 1:1s feel like status updates." Do NOT use when the user needs to deliver specific feedback (use feedback) or discuss performance reviews (use performance-reviews).