skills/career-development/SKILL.md
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.
npx skillsauth add manager-dot-dev/manager-skills career-developmentInstall 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:
.agents/em-context.md if it exists.agents/reports/[name].md — it may contain their level, goals, and growth historyIf .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:
When helping with career development, produce a manager-ready plan:
Do not promise promotion. Separate "ready to grow" from "the organization has a slot and evidence."
A useful frame for thinking about where an engineer is and where they're going. Impact expands in concentric circles:
Personal — Masters their own craft. Delivers reliable results. Writes good code, handles on-call, completes tasks well. This is the foundation.
Team — Makes the team better. Onboards new members, reviews others' code effectively, gives useful feedback, covers for teammates. Their absence would be felt on the team.
Group — Shapes cross-team work. Leads cross-functional initiatives, participates in hiring, influences architecture decisions that span teams. Their impact reaches beyond their immediate team.
Company — Drives org-wide outcomes. Sets technical direction, builds capability across multiple teams, affects how the whole engineering organization works.
How to use this in career conversations:
A Senior engineer who writes excellent code but never helps teammates grow is strong at the Personal circle but hasn't entered the Team circle. That's the gap to address, not more technical depth.
Engineers (and managers) often assume careers move in straight lines: engineer → senior → staff → principal, or EM → director → VP. This leads to fixating on the fastest route up a single ladder.
The reality: senior roles require both capability AND company need. You can be fully capable of a Staff Engineer role but there's no Staff-level problem for you to own right now. The role has to exist and need filling at the moment you're ready for it.
The Tarzan model: swing to the next vine, not to the destination. Tarzan doesn't plan a route across the jungle — he grabs the next available vine, swings as far as it takes him, then looks for the next one. Careers work the same way.
Practical implications for career conversations with reports:
Growth isn't a continuous line — it comes in bursts separated by consolidation periods. Signs an engineer is growing:
Signs growth has stalled (and what to do):
Career development conversations are uncomfortable for a lot of managers because they feel high-stakes. Some principles:
Ask before advising. "What does growth look like for you in the next year?" beats "here's what I think you should work on." You'll often get a much clearer picture of what they actually want, which may differ significantly from what you assumed.
Separate "what they want" from "what the company needs." Be honest when these aren't aligned. If someone wants to move into a Staff role but the team doesn't have Staff-level problems, say so — and help them think through what that means (a different team, a different company, a different timeframe).
Be specific about the gap. "You need to show more leadership" is useless. "The gap I see is that you're not yet driving alignment with the PM and design on your projects — you're still waiting for requirements rather than shaping them" is something they can act on.
Document it. After a career conversation, write down what was discussed and share it with the report. Memory is unreliable. A written note creates shared accountability.
Two separate questions that managers often conflate:
Is this person ready for promotion? — Are they consistently operating at the next level? Do they have a track record of impact at that level, not just occasional moments?
Is now the right time to push the case? — Is there headcount/budget for a promotion? Is the calibration cycle coming up? Do you have enough documented evidence? Is the person visible enough to the people who will weigh in?
Both have to be true. Pushing someone for promotion before they're ready damages your credibility and can actually set them back. Waiting too long after they're ready damages trust and risks losing them.
The rule: start building the promotion case while the person is still being developed — document impact, get visibility, prepare specific examples. Don't scramble at calibration time.
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.
1on1s — The primary venue for ongoing career conversationsperformance-reviews — Promotion cases are made at review time; the groundwork is laid heremanaging-high-performers — High performers need growth challenges to stay engagedmanagement-transitions — Counseling engineers on whether management is the right pathtesting
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`).