{ "schemaVersion": "1.0", "item": { "slug": "afrexai-engineering-manager", "name": "Engineering Manager OS", "source": "tencent", "type": "skill", "category": "开发工具", "sourceUrl": "https://clawhub.ai/1kalin/afrexai-engineering-manager", "canonicalUrl": "https://clawhub.ai/1kalin/afrexai-engineering-manager", "targetPlatform": "OpenClaw" }, "install": { "downloadMode": "redirect", "downloadUrl": "/downloads/afrexai-engineering-manager", "sourceDownloadUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=afrexai-engineering-manager", "sourcePlatform": "tencent", "targetPlatform": "OpenClaw", "installMethod": "Manual import", "extraction": "Extract archive", "prerequisites": [ "OpenClaw" ], "packageFormat": "ZIP package", "includedAssets": [ "README.md", "SKILL.md" ], "primaryDoc": "SKILL.md", "quickSetup": [ "Download the package from Yavira.", "Extract the archive and review SKILL.md first.", "Import or place the package into your OpenClaw setup." ], "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Then review README.md for any prerequisites, environment setup, or post-install checks. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Then review README.md for any prerequisites, environment setup, or post-install checks. Summarize what changed and any follow-up checks I should run." } ] }, "sourceHealth": { "source": "tencent", "status": "healthy", "reason": "direct_download_ok", "recommendedAction": "download", "checkedAt": "2026-04-30T16:55:25.780Z", "expiresAt": "2026-05-07T16:55:25.780Z", "httpStatus": 200, "finalUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=network", "contentType": "application/zip", "probeMethod": "head", "details": { "probeUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=network", "contentDisposition": "attachment; filename=\"network-1.0.0.zip\"", "redirectLocation": null, "bodySnippet": null }, "scope": "source", "summary": "Source download looks usable.", "detail": "Yavira can redirect you to the upstream package for this source.", "primaryActionLabel": "Download for OpenClaw", "primaryActionHref": "/downloads/afrexai-engineering-manager" }, "validation": { "installChecklist": [ "Use the Yavira download entry.", "Review SKILL.md after the package is downloaded.", "Confirm the extracted package contains the expected setup assets." ], "postInstallChecks": [ "Confirm the extracted package includes the expected docs or setup files.", "Validate the skill or prompts are available in your target agent workspace.", "Capture any manual follow-up steps the agent could not complete." ] }, "downloadPageUrl": "https://openagent3.xyz/downloads/afrexai-engineering-manager", "agentPageUrl": "https://openagent3.xyz/skills/afrexai-engineering-manager/agent", "manifestUrl": "https://openagent3.xyz/skills/afrexai-engineering-manager/agent.json", "briefUrl": "https://openagent3.xyz/skills/afrexai-engineering-manager/agent.md" }, "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Then review README.md for any prerequisites, environment setup, or post-install checks. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Then review README.md for any prerequisites, environment setup, or post-install checks. Summarize what changed and any follow-up checks I should run." } ] }, "documentation": { "source": "clawhub", "primaryDoc": "SKILL.md", "sections": [ { "title": "Engineering Manager Operating System", "body": "Your complete playbook for engineering leadership. Not generic management advice — this is the specific system that high-performing engineering managers run daily." }, { "title": "Team Topology Assessment", "body": "Before managing people, understand the system they work in.\n\nteam_topology:\n name: \"[Team Name]\"\n type: stream-aligned | platform | enabling | complicated-subsystem\n mission: \"[One sentence — what does this team exist to do?]\"\n boundaries:\n owns: [\"service-x\", \"domain-y\", \"pipeline-z\"]\n consumes: [\"auth-service\", \"data-platform\"]\n provides: [\"checkout-api\", \"payment-events\"]\n cognitive_load: low | medium | high | overloaded\n interaction_modes:\n - team: \"[Other Team]\"\n mode: collaboration | x-as-a-service | facilitating\n friction: low | medium | high\n notes: \"[What's working/not working]\"\n current_headcount: N\n ideal_headcount: N\n skill_gaps: [\"observability\", \"mobile\", \"ML\"]" }, { "title": "Team Health Radar (Monthly)", "body": "Score 1-5 for each dimension. Track trends over time.\n\nDimensionScoreSignalDelivery pace_ /5Are we shipping what we committed?Quality_ /5Bug rate, incident frequency, tech debt trajectoryCollaboration_ /5Cross-functional work, PR review speed, knowledge sharingMorale_ /5Energy in meetings, voluntary contributions, retention signalsLearning_ /5New skills adopted, conference talks, internal tech talksAutonomy_ /5Can the team make decisions without waiting for me?Psychological safety_ /5Do people raise concerns, admit mistakes, challenge ideas?On-call health_ /5Page frequency, off-hours burden, burnout signals\n\nAction rules:\n\nAny dimension ≤2 → Address THIS WEEK (it's a fire)\nAny dimension at 3 → Create improvement plan within 2 weeks\nOverall average <3.5 → Team is struggling, block new commitments until fixed\nTrack quarter-over-quarter — sustained decline in any dimension = systemic issue" }, { "title": "Team Composition Model", "body": "The ideal team has these roles covered (not necessarily 1:1 with people):\n\nRoleDescriptionGap ImpactTech leadArchitecture decisions, code quality barDecisions bottleneck through youSenior IC (2-3)Carry complex work, mentor juniorsVelocity drops, quality suffersMid-level (2-3)Reliable delivery, growing scopeNo bench for senior pipelineJunior (0-2)Learning, fresh perspectiveNo talent pipelineDomain expertDeep knowledge of the problem spaceConstantly solving wrong problems\n\nRule of thumb: Never have >60% of team at same level. Mix creates natural mentorship." }, { "title": "1:1 Cadence", "body": "Report LevelFrequencyDurationFocusDirect reportsWeekly30 minCareer + blockers + feedbackSkip-levelsMonthly30 minTeam health + career + honesty checkYour managerWeekly30 minPriorities + asks + air coverCross-functional peersBi-weekly25 minDependencies + alignment" }, { "title": "1:1 Template (Direct Reports)", "body": "one_on_one:\n date: \"YYYY-MM-DD\"\n person: \"[Name]\"\n role: \"[Title]\"\n tenure: \"[X months on team]\"\n \n # Their agenda first — ALWAYS\n their_topics: []\n \n # Check-in (2 min)\n energy_level: 1-10 # \"How are you feeling about work this week?\"\n energy_trend: up | stable | down\n \n # Delivery (5 min)\n current_work: \"[What they're working on]\"\n blockers: []\n help_needed: \"[What can I unblock?]\"\n \n # Growth (10 min — skip if urgent topics dominate, but never 3 weeks in a row)\n career_conversation: \"[Topic discussed]\"\n feedback_given: \"[Specific behavior → impact → request]\"\n feedback_received: \"[What they told me]\"\n stretch_opportunity: \"[Current or upcoming]\"\n \n # Action items\n my_actions: [] # What I committed to do\n their_actions: [] # What they committed to do\n \n # Signals (private — don't share these)\n flight_risk: low | medium | high\n performance_trajectory: improving | stable | declining\n notes: \"[Anything notable]\"" }, { "title": "1:1 Question Bank", "body": "Opening (rotate these — never use the same opener 3 weeks in a row):\n\n\"What's on your mind?\"\n\"What was the best/worst part of your week?\"\n\"If you could change one thing about how we work, what would it be?\"\n\"What's something you're proud of from this week that I might not know about?\"\n\"On a scale of 1-10, how's your energy? What would move it up one point?\"\n\nCareer development (monthly deep-dive):\n\n\"Where do you want to be in 2 years? What's the gap between here and there?\"\n\"What skills are you not using that you'd like to use more?\"\n\"Who in the org (or industry) has a role you'd want? What specifically about it?\"\n\"What's the hardest technical problem you've solved recently? What did you learn?\"\n\"If you left tomorrow, what would you regret not doing here?\"\n\nTeam health (probe with care):\n\n\"Who on the team do you learn the most from? The least?\"\n\"Is there anyone whose work you don't trust to review?\"\n\"What's something the team avoids talking about?\"\n\"If you were me, what would you change about how this team operates?\"\n\nFeedback solicitation (for YOU):\n\n\"What's one thing I could do differently that would help you most?\"\n\"Am I giving you too much direction or too little?\"\n\"Is there context I have that I'm not sharing that would help you?\"\n\"When was the last time I frustrated you? What happened?\"" }, { "title": "Flight Risk Detection", "body": "Monitor these signals — if 3+ present, have a retention conversation within a week:\n\nSignalWeightDetectionLinkedIn profile update🔴 HighSomeone mentions it, or you noticeDeclining 1:1 engagement🔴 HighShorter answers, less eye contact, \"everything's fine\"Stopped volunteering for projects🟡 MediumUsed to raise hand, now doesn'tIncreased PTO without travel🟡 MediumInterviewing signalDisengaged in meetings🟡 MediumCamera off, multitasking, no opinionsComplaining shifted from specific to general🟡 Medium\"This sprint is rough\" → \"This place...\"Stopped arguing for their ideas🔴 HighThey've mentally checked outLife event (new baby, move, partner change)🟡 MediumRe-evaluating everything\n\nRetention conversation framework:\n\nName it: \"I've noticed [specific behavior change]. I want to check in.\"\nListen: Let them talk. Don't interrupt. Don't get defensive.\nUnderstand: \"What would make this the best job you've ever had?\"\nAct: Make a concrete commitment within 48 hours — title, comp, scope, flexibility\nFollow up: Check back in 1 week. Did what you promised make a difference?" }, { "title": "Performance Calibration Framework", "body": "Rate on two axes (both matter):\n\nDelivery Impact (What)\n\nLevelDescription1 - BelowMissing commitments, quality issues, needs close oversight2 - MeetingDelivering assigned work reliably3 - ExceedingDelivering beyond scope, finding better solutions4 - OutstandingMultiplying team output, solving problems no one asked them to\n\nBehaviors (How)\n\nLevelDescription1 - BelowCreating friction, not collaborating, ignoring feedback2 - MeetingProfessional, collaborative, receptive to feedback3 - ExceedingMentoring others, proactively improving processes4 - OutstandingShaping culture, attracting talent, raising the entire bar\n\nCalibration matrix:\n\nBehavior 1Behavior 2Behavior 3Behavior 4Delivery 4Coach behaviorsStrongTop performerSuperstarDelivery 3Coach behaviorsSolidStrongTop performerDelivery 2PIP candidateMeets expectationsDevelopingGrowingDelivery 1ExitPIPCoach deliveryCoach delivery" }, { "title": "Feedback Framework: SBI-I (Situation-Behavior-Impact-Intent)", "body": "Template:\n\"In [situation], when you [specific behavior], the impact was [concrete effect]. I'd like to see [specific change] because [intent/why it matters].\"\n\nExamples:\n\n✅ Good: \"In yesterday's design review, when you challenged the API schema with the versioning concern, it caught a breaking change we would have shipped. That's exactly the kind of technical leadership I want to see more of.\"\n\n❌ Bad: \"You're doing great work. Keep it up.\" (Too vague — they learn nothing)\n\n✅ Good: \"In the last two sprints, PRs have been sitting in review for 3+ days. The impact is features are merging late and we're missing sprint commitments. I'd like us to commit to <24h first review because velocity depends on review speed.\"\n\n❌ Bad: \"You need to review PRs faster.\" (No situation, no impact, no collaboration)" }, { "title": "Performance Improvement Plan (PIP) Template", "body": "pip:\n employee: \"[Name]\"\n role: \"[Title]\"\n manager: \"[Your name]\"\n start_date: \"YYYY-MM-DD\"\n end_date: \"YYYY-MM-DD\" # 30-60 days, never >90\n \n context: |\n [Specific pattern of underperformance with dates and examples.\n Must reference prior feedback conversations and dates they occurred.]\n \n expectations:\n - area: \"[Specific skill/behavior]\"\n current_state: \"[What's happening now — with examples]\"\n target_state: \"[What success looks like — measurable]\"\n measurement: \"[How we'll measure — PR metrics, sprint completion, etc.]\"\n support: \"[What I'll provide — pairing, training, reduced scope]\"\n \n check_ins:\n frequency: weekly\n day: \"[Day]\"\n format: \"[30 min 1:1 with written summary]\"\n \n outcomes:\n success: \"[What happens if targets met — return to normal performance management]\"\n failure: \"[What happens if targets not met — typically termination]\"\n \n # CRITICAL: Have HR review before sharing. Document every check-in.\n hr_reviewed: false\n hr_reviewer: \"[Name]\"\n\nPIP rules:\n\nA PIP should never be a surprise — if it is, YOU failed at feedback\nPIPs are for capability gaps, not attitude problems (attitude = manage out faster)\n70% of PIPs end in termination — be honest with yourself about whether this is a development tool or a documentation exercise\nWeekly check-ins are non-negotiable — document everything in writing\nIf performance improves during PIP then declines after: second PIP is rarely worth it" }, { "title": "Promotion Case Template", "body": "promotion_case:\n candidate: \"[Name]\"\n current_level: \"[Level]\"\n target_level: \"[Level]\"\n manager: \"[Your name]\"\n date: \"YYYY-MM-DD\"\n \n # Already operating at next level (past 6+ months)\n evidence:\n - dimension: \"Technical complexity\"\n examples:\n - \"[Specific project/decision with measurable impact]\"\n - \"[Another example]\"\n - dimension: \"Scope & ownership\"\n examples:\n - \"[Owned X end-to-end, previously needed guidance]\"\n - dimension: \"Influence & leadership\"\n examples:\n - \"[Mentored Y, led Z initiative, shaped team direction]\"\n - dimension: \"Business impact\"\n examples:\n - \"[Revenue/efficiency/reliability improvement with numbers]\"\n \n peer_feedback:\n - from: \"[Name, role]\"\n quote: \"[Specific praise with examples]\"\n \n # Why now, not 6 months from now?\n timing_justification: |\n [They've been consistently operating at next level for X months.\n Delaying creates retention risk and sends wrong signal to team.]\n \n # What's the gap? (Be honest — calibration committees will find it)\n growth_areas: |\n [Areas they're still developing. Frame as \"growing into\" not \"lacking.\"]" }, { "title": "Hiring Pipeline", "body": "Role opened → Job description → Sourcing (5-7 days)\n→ Resume screen → Recruiter screen (30 min)\n→ Technical phone screen (60 min) → Take-home OR live coding (2-4 hrs)\n→ Onsite/virtual loop (3-4 hrs) → Debrief → Offer → Close\n\nTarget: <21 days from first screen to offer" }, { "title": "Job Description Template", "body": "# [Role Title] — [Team Name]\n\n## What you'll do\n[3-5 bullet points of ACTUAL work, not generic responsibilities]\n- Ship [specific feature/system] that [specific impact]\n- Own [specific domain] end-to-end\n- [Concrete example of a recent problem this person would solve]\n\n## What you'll need\n[Must-haves only — each one must be a genuine filter]\n- X years building [specific technology/domain]\n- Experience with [specific technical requirement]\n- [Skill that actually differentiates candidates]\n\n## Nice to have (genuinely nice, not secretly required)\n- [Thing that would accelerate ramp-up]\n- [Adjacent skill that adds value]\n\n## What we offer\n[Be specific — \"competitive salary\" means nothing]\n- Salary range: $X-$Y (based on [location/level])\n- [Specific benefits that matter to engineers]\n- [Team/culture thing that's actually true and differentiating]\n\n## How we hire\n[Timeline and what to expect — respect their time]\n1. [Step]: [Duration] — [What we're assessing]\n2. [Step]: [Duration] — [What we're assessing]\nTotal time investment: ~X hours" }, { "title": "Interview Scorecard (Per Interviewer)", "body": "scorecard:\n candidate: \"[Name]\"\n interviewer: \"[Name]\"\n interview_type: \"technical | system design | behavioral | culture\"\n date: \"YYYY-MM-DD\"\n \n # Score each dimension 1-4 (no 3s allowed — forces a decision)\n dimensions:\n - name: \"Technical depth\"\n score: _ # 1=no hire, 2=lean no, 4=lean yes, 5=strong yes (skip 3)\n evidence: \"[Specific examples from the interview]\"\n - name: \"Problem solving approach\"\n score: _\n evidence: \"[How they broke down the problem, handled hints]\"\n - name: \"Communication clarity\"\n score: _\n evidence: \"[Could they explain their thinking? Did they ask good questions?]\"\n - name: \"Collaboration signals\"\n score: _\n evidence: \"[How did they respond to pushback? Did they build on ideas?]\"\n \n # Overall\n hire_recommendation: strong_no | no | yes | strong_yes\n level_recommendation: \"[What level would you place them?]\"\n concerns: \"[Anything that gave you pause]\"\n highlights: \"[What impressed you most]\"" }, { "title": "Debrief Protocol", "body": "No pre-discussion — Submit scorecards BEFORE the debrief meeting\nHire bar holder speaks last — Prevent anchoring\nDiscuss each dimension, not overall vibes — \"Tell me about their system design approach\" not \"What did you think?\"\nAny strong_no is a veto — Unless the interviewer can be convinced their signal was a misread\nDecide in the room — Don't \"sleep on it\" unless genuinely torn (then it's probably a no)\nLeveling before offer — Agree on level first, then comp follows from band" }, { "title": "Closing Candidates", "body": "The 3 things that close engineers:\n\nThe problem — \"Here's the specific hard problem you'd work on\"\nThe people — Connect them with future teammates before offer\nThe growth — \"Here's where this role leads in 18 months\"\n\nOffer call structure (15-20 min):\n\nExpress genuine excitement (2 min)\nPresent offer details — base, equity, bonus, start date (3 min)\nExplain equity/comp philosophy (3 min)\nAsk: \"How does this compare to what you were expecting?\" (listen)\nAddress concerns immediately if possible\nSet a decision deadline (3-5 business days, not open-ended)\nAsk: \"Is there anything that would make this a clear yes?\"" }, { "title": "Architecture Decision Record (ADR)", "body": "adr:\n id: \"ADR-NNN\"\n title: \"[Decision title]\"\n date: \"YYYY-MM-DD\"\n status: proposed | accepted | deprecated | superseded\n superseded_by: \"ADR-NNN\" # if applicable\n \n context: |\n [What situation are we in? What forces are at play?\n Include constraints: timeline, team skill, budget, scale requirements.]\n \n options:\n - name: \"[Option A]\"\n pros: [\"pro 1\", \"pro 2\"]\n cons: [\"con 1\", \"con 2\"]\n effort: \"[T-shirt size]\"\n risk: low | medium | high\n - name: \"[Option B]\"\n pros: [\"pro 1\"]\n cons: [\"con 1\", \"con 2\", \"con 3\"]\n effort: \"[T-shirt size]\"\n risk: low | medium | high\n \n decision: |\n [What we decided and WHY. The \"why\" is the most important part.\n Future readers need to understand the reasoning, not just the choice.]\n \n consequences: |\n [What follows from this decision? What becomes easier/harder?\n What do we need to monitor?]\n \n review_date: \"YYYY-MM-DD\" # When to revisit this decision" }, { "title": "Tech Debt Prioritization", "body": "Score each debt item on two axes:\n\nImpact of fixing (1-5):\n\n5: Unblocks multiple teams or critical features\n4: Significant velocity improvement for our team\n3: Moderate improvement, prevents future problems\n2: Nice to have, minor improvement\n1: Cosmetic or theoretical benefit\n\nCost of NOT fixing (1-5):\n\n5: Will cause incidents or data loss\n4: Blocking hiring/onboarding (can't explain the code)\n3: Slowing every feature by >20%\n2: Occasional friction, workarounds exist\n1: Annoying but harmless\n\nPriority = Impact × Cost-of-not-fixing\n\nScoreAction20-25Fix THIS sprint — it's an emergency12-19Schedule within 2 sprints6-11Add to quarterly tech debt budget (allocate 15-20% of sprint capacity)1-5Backlog — revisit quarterly" }, { "title": "Code Review Culture Guidelines", "body": "code_review_standards:\n sla:\n first_review: \"< 4 hours during work hours\"\n follow_up: \"< 2 hours\"\n max_pr_size: 400 # lines changed — larger needs pre-review or splitting\n \n what_to_review:\n always:\n - \"Correctness — does it do what it claims?\"\n - \"Edge cases — what happens with nil/empty/max/concurrent?\"\n - \"Security — auth checks, input validation, secrets exposure\"\n - \"Naming — will someone understand this in 6 months?\"\n sometimes:\n - \"Performance — only if in hot path or O(n²)+ risk\"\n - \"Style — only if it significantly hurts readability\"\n never:\n - \"Personal preference disguised as improvement\"\n - \"Premature optimization suggestions\"\n - \"Rewriting working code to your style\"\n \n tone_rules:\n - \"Ask questions instead of making demands: 'What happens if X is nil?' not 'Handle the nil case'\"\n - \"Prefix opinion with 'nit:' or 'optional:' — make severity clear\"\n - \"Praise good code — 'Nice abstraction here' costs nothing\"\n - \"If >5 comments, offer to pair instead\"\n - \"Approve with comments when nothing is blocking — trust your team\"" }, { "title": "Sprint Ceremony Cheat Sheet", "body": "CeremonyDurationWhoPurposeYour RoleSprint planning1-2 hrsTeam + POCommit to sprint goalFacilitate, challenge estimates, protect capacityDaily standup15 minTeamSurface blockersListen for problems, DON'T manage tasksBacklog refinement1 hrTeam + POPrepare future workEnsure technical feasibility, flag risksSprint review30 minTeam + stakeholdersDemo working softwareLet the team present, handle stakeholder QsRetrospective1 hrTeam onlyImprove processFacilitate, ensure psychological safety, track actions" }, { "title": "Sprint Health Metrics", "body": "Track these weekly — trend matters more than absolute numbers:\n\nMetricHealthy RangeRed FlagSprint completion rate80-100% of committed points<70% for 2+ sprintsCarry-over stories0-1 per sprintSame story carried 3+ sprintsPR cycle time<48 hours open to merge>72 hours consistentlyBug escape rate<10% of stories create bugsRising trendDeployment frequencyDaily to weeklyMonthly or lessSprint goal achievementYes/No binaryNo for 3+ consecutive sprints" }, { "title": "Estimation Heuristic", "body": "When the team struggles with estimation:\n\nCertainty LevelApproach\"We've done this exact thing before\"Size by comparison to past work\"We understand the problem but not the solution\"Spike first (timeboxed), then estimate\"We don't fully understand the problem\"Discovery task (1-2 days), then re-scope\"We have no idea\"Break it down until you reach pieces you can estimate\n\nRule: If an estimate is >8 points (or >5 days), it's not estimated — it's a guess. Break it down further." }, { "title": "Incident Response Framework", "body": "incident:\n id: \"INC-YYYY-NNN\"\n severity: SEV1 | SEV2 | SEV3 | SEV4\n detected: \"YYYY-MM-DD HH:MM UTC\"\n resolved: \"YYYY-MM-DD HH:MM UTC\"\n duration: \"Xh Ym\"\n commander: \"[Name]\"\n \n # Severity guide\n # SEV1: Revenue impact, data loss, full outage — ALL HANDS, exec notification\n # SEV2: Degraded service, partial outage — On-call + team lead\n # SEV3: Minor degradation, workaround exists — On-call handles\n # SEV4: Cosmetic, no user impact — Normal ticket\n \n timeline:\n - time: \"HH:MM\"\n action: \"[What happened / what was done]\"\n who: \"[Name]\"\n \n root_cause: |\n [Technical root cause — be specific. \n \"Human error\" is never the root cause. What system allowed the error?]\n \n contributing_factors:\n - \"[Factor 1 — e.g., missing monitoring on X]\"\n - \"[Factor 2 — e.g., deployment during peak without feature flag]\"\n \n action_items:\n - description: \"[Specific fix]\"\n owner: \"[Name]\"\n due_date: \"YYYY-MM-DD\"\n priority: P0 | P1 | P2\n status: open | in_progress | done" }, { "title": "Blameless Post-Mortem Template", "body": "Facilitation rules:\n\nFocus on systems, not individuals\n\"What\" and \"how,\" never \"who\"\nEveryone involved attends (including on-call who was paged)\nSchedule within 48 hours of resolution (memories fade)\nWrite it up and share publicly within the engineering org\n\nStructure (60-90 min):\n\nTimeline review (20 min) — Walk through chronologically. Fill gaps.\nRoot cause analysis (15 min) — \"5 Whys\" until you hit a systemic issue\nWhat went well (10 min) — Reinforce good incident response behaviors\nWhat went wrong (15 min) — Process failures, detection gaps, communication issues\nAction items (15 min) — Each must have an owner and due date. Max 5 items — focus beats volume." }, { "title": "On-Call Health Guidelines", "body": "MetricHealthyUnhealthyPages per week<5>10Off-hours pages<2/week>5/weekTime to acknowledge<5 min>15 minFalse positive rate<20%>50%Rotation size4+ people<3 peopleConsecutive weeks on-callNever >2Regular 3+ week stretches\n\nIf on-call is unhealthy: This is a tech debt problem, not a people problem. Invest in reliability before adding headcount." }, { "title": "When to Split a Team", "body": "SignalActionTeam >8 peopleSplit before communication overhead kills velocityTwo distinct domains in one teamSplit along domain boundariesStandup takes >15 minToo many threads — people are tuning outPR review queue >48 hours consistentlyNot enough context overlap — specializeOn-call covers too many servicesReduce blast radius per team" }, { "title": "Splitting Protocol", "body": "Define boundaries clearly — What does each new team OWN? Write it down.\nSplit the backlog — Every ticket gets a home. Shared backlogs = shared ownership = no ownership.\nSplit on-call — Each team owns their services' reliability.\nName the teams — Sounds trivial, matters for identity.\nDesignate tech leads — Don't leave both teams looking to you for technical decisions.\nGive it 3 months — Resist re-orging again too quickly. Turbulence is normal." }, { "title": "Manager-to-IC Ratio", "body": "Team SizeStructure3-5 ICsPlayer-coach (you're still coding ~30-40%)5-8 ICsFull-time manager (stop coding in critical path)8-12 ICsSplit the team OR add a tech lead as force multiplier12+ ICsMust split — you cannot manage this effectively" }, { "title": "The IC-to-Manager Transition", "body": "If you're newly managing (or coaching someone through it):\n\nStop doing:\n\nWriting code in the critical path (you're now the bottleneck)\nSolving every technical problem yourself\nBeing the best engineer on the team (your job changed)\n\nStart doing:\n\nAsking \"who should own this?\" instead of doing it yourself\nMeasuring success by team output, not your output\nHaving uncomfortable conversations early (feedback, performance, conflict)\nBlocking time for thinking, not just meetings\n\nKeep doing:\n\nStaying technical enough to evaluate decisions (read code, review designs)\nCoding on side projects, tools, or prototypes (stay sharp)\nHaving strong technical opinions (but hold them loosely)\n\nTimeline to competence:\n\nMonth 1-3: Imposter syndrome, everything feels slow. Normal.\nMonth 3-6: Finding your rhythm, some wins, some failures. Normal.\nMonth 6-12: Confident in the role, building systems. Target.\nMonth 12+: Multiplying impact. If you're not here by month 18, honest conversation needed." }, { "title": "Weekly Status Update Template", "body": "Send this to your manager and stakeholders every Friday:\n\n# [Team Name] — Week of [Date]\n\n## 🎯 Sprint Goal: [Goal] — On Track / At Risk / Off Track\n\n## ✅ Shipped This Week\n- [Feature/fix] — [Impact in user/business terms]\n- [Feature/fix] — [Impact]\n\n## 🔨 In Progress\n- [Work item] — [Status, ETA, any blockers]\n\n## 🚨 Risks & Blockers\n- [Risk] — [What you're doing about it, what you need]\n\n## 📊 Key Metrics\n- Deploy frequency: X\n- Incident count: X (SEV breakdown)\n- Sprint completion: X%\n\n## 🔮 Next Week\n- [Priority 1]\n- [Priority 2]" }, { "title": "Managing Up Checklist", "body": "DoDon'tBring solutions with problemsDump problems without proposalsFlag risks early with mitigation plansSurprise with bad news at the last minuteQuantify impact (hours, $$, users)Use vague language (\"it's kinda slow\")Say \"I need X from you by Y\"Hope they'll figure out you need helpSend written updates proactivelyWait to be asked for statusDisagree in privateDisagree in public meetingsAsk for feedback regularlyAssume no news is good news" }, { "title": "Cross-Functional Relationship Map", "body": "stakeholders:\n - name: \"[Product Manager]\"\n relationship: partner\n cadence: \"Daily async + weekly 1:1\"\n currency: \"Scope clarity, user data, priority decisions\"\n \n - name: \"[Design Lead]\"\n relationship: partner\n cadence: \"Bi-weekly sync + ad-hoc\"\n currency: \"Early technical feasibility input\"\n \n - name: \"[Platform/Infra Team]\"\n relationship: dependency\n cadence: \"Monthly sync + Slack\"\n currency: \"Clear requirements, advance notice of needs\"\n \n - name: \"[Your Manager]\"\n relationship: air_cover\n cadence: \"Weekly 1:1\"\n currency: \"No surprises, clear asks, good judgment\"" }, { "title": "Daily (15 min total)", "body": "Scan Slack/email for blockers — unblock before standup\n Attend standup — listen for patterns, not task updates\n Check PR queue — nudge any >24h reviews\n One piece of feedback (positive or constructive) to someone" }, { "title": "Weekly", "body": "All 1:1s completed (never cancel — reschedule if needed)\n Sprint metrics reviewed\n Status update sent to stakeholders\n Calendar audit — am I in meetings I shouldn't be in?\n One skip-level or cross-functional conversation" }, { "title": "Monthly", "body": "Team health radar updated\n Career development conversation with each report\n Tech debt review and prioritization\n On-call health review\n Update team topology doc" }, { "title": "Quarterly", "body": "Performance calibration (formal or informal)\n Team goals review and reset\n Architecture review — any ADRs need revisiting?\n Headcount planning — what do we need in 6 months?\n Retrospective on YOUR performance — ask your team for feedback" }, { "title": "Scenario: Two Senior Engineers Disagree on Architecture", "body": "Let them present both approaches in a design doc (each writes their own section)\nDefine decision criteria BEFORE evaluating: reversibility, maintenance cost, team familiarity, timeline\nFacilitate a time-boxed discussion (60 min max)\nIf no consensus: the tech lead or DRI decides. Not you (unless you must).\nDocument the decision as an ADR — the \"why\" matters more than the \"what\"\nThe person who \"lost\" must commit fully. Monitor for passive resistance." }, { "title": "Scenario: High Performer Wants to Be a Manager", "body": "Explore motivation: \"Tell me what you think a manager does day-to-day\"\nTest with real work: lead a project, mentor a junior, run a retrospective\nBe honest about tradeoffs: less coding, more meetings, slower feedback loops, ambiguous success metrics\nOffer the Staff/Principal IC path as a genuine alternative, not a consolation prize\nIf they proceed: set explicit check-in at 3 months — \"Is this what you wanted?\"" }, { "title": "Scenario: You Inherit a Low-Performing Team", "body": "Week 1-2: Listen. 1:1 with every person. Don't change anything yet.\nWeek 3-4: Identify the 1-2 systemic issues (usually: unclear priorities, no accountability, or trust deficit)\nMonth 2: Make ONE process change. Get a quick win. Build credibility.\nMonth 3: Address performance issues you've now observed firsthand\nNever: Blame the previous manager publicly. Never say \"things are going to change around here.\"" }, { "title": "Scenario: Layoffs / Reorg Affecting Your Team", "body": "Before announcement: Prepare a plan for remaining team — who covers what?\nDuring: Be honest about what you know and what you don't. \"I don't know\" > corporate-speak.\nAfter: 1:1 with every remaining person within 48 hours. Expect anger, fear, guilt.\nOngoing: Workload audit — don't expect same output from fewer people. Push back on scope.\nSelf-care: This is one of the hardest parts of the job. Talk to your own manager or a coach." }, { "title": "Scenario: Your Best Engineer Gives Notice", "body": "Same day: Have a real conversation. Not a counteroffer — understand why.\nIf it's about money: Match or beat if they're worth it. If your company won't, that tells you something.\nIf it's about growth/role: Can you create what they want? Be honest if you can't.\nIf they're leaving for the right reasons: Celebrate them. Write a recommendation. Don't make it weird.\nImmediately: Start knowledge transfer plan. Identify what only they know.\nTo the team: Transparent but positive. \"X is leaving for a great opportunity. Here's our transition plan.\"" }, { "title": "Scoring Rubric: Engineering Manager Effectiveness (0-100)", "body": "DimensionWeightIndicatorsTeam health20%Retention, engagement scores, psychological safety signalsDelivery20%Sprint completion, quality metrics, stakeholder satisfactionPeople development20%Promotions, skill growth, 1:1 quality, mentorshipTechnical stewardship15%Tech debt trajectory, architecture quality, incident trendsHiring10%Pipeline health, offer acceptance rate, new hire ramp timeCommunication10%Stakeholder relationships, information flow, no surprisesSelf-improvement5%Seeking feedback, adapting, growing as a leader\n\nScoring:\n\n90-100: Exceptional — team thriving, people growing, shipping reliably\n75-89: Strong — most things working, some areas to develop\n60-74: Developing — foundational skills present, needs coaching\n40-59: Struggling — significant gaps, at risk of losing team trust\n<40: Intervention needed — coaching, role change, or transition" }, { "title": "Natural Language Commands", "body": "\"Prepare 1:1 with [name]\" → Generate agenda from recent context\n\"Write performance review for [name]\" → Calibrate and draft using framework\n\"Create job description for [role]\" → Generate using template\n\"Run team health check\" → Walk through radar dimensions\n\"Draft ADR for [decision]\" → Structure architecture decision\n\"Incident post-mortem for [incident]\" → Generate post-mortem template\n\"Sprint health report\" → Analyze metrics and flag issues\n\"Promotion case for [name]\" → Build evidence-based promotion doc\n\"Evaluate tech debt [item]\" → Score using prioritization matrix\n\"Flight risk assessment\" → Review signals for each team member\n\"Stakeholder update\" → Generate weekly status from context\n\"Interview scorecard for [candidate]\" → Create structured evaluation" } ], "body": "Engineering Manager Operating System\n\nYour complete playbook for engineering leadership. Not generic management advice — this is the specific system that high-performing engineering managers run daily.\n\nPhase 1: Team Architecture\nTeam Topology Assessment\n\nBefore managing people, understand the system they work in.\n\nteam_topology:\n name: \"[Team Name]\"\n type: stream-aligned | platform | enabling | complicated-subsystem\n mission: \"[One sentence — what does this team exist to do?]\"\n boundaries:\n owns: [\"service-x\", \"domain-y\", \"pipeline-z\"]\n consumes: [\"auth-service\", \"data-platform\"]\n provides: [\"checkout-api\", \"payment-events\"]\n cognitive_load: low | medium | high | overloaded\n interaction_modes:\n - team: \"[Other Team]\"\n mode: collaboration | x-as-a-service | facilitating\n friction: low | medium | high\n notes: \"[What's working/not working]\"\n current_headcount: N\n ideal_headcount: N\n skill_gaps: [\"observability\", \"mobile\", \"ML\"]\n\nTeam Health Radar (Monthly)\n\nScore 1-5 for each dimension. Track trends over time.\n\nDimension\tScore\tSignal\nDelivery pace\t_ /5\tAre we shipping what we committed?\nQuality\t_ /5\tBug rate, incident frequency, tech debt trajectory\nCollaboration\t_ /5\tCross-functional work, PR review speed, knowledge sharing\nMorale\t_ /5\tEnergy in meetings, voluntary contributions, retention signals\nLearning\t_ /5\tNew skills adopted, conference talks, internal tech talks\nAutonomy\t_ /5\tCan the team make decisions without waiting for me?\nPsychological safety\t_ /5\tDo people raise concerns, admit mistakes, challenge ideas?\nOn-call health\t_ /5\tPage frequency, off-hours burden, burnout signals\n\nAction rules:\n\nAny dimension ≤2 → Address THIS WEEK (it's a fire)\nAny dimension at 3 → Create improvement plan within 2 weeks\nOverall average <3.5 → Team is struggling, block new commitments until fixed\nTrack quarter-over-quarter — sustained decline in any dimension = systemic issue\nTeam Composition Model\n\nThe ideal team has these roles covered (not necessarily 1:1 with people):\n\nRole\tDescription\tGap Impact\nTech lead\tArchitecture decisions, code quality bar\tDecisions bottleneck through you\nSenior IC (2-3)\tCarry complex work, mentor juniors\tVelocity drops, quality suffers\nMid-level (2-3)\tReliable delivery, growing scope\tNo bench for senior pipeline\nJunior (0-2)\tLearning, fresh perspective\tNo talent pipeline\nDomain expert\tDeep knowledge of the problem space\tConstantly solving wrong problems\n\nRule of thumb: Never have >60% of team at same level. Mix creates natural mentorship.\n\nPhase 2: 1:1 System\n1:1 Cadence\nReport Level\tFrequency\tDuration\tFocus\nDirect reports\tWeekly\t30 min\tCareer + blockers + feedback\nSkip-levels\tMonthly\t30 min\tTeam health + career + honesty check\nYour manager\tWeekly\t30 min\tPriorities + asks + air cover\nCross-functional peers\tBi-weekly\t25 min\tDependencies + alignment\n1:1 Template (Direct Reports)\none_on_one:\n date: \"YYYY-MM-DD\"\n person: \"[Name]\"\n role: \"[Title]\"\n tenure: \"[X months on team]\"\n \n # Their agenda first — ALWAYS\n their_topics: []\n \n # Check-in (2 min)\n energy_level: 1-10 # \"How are you feeling about work this week?\"\n energy_trend: up | stable | down\n \n # Delivery (5 min)\n current_work: \"[What they're working on]\"\n blockers: []\n help_needed: \"[What can I unblock?]\"\n \n # Growth (10 min — skip if urgent topics dominate, but never 3 weeks in a row)\n career_conversation: \"[Topic discussed]\"\n feedback_given: \"[Specific behavior → impact → request]\"\n feedback_received: \"[What they told me]\"\n stretch_opportunity: \"[Current or upcoming]\"\n \n # Action items\n my_actions: [] # What I committed to do\n their_actions: [] # What they committed to do\n \n # Signals (private — don't share these)\n flight_risk: low | medium | high\n performance_trajectory: improving | stable | declining\n notes: \"[Anything notable]\"\n\n1:1 Question Bank\n\nOpening (rotate these — never use the same opener 3 weeks in a row):\n\n\"What's on your mind?\"\n\"What was the best/worst part of your week?\"\n\"If you could change one thing about how we work, what would it be?\"\n\"What's something you're proud of from this week that I might not know about?\"\n\"On a scale of 1-10, how's your energy? What would move it up one point?\"\n\nCareer development (monthly deep-dive):\n\n\"Where do you want to be in 2 years? What's the gap between here and there?\"\n\"What skills are you not using that you'd like to use more?\"\n\"Who in the org (or industry) has a role you'd want? What specifically about it?\"\n\"What's the hardest technical problem you've solved recently? What did you learn?\"\n\"If you left tomorrow, what would you regret not doing here?\"\n\nTeam health (probe with care):\n\n\"Who on the team do you learn the most from? The least?\"\n\"Is there anyone whose work you don't trust to review?\"\n\"What's something the team avoids talking about?\"\n\"If you were me, what would you change about how this team operates?\"\n\nFeedback solicitation (for YOU):\n\n\"What's one thing I could do differently that would help you most?\"\n\"Am I giving you too much direction or too little?\"\n\"Is there context I have that I'm not sharing that would help you?\"\n\"When was the last time I frustrated you? What happened?\"\nFlight Risk Detection\n\nMonitor these signals — if 3+ present, have a retention conversation within a week:\n\nSignal\tWeight\tDetection\nLinkedIn profile update\t🔴 High\tSomeone mentions it, or you notice\nDeclining 1:1 engagement\t🔴 High\tShorter answers, less eye contact, \"everything's fine\"\nStopped volunteering for projects\t🟡 Medium\tUsed to raise hand, now doesn't\nIncreased PTO without travel\t🟡 Medium\tInterviewing signal\nDisengaged in meetings\t🟡 Medium\tCamera off, multitasking, no opinions\nComplaining shifted from specific to general\t🟡 Medium\t\"This sprint is rough\" → \"This place...\"\nStopped arguing for their ideas\t🔴 High\tThey've mentally checked out\nLife event (new baby, move, partner change)\t🟡 Medium\tRe-evaluating everything\n\nRetention conversation framework:\n\nName it: \"I've noticed [specific behavior change]. I want to check in.\"\nListen: Let them talk. Don't interrupt. Don't get defensive.\nUnderstand: \"What would make this the best job you've ever had?\"\nAct: Make a concrete commitment within 48 hours — title, comp, scope, flexibility\nFollow up: Check back in 1 week. Did what you promised make a difference?\nPhase 3: Performance Management\nPerformance Calibration Framework\n\nRate on two axes (both matter):\n\nDelivery Impact (What)\n\nLevel\tDescription\n1 - Below\tMissing commitments, quality issues, needs close oversight\n2 - Meeting\tDelivering assigned work reliably\n3 - Exceeding\tDelivering beyond scope, finding better solutions\n4 - Outstanding\tMultiplying team output, solving problems no one asked them to\n\nBehaviors (How)\n\nLevel\tDescription\n1 - Below\tCreating friction, not collaborating, ignoring feedback\n2 - Meeting\tProfessional, collaborative, receptive to feedback\n3 - Exceeding\tMentoring others, proactively improving processes\n4 - Outstanding\tShaping culture, attracting talent, raising the entire bar\n\nCalibration matrix:\n\n\tBehavior 1\tBehavior 2\tBehavior 3\tBehavior 4\nDelivery 4\tCoach behaviors\tStrong\tTop performer\tSuperstar\nDelivery 3\tCoach behaviors\tSolid\tStrong\tTop performer\nDelivery 2\tPIP candidate\tMeets expectations\tDeveloping\tGrowing\nDelivery 1\tExit\tPIP\tCoach delivery\tCoach delivery\nFeedback Framework: SBI-I (Situation-Behavior-Impact-Intent)\n\nTemplate: \"In [situation], when you [specific behavior], the impact was [concrete effect]. I'd like to see [specific change] because [intent/why it matters].\"\n\nExamples:\n\n✅ Good: \"In yesterday's design review, when you challenged the API schema with the versioning concern, it caught a breaking change we would have shipped. That's exactly the kind of technical leadership I want to see more of.\"\n\n❌ Bad: \"You're doing great work. Keep it up.\" (Too vague — they learn nothing)\n\n✅ Good: \"In the last two sprints, PRs have been sitting in review for 3+ days. The impact is features are merging late and we're missing sprint commitments. I'd like us to commit to <24h first review because velocity depends on review speed.\"\n\n❌ Bad: \"You need to review PRs faster.\" (No situation, no impact, no collaboration)\n\nPerformance Improvement Plan (PIP) Template\npip:\n employee: \"[Name]\"\n role: \"[Title]\"\n manager: \"[Your name]\"\n start_date: \"YYYY-MM-DD\"\n end_date: \"YYYY-MM-DD\" # 30-60 days, never >90\n \n context: |\n [Specific pattern of underperformance with dates and examples.\n Must reference prior feedback conversations and dates they occurred.]\n \n expectations:\n - area: \"[Specific skill/behavior]\"\n current_state: \"[What's happening now — with examples]\"\n target_state: \"[What success looks like — measurable]\"\n measurement: \"[How we'll measure — PR metrics, sprint completion, etc.]\"\n support: \"[What I'll provide — pairing, training, reduced scope]\"\n \n check_ins:\n frequency: weekly\n day: \"[Day]\"\n format: \"[30 min 1:1 with written summary]\"\n \n outcomes:\n success: \"[What happens if targets met — return to normal performance management]\"\n failure: \"[What happens if targets not met — typically termination]\"\n \n # CRITICAL: Have HR review before sharing. Document every check-in.\n hr_reviewed: false\n hr_reviewer: \"[Name]\"\n\n\nPIP rules:\n\nA PIP should never be a surprise — if it is, YOU failed at feedback\nPIPs are for capability gaps, not attitude problems (attitude = manage out faster)\n70% of PIPs end in termination — be honest with yourself about whether this is a development tool or a documentation exercise\nWeekly check-ins are non-negotiable — document everything in writing\nIf performance improves during PIP then declines after: second PIP is rarely worth it\nPromotion Case Template\npromotion_case:\n candidate: \"[Name]\"\n current_level: \"[Level]\"\n target_level: \"[Level]\"\n manager: \"[Your name]\"\n date: \"YYYY-MM-DD\"\n \n # Already operating at next level (past 6+ months)\n evidence:\n - dimension: \"Technical complexity\"\n examples:\n - \"[Specific project/decision with measurable impact]\"\n - \"[Another example]\"\n - dimension: \"Scope & ownership\"\n examples:\n - \"[Owned X end-to-end, previously needed guidance]\"\n - dimension: \"Influence & leadership\"\n examples:\n - \"[Mentored Y, led Z initiative, shaped team direction]\"\n - dimension: \"Business impact\"\n examples:\n - \"[Revenue/efficiency/reliability improvement with numbers]\"\n \n peer_feedback:\n - from: \"[Name, role]\"\n quote: \"[Specific praise with examples]\"\n \n # Why now, not 6 months from now?\n timing_justification: |\n [They've been consistently operating at next level for X months.\n Delaying creates retention risk and sends wrong signal to team.]\n \n # What's the gap? (Be honest — calibration committees will find it)\n growth_areas: |\n [Areas they're still developing. Frame as \"growing into\" not \"lacking.\"]\n\nPhase 4: Hiring Machine\nHiring Pipeline\nRole opened → Job description → Sourcing (5-7 days)\n→ Resume screen → Recruiter screen (30 min)\n→ Technical phone screen (60 min) → Take-home OR live coding (2-4 hrs)\n→ Onsite/virtual loop (3-4 hrs) → Debrief → Offer → Close\n\nTarget: <21 days from first screen to offer\n\nJob Description Template\n# [Role Title] — [Team Name]\n\n## What you'll do\n[3-5 bullet points of ACTUAL work, not generic responsibilities]\n- Ship [specific feature/system] that [specific impact]\n- Own [specific domain] end-to-end\n- [Concrete example of a recent problem this person would solve]\n\n## What you'll need\n[Must-haves only — each one must be a genuine filter]\n- X years building [specific technology/domain]\n- Experience with [specific technical requirement]\n- [Skill that actually differentiates candidates]\n\n## Nice to have (genuinely nice, not secretly required)\n- [Thing that would accelerate ramp-up]\n- [Adjacent skill that adds value]\n\n## What we offer\n[Be specific — \"competitive salary\" means nothing]\n- Salary range: $X-$Y (based on [location/level])\n- [Specific benefits that matter to engineers]\n- [Team/culture thing that's actually true and differentiating]\n\n## How we hire\n[Timeline and what to expect — respect their time]\n1. [Step]: [Duration] — [What we're assessing]\n2. [Step]: [Duration] — [What we're assessing]\nTotal time investment: ~X hours\n\nInterview Scorecard (Per Interviewer)\nscorecard:\n candidate: \"[Name]\"\n interviewer: \"[Name]\"\n interview_type: \"technical | system design | behavioral | culture\"\n date: \"YYYY-MM-DD\"\n \n # Score each dimension 1-4 (no 3s allowed — forces a decision)\n dimensions:\n - name: \"Technical depth\"\n score: _ # 1=no hire, 2=lean no, 4=lean yes, 5=strong yes (skip 3)\n evidence: \"[Specific examples from the interview]\"\n - name: \"Problem solving approach\"\n score: _\n evidence: \"[How they broke down the problem, handled hints]\"\n - name: \"Communication clarity\"\n score: _\n evidence: \"[Could they explain their thinking? Did they ask good questions?]\"\n - name: \"Collaboration signals\"\n score: _\n evidence: \"[How did they respond to pushback? Did they build on ideas?]\"\n \n # Overall\n hire_recommendation: strong_no | no | yes | strong_yes\n level_recommendation: \"[What level would you place them?]\"\n concerns: \"[Anything that gave you pause]\"\n highlights: \"[What impressed you most]\"\n\nDebrief Protocol\nNo pre-discussion — Submit scorecards BEFORE the debrief meeting\nHire bar holder speaks last — Prevent anchoring\nDiscuss each dimension, not overall vibes — \"Tell me about their system design approach\" not \"What did you think?\"\nAny strong_no is a veto — Unless the interviewer can be convinced their signal was a misread\nDecide in the room — Don't \"sleep on it\" unless genuinely torn (then it's probably a no)\nLeveling before offer — Agree on level first, then comp follows from band\nClosing Candidates\n\nThe 3 things that close engineers:\n\nThe problem — \"Here's the specific hard problem you'd work on\"\nThe people — Connect them with future teammates before offer\nThe growth — \"Here's where this role leads in 18 months\"\n\nOffer call structure (15-20 min):\n\nExpress genuine excitement (2 min)\nPresent offer details — base, equity, bonus, start date (3 min)\nExplain equity/comp philosophy (3 min)\nAsk: \"How does this compare to what you were expecting?\" (listen)\nAddress concerns immediately if possible\nSet a decision deadline (3-5 business days, not open-ended)\nAsk: \"Is there anything that would make this a clear yes?\"\nPhase 5: Technical Leadership\nArchitecture Decision Record (ADR)\nadr:\n id: \"ADR-NNN\"\n title: \"[Decision title]\"\n date: \"YYYY-MM-DD\"\n status: proposed | accepted | deprecated | superseded\n superseded_by: \"ADR-NNN\" # if applicable\n \n context: |\n [What situation are we in? What forces are at play?\n Include constraints: timeline, team skill, budget, scale requirements.]\n \n options:\n - name: \"[Option A]\"\n pros: [\"pro 1\", \"pro 2\"]\n cons: [\"con 1\", \"con 2\"]\n effort: \"[T-shirt size]\"\n risk: low | medium | high\n - name: \"[Option B]\"\n pros: [\"pro 1\"]\n cons: [\"con 1\", \"con 2\", \"con 3\"]\n effort: \"[T-shirt size]\"\n risk: low | medium | high\n \n decision: |\n [What we decided and WHY. The \"why\" is the most important part.\n Future readers need to understand the reasoning, not just the choice.]\n \n consequences: |\n [What follows from this decision? What becomes easier/harder?\n What do we need to monitor?]\n \n review_date: \"YYYY-MM-DD\" # When to revisit this decision\n\nTech Debt Prioritization\n\nScore each debt item on two axes:\n\nImpact of fixing (1-5):\n\n5: Unblocks multiple teams or critical features\n4: Significant velocity improvement for our team\n3: Moderate improvement, prevents future problems\n2: Nice to have, minor improvement\n1: Cosmetic or theoretical benefit\n\nCost of NOT fixing (1-5):\n\n5: Will cause incidents or data loss\n4: Blocking hiring/onboarding (can't explain the code)\n3: Slowing every feature by >20%\n2: Occasional friction, workarounds exist\n1: Annoying but harmless\n\nPriority = Impact × Cost-of-not-fixing\n\nScore\tAction\n20-25\tFix THIS sprint — it's an emergency\n12-19\tSchedule within 2 sprints\n6-11\tAdd to quarterly tech debt budget (allocate 15-20% of sprint capacity)\n1-5\tBacklog — revisit quarterly\nCode Review Culture Guidelines\ncode_review_standards:\n sla:\n first_review: \"< 4 hours during work hours\"\n follow_up: \"< 2 hours\"\n max_pr_size: 400 # lines changed — larger needs pre-review or splitting\n \n what_to_review:\n always:\n - \"Correctness — does it do what it claims?\"\n - \"Edge cases — what happens with nil/empty/max/concurrent?\"\n - \"Security — auth checks, input validation, secrets exposure\"\n - \"Naming — will someone understand this in 6 months?\"\n sometimes:\n - \"Performance — only if in hot path or O(n²)+ risk\"\n - \"Style — only if it significantly hurts readability\"\n never:\n - \"Personal preference disguised as improvement\"\n - \"Premature optimization suggestions\"\n - \"Rewriting working code to your style\"\n \n tone_rules:\n - \"Ask questions instead of making demands: 'What happens if X is nil?' not 'Handle the nil case'\"\n - \"Prefix opinion with 'nit:' or 'optional:' — make severity clear\"\n - \"Praise good code — 'Nice abstraction here' costs nothing\"\n - \"If >5 comments, offer to pair instead\"\n - \"Approve with comments when nothing is blocking — trust your team\"\n\nPhase 6: Sprint & Delivery\nSprint Ceremony Cheat Sheet\nCeremony\tDuration\tWho\tPurpose\tYour Role\nSprint planning\t1-2 hrs\tTeam + PO\tCommit to sprint goal\tFacilitate, challenge estimates, protect capacity\nDaily standup\t15 min\tTeam\tSurface blockers\tListen for problems, DON'T manage tasks\nBacklog refinement\t1 hr\tTeam + PO\tPrepare future work\tEnsure technical feasibility, flag risks\nSprint review\t30 min\tTeam + stakeholders\tDemo working software\tLet the team present, handle stakeholder Qs\nRetrospective\t1 hr\tTeam only\tImprove process\tFacilitate, ensure psychological safety, track actions\nSprint Health Metrics\n\nTrack these weekly — trend matters more than absolute numbers:\n\nMetric\tHealthy Range\tRed Flag\nSprint completion rate\t80-100% of committed points\t<70% for 2+ sprints\nCarry-over stories\t0-1 per sprint\tSame story carried 3+ sprints\nPR cycle time\t<48 hours open to merge\t>72 hours consistently\nBug escape rate\t<10% of stories create bugs\tRising trend\nDeployment frequency\tDaily to weekly\tMonthly or less\nSprint goal achievement\tYes/No binary\tNo for 3+ consecutive sprints\nEstimation Heuristic\n\nWhen the team struggles with estimation:\n\nCertainty Level\tApproach\n\"We've done this exact thing before\"\tSize by comparison to past work\n\"We understand the problem but not the solution\"\tSpike first (timeboxed), then estimate\n\"We don't fully understand the problem\"\tDiscovery task (1-2 days), then re-scope\n\"We have no idea\"\tBreak it down until you reach pieces you can estimate\n\nRule: If an estimate is >8 points (or >5 days), it's not estimated — it's a guess. Break it down further.\n\nPhase 7: Incident Management\nIncident Response Framework\nincident:\n id: \"INC-YYYY-NNN\"\n severity: SEV1 | SEV2 | SEV3 | SEV4\n detected: \"YYYY-MM-DD HH:MM UTC\"\n resolved: \"YYYY-MM-DD HH:MM UTC\"\n duration: \"Xh Ym\"\n commander: \"[Name]\"\n \n # Severity guide\n # SEV1: Revenue impact, data loss, full outage — ALL HANDS, exec notification\n # SEV2: Degraded service, partial outage — On-call + team lead\n # SEV3: Minor degradation, workaround exists — On-call handles\n # SEV4: Cosmetic, no user impact — Normal ticket\n \n timeline:\n - time: \"HH:MM\"\n action: \"[What happened / what was done]\"\n who: \"[Name]\"\n \n root_cause: |\n [Technical root cause — be specific. \n \"Human error\" is never the root cause. What system allowed the error?]\n \n contributing_factors:\n - \"[Factor 1 — e.g., missing monitoring on X]\"\n - \"[Factor 2 — e.g., deployment during peak without feature flag]\"\n \n action_items:\n - description: \"[Specific fix]\"\n owner: \"[Name]\"\n due_date: \"YYYY-MM-DD\"\n priority: P0 | P1 | P2\n status: open | in_progress | done\n\nBlameless Post-Mortem Template\n\nFacilitation rules:\n\nFocus on systems, not individuals\n\"What\" and \"how,\" never \"who\"\nEveryone involved attends (including on-call who was paged)\nSchedule within 48 hours of resolution (memories fade)\nWrite it up and share publicly within the engineering org\n\nStructure (60-90 min):\n\nTimeline review (20 min) — Walk through chronologically. Fill gaps.\nRoot cause analysis (15 min) — \"5 Whys\" until you hit a systemic issue\nWhat went well (10 min) — Reinforce good incident response behaviors\nWhat went wrong (15 min) — Process failures, detection gaps, communication issues\nAction items (15 min) — Each must have an owner and due date. Max 5 items — focus beats volume.\nOn-Call Health Guidelines\nMetric\tHealthy\tUnhealthy\nPages per week\t<5\t>10\nOff-hours pages\t<2/week\t>5/week\nTime to acknowledge\t<5 min\t>15 min\nFalse positive rate\t<20%\t>50%\nRotation size\t4+ people\t<3 people\nConsecutive weeks on-call\tNever >2\tRegular 3+ week stretches\n\nIf on-call is unhealthy: This is a tech debt problem, not a people problem. Invest in reliability before adding headcount.\n\nPhase 8: Scaling & Org Design\nWhen to Split a Team\nSignal\tAction\nTeam >8 people\tSplit before communication overhead kills velocity\nTwo distinct domains in one team\tSplit along domain boundaries\nStandup takes >15 min\tToo many threads — people are tuning out\nPR review queue >48 hours consistently\tNot enough context overlap — specialize\nOn-call covers too many services\tReduce blast radius per team\nSplitting Protocol\nDefine boundaries clearly — What does each new team OWN? Write it down.\nSplit the backlog — Every ticket gets a home. Shared backlogs = shared ownership = no ownership.\nSplit on-call — Each team owns their services' reliability.\nName the teams — Sounds trivial, matters for identity.\nDesignate tech leads — Don't leave both teams looking to you for technical decisions.\nGive it 3 months — Resist re-orging again too quickly. Turbulence is normal.\nManager-to-IC Ratio\nTeam Size\tStructure\n3-5 ICs\tPlayer-coach (you're still coding ~30-40%)\n5-8 ICs\tFull-time manager (stop coding in critical path)\n8-12 ICs\tSplit the team OR add a tech lead as force multiplier\n12+ ICs\tMust split — you cannot manage this effectively\nThe IC-to-Manager Transition\n\nIf you're newly managing (or coaching someone through it):\n\nStop doing:\n\nWriting code in the critical path (you're now the bottleneck)\nSolving every technical problem yourself\nBeing the best engineer on the team (your job changed)\n\nStart doing:\n\nAsking \"who should own this?\" instead of doing it yourself\nMeasuring success by team output, not your output\nHaving uncomfortable conversations early (feedback, performance, conflict)\nBlocking time for thinking, not just meetings\n\nKeep doing:\n\nStaying technical enough to evaluate decisions (read code, review designs)\nCoding on side projects, tools, or prototypes (stay sharp)\nHaving strong technical opinions (but hold them loosely)\n\nTimeline to competence:\n\nMonth 1-3: Imposter syndrome, everything feels slow. Normal.\nMonth 3-6: Finding your rhythm, some wins, some failures. Normal.\nMonth 6-12: Confident in the role, building systems. Target.\nMonth 12+: Multiplying impact. If you're not here by month 18, honest conversation needed.\nPhase 9: Communication & Stakeholder Management\nWeekly Status Update Template\n\nSend this to your manager and stakeholders every Friday:\n\n# [Team Name] — Week of [Date]\n\n## 🎯 Sprint Goal: [Goal] — On Track / At Risk / Off Track\n\n## ✅ Shipped This Week\n- [Feature/fix] — [Impact in user/business terms]\n- [Feature/fix] — [Impact]\n\n## 🔨 In Progress\n- [Work item] — [Status, ETA, any blockers]\n\n## 🚨 Risks & Blockers\n- [Risk] — [What you're doing about it, what you need]\n\n## 📊 Key Metrics\n- Deploy frequency: X\n- Incident count: X (SEV breakdown)\n- Sprint completion: X%\n\n## 🔮 Next Week\n- [Priority 1]\n- [Priority 2]\n\nManaging Up Checklist\nDo\tDon't\nBring solutions with problems\tDump problems without proposals\nFlag risks early with mitigation plans\tSurprise with bad news at the last minute\nQuantify impact (hours, $$, users)\tUse vague language (\"it's kinda slow\")\nSay \"I need X from you by Y\"\tHope they'll figure out you need help\nSend written updates proactively\tWait to be asked for status\nDisagree in private\tDisagree in public meetings\nAsk for feedback regularly\tAssume no news is good news\nCross-Functional Relationship Map\nstakeholders:\n - name: \"[Product Manager]\"\n relationship: partner\n cadence: \"Daily async + weekly 1:1\"\n currency: \"Scope clarity, user data, priority decisions\"\n \n - name: \"[Design Lead]\"\n relationship: partner\n cadence: \"Bi-weekly sync + ad-hoc\"\n currency: \"Early technical feasibility input\"\n \n - name: \"[Platform/Infra Team]\"\n relationship: dependency\n cadence: \"Monthly sync + Slack\"\n currency: \"Clear requirements, advance notice of needs\"\n \n - name: \"[Your Manager]\"\n relationship: air_cover\n cadence: \"Weekly 1:1\"\n currency: \"No surprises, clear asks, good judgment\"\n\nPhase 10: Engineering Manager Rituals\nDaily (15 min total)\n Scan Slack/email for blockers — unblock before standup\n Attend standup — listen for patterns, not task updates\n Check PR queue — nudge any >24h reviews\n One piece of feedback (positive or constructive) to someone\nWeekly\n All 1:1s completed (never cancel — reschedule if needed)\n Sprint metrics reviewed\n Status update sent to stakeholders\n Calendar audit — am I in meetings I shouldn't be in?\n One skip-level or cross-functional conversation\nMonthly\n Team health radar updated\n Career development conversation with each report\n Tech debt review and prioritization\n On-call health review\n Update team topology doc\nQuarterly\n Performance calibration (formal or informal)\n Team goals review and reset\n Architecture review — any ADRs need revisiting?\n Headcount planning — what do we need in 6 months?\n Retrospective on YOUR performance — ask your team for feedback\nPhase 11: Difficult Situations Playbook\nScenario: Two Senior Engineers Disagree on Architecture\nLet them present both approaches in a design doc (each writes their own section)\nDefine decision criteria BEFORE evaluating: reversibility, maintenance cost, team familiarity, timeline\nFacilitate a time-boxed discussion (60 min max)\nIf no consensus: the tech lead or DRI decides. Not you (unless you must).\nDocument the decision as an ADR — the \"why\" matters more than the \"what\"\nThe person who \"lost\" must commit fully. Monitor for passive resistance.\nScenario: High Performer Wants to Be a Manager\nExplore motivation: \"Tell me what you think a manager does day-to-day\"\nTest with real work: lead a project, mentor a junior, run a retrospective\nBe honest about tradeoffs: less coding, more meetings, slower feedback loops, ambiguous success metrics\nOffer the Staff/Principal IC path as a genuine alternative, not a consolation prize\nIf they proceed: set explicit check-in at 3 months — \"Is this what you wanted?\"\nScenario: You Inherit a Low-Performing Team\nWeek 1-2: Listen. 1:1 with every person. Don't change anything yet.\nWeek 3-4: Identify the 1-2 systemic issues (usually: unclear priorities, no accountability, or trust deficit)\nMonth 2: Make ONE process change. Get a quick win. Build credibility.\nMonth 3: Address performance issues you've now observed firsthand\nNever: Blame the previous manager publicly. Never say \"things are going to change around here.\"\nScenario: Layoffs / Reorg Affecting Your Team\nBefore announcement: Prepare a plan for remaining team — who covers what?\nDuring: Be honest about what you know and what you don't. \"I don't know\" > corporate-speak.\nAfter: 1:1 with every remaining person within 48 hours. Expect anger, fear, guilt.\nOngoing: Workload audit — don't expect same output from fewer people. Push back on scope.\nSelf-care: This is one of the hardest parts of the job. Talk to your own manager or a coach.\nScenario: Your Best Engineer Gives Notice\nSame day: Have a real conversation. Not a counteroffer — understand why.\nIf it's about money: Match or beat if they're worth it. If your company won't, that tells you something.\nIf it's about growth/role: Can you create what they want? Be honest if you can't.\nIf they're leaving for the right reasons: Celebrate them. Write a recommendation. Don't make it weird.\nImmediately: Start knowledge transfer plan. Identify what only they know.\nTo the team: Transparent but positive. \"X is leaving for a great opportunity. Here's our transition plan.\"\nScoring Rubric: Engineering Manager Effectiveness (0-100)\nDimension\tWeight\tIndicators\nTeam health\t20%\tRetention, engagement scores, psychological safety signals\nDelivery\t20%\tSprint completion, quality metrics, stakeholder satisfaction\nPeople development\t20%\tPromotions, skill growth, 1:1 quality, mentorship\nTechnical stewardship\t15%\tTech debt trajectory, architecture quality, incident trends\nHiring\t10%\tPipeline health, offer acceptance rate, new hire ramp time\nCommunication\t10%\tStakeholder relationships, information flow, no surprises\nSelf-improvement\t5%\tSeeking feedback, adapting, growing as a leader\n\nScoring:\n\n90-100: Exceptional — team thriving, people growing, shipping reliably\n75-89: Strong — most things working, some areas to develop\n60-74: Developing — foundational skills present, needs coaching\n40-59: Struggling — significant gaps, at risk of losing team trust\n<40: Intervention needed — coaching, role change, or transition\nNatural Language Commands\n\"Prepare 1:1 with [name]\" → Generate agenda from recent context\n\"Write performance review for [name]\" → Calibrate and draft using framework\n\"Create job description for [role]\" → Generate using template\n\"Run team health check\" → Walk through radar dimensions\n\"Draft ADR for [decision]\" → Structure architecture decision\n\"Incident post-mortem for [incident]\" → Generate post-mortem template\n\"Sprint health report\" → Analyze metrics and flag issues\n\"Promotion case for [name]\" → Build evidence-based promotion doc\n\"Evaluate tech debt [item]\" → Score using prioritization matrix\n\"Flight risk assessment\" → Review signals for each team member\n\"Stakeholder update\" → Generate weekly status from context\n\"Interview scorecard for [candidate]\" → Create structured evaluation" }, "trust": { "sourceLabel": "tencent", "provenanceUrl": "https://clawhub.ai/1kalin/afrexai-engineering-manager", "publisherUrl": "https://clawhub.ai/1kalin/afrexai-engineering-manager", "owner": "1kalin", "version": "1.0.0", "license": null, "verificationStatus": "Indexed source record" }, "links": { "detailUrl": "https://openagent3.xyz/skills/afrexai-engineering-manager", "downloadUrl": "https://openagent3.xyz/downloads/afrexai-engineering-manager", "agentUrl": "https://openagent3.xyz/skills/afrexai-engineering-manager/agent", "manifestUrl": "https://openagent3.xyz/skills/afrexai-engineering-manager/agent.json", "briefUrl": "https://openagent3.xyz/skills/afrexai-engineering-manager/agent.md" } }