The transition from individual contributor to engineering manager is, more than anything else, a transition into writing. Not the writing you did as an IC — code comments, PR descriptions, the occasional design doc you procrastinated for two weeks. The writing that runs an engineering organization: the RFC that nobody has started yet, the performance review for the engineer who's been coasting for two quarters, the hiring scorecard from yesterday's debrief, the sprint retro you need to run on Thursday, the quarterly OKR update for the CPO who doesn't know what a message queue is, the Slack thread that escalated into a situation that should have been a design doc three months ago.
All of it lands on you. And the volume doesn't shrink as the team grows — it scales with the team. The more engineers you're responsible for, the more documents those responsibilities generate. Claude doesn't write your code. You shouldn't want it to. But it handles the writing layer — the layer that currently owns your evenings.
Claude is a large language model. It is not connected to your systems. It cannot access GitHub, Jira, Linear, Notion, Confluence, Google Docs, Datadog, PagerDuty, or Slack. It cannot read your team's commit history, pull request data, incident timeline, or performance data. It cannot generate, run, review, or deploy code in production. It strictly drafts documents. You bring the context — paste in your notes, your ticket summaries, your interview observations, your sprint data — and Claude produces structured prose from that input. Every use case below follows that same pattern. You own the technical judgment. Claude closes the blank-page gap.
That constraint matters for engineering leaders specifically. A fabricated architecture pattern in an RFC costs you alignment. An invented competency score in a hiring scorecard costs you a candidate or a bad hire. Claude will not fill gaps by making things up — when your notes are thin, the output says so. That conservatism is the behavior you want when you're signing off on a document.
1. RFC / Technical Design Document Narrative
The RFC is the document that gets engineers aligned before a single line of production code is written. When it's done well — clear problem statement, crisp proposed solution, honest alternatives considered with real rejection rationale, explicit trade-offs, open questions surfaced — it prevents two weeks of architecture debates in code review. When it's missing or thin, those debates happen anyway, just at the worst possible time.
The blocker is usually the blank page. The technical thinking is done. The decisions have been made in your head or in a whiteboard session. Getting it into a 1,500-word structured document that other engineers will actually read is the friction.
Paste your technical spec bullets, problem statement, and decision context. Claude produces the RFC narrative.
I need to write an RFC for [system name / feature name]. Here's what I have:
Problem statement: [describe the current state and why it's a problem — include scale, failure modes, or business impact if relevant]
Proposed solution: [describe what you're building or changing — architecture, components, data flow, interfaces]
Alternatives we considered: [list the alternatives — even brief descriptions — and why we're not doing them]
Key trade-offs: [what we're accepting with this approach — performance, complexity, consistency, operational burden, etc.]
Open questions: [things not yet decided, dependencies we're waiting on, areas we need review on]
Migration/rollout: [how we get from current state to new state — any phasing, feature flags, backward compatibility considerations]
Write a full RFC narrative with the following sections:
- Problem Statement: the current state, why it matters, what breaks or doesn't scale, the business or user impact
- Proposed Solution: the technical approach in narrative form — not bullet points; explain the design as if you're walking an engineer through it who wasn't in the whiteboard session
- Alternatives Considered: each alternative with a 2–3 sentence rejection rationale — honest, not dismissive
- Trade-offs: what we're accepting, what we're not optimizing for, what this approach makes harder
- Open Questions: specific, not vague; flag decisions still to be made and who needs to weigh in
- Migration and Rollout Plan Sketch: phased approach, any compatibility concerns, rollback considerations
Do not invent technical details not in the notes I provided.
The "do not invent technical details" instruction is non-negotiable. The RFC narrative is yours — Claude writes the structure and the prose, you supply the technical substance. For software engineers working at the IC level who need to write their own RFCs and design docs, Claude AI for Software Engineers covers the individual contributor documentation layer.
2. Performance Review Document (Individual Contributor)
The performance review is the document that takes three hours and a blank cursor. You've been running 1:1s all year. You know exactly how the engineer has performed — what they shipped, where they coasted, what their ceiling is, whether they're operating at level. Getting that judgment into a structured document that HR will accept, that the engineer will read as fair, and that you can defend in a calibration meeting is the actual job.
The hard caveat first: do not paste identifiable employee data — full names, employee IDs, or any HR-system identifiers — into Claude. Use initials or a role description (e.g., "Senior Backend Engineer, 3 years at company"), then replace with identifying information before submitting to HR. This is a firm line.
Paste your 1:1 notes, recent wins, development areas, and level rubric context. Claude produces the structured review document.
I need to write a performance review for [use initials or role description — e.g., "Senior Backend Engineer, 3 years at company, working on payments infrastructure"]. Here's my input:
Recent wins and impact: [paste your notes — specific projects, outcomes, contributions that stand out]
Development areas: [paste your notes — patterns you've observed, feedback you've given, areas where performance hasn't met expectations]
1:1 notes summary: [paste relevant themes from your 1:1 notes — not a transcript, the patterns you've noticed over the cycle]
Level expectations for this role: [paste the level rubric or describe the expectations — what does "meeting expectations" look like at this level?]
Write a structured performance review document including:
- Impact Summary: 2–3 sentences on the overall contribution this cycle — specific, not generic
- Strengths: 3–4 strengths with specific examples from the work I described — not generic praise; each strength should reference real output
- Growth Areas: 2–3 development areas with specific examples and the pattern behind each — framed as development, not criticism
- Level Assessment: is this person operating at level, above, or below — and what's the specific evidence for that assessment?
- Recommended Next Focus: 1–2 development priorities for the next cycle with concrete framing
Tone: direct, fair, specific. Written as the manager who ran this cycle, not HR.
The specificity instruction is the part that makes reviews credible. Vague strengths ("strong communicator," "team player") don't hold up in calibration. Claude will pull specific examples from what you paste in — which means your 1:1 notes are the quality input that drives quality output.
3. Hiring Scorecard and Interview Debrief Summary
The EM who summarizes the debrief well controls the hiring decision. That's the actual dynamic in every hiring loop: the person who walks into the debrief with a coherent narrative — this is what we saw, this is the evidence, this is the concern and how much it matters, this is the recommendation — shapes the room. That document is the hiring scorecard.
The caveat up front: Claude cannot access Greenhouse, Lever, or any ATS. The scorecard narrative you produce here is for your own use in the debrief meeting — you'll enter scores and notes into your ATS separately. Do not paste candidates' full names or personal contact information into Claude.
Paste your interview notes, role requirements, and team context. Claude produces the scorecard narrative.
I'm preparing the hiring debrief for a candidate for [role title]. Here's what I have:
Role requirements: [paste the key requirements — technical skills, behaviors, level criteria, team fit considerations]
My interview notes: [paste your notes from the interviews you conducted — observations, specific answers, red flags, strong signals]
Other interviewers' feedback (summarized): [paste any feedback you've received from other interviewers — key themes, concerns, positive signals]
Team context: [describe the team this person would join — size, current gaps, working style, what success in this role looks like in 6 months]
Write a candidate scorecard narrative for the debrief meeting including:
- Strengths: 3–4 specific, evidence-backed strengths — what we observed and why it's signal, not noise
- Concerns: 2–3 specific concerns — what we observed, whether it's a dealbreaker or manageable, and what would need to be true for it not to matter
- Evidence Summary Per Competency: for each key competency in the role, 1–2 sentences of evidence from the interviews — what we saw, from whom
- Hiring Recommendation: hire / no hire / strong hire — with a 3–4 sentence rationale that would hold up in a debrief where someone disagrees
Do not invent competency scores or observations not in the notes I provided.
The "do not invent competency scores" instruction is critical. A scorecard that fabricates evidence is useless at best, harmful at worst. Claude pulls from what you give it — which means the quality of your interview notes drives the quality of the debrief narrative. For recruiters working on the sourcing and screening side of the same loop, Claude AI for Startup Founders covers the hiring and team-building layer from the founder perspective.
4. Sprint Retrospective Document
The sprint retro is the meeting that feels optional to engineers who've been in bad ones. A good retro document — themes rather than a list dump, root cause framing rather than blame, action items with owners and measurable outcomes, honest carry-forward from last time — is what makes it feel worth attending.
Paste your retro notes, velocity data, and incident log summaries. Claude produces the structured retrospective.
I need to write the sprint retrospective document for Sprint [number/name]. Here's the raw material:
What went well (raw notes): [paste your notes — wins, things that worked, team behavior you want to reinforce]
What didn't go well (raw notes): [paste your notes — friction, failures, incidents, missed commitments]
Velocity and delivery data: [paste the numbers — story points committed vs. completed, carry-over tickets, any incidents or outages this sprint]
Carry-forward from last retro: [paste the action items from the previous retro — which were completed, which weren't]
Write a structured sprint retrospective document including:
- What Went Well: organized by themes (not a bullet list dump) — 3–4 themes with 2–3 specific examples each; include a one-sentence "why this matters" for each theme
- What Didn't Go Well: each item with a root cause framing ("the root cause here was X, not Y") — specific, not blame-oriented; flag patterns across items
- Action Items: table format — Action | Owner | Priority (High/Medium) | Measurable Outcome | Due Sprint
- Carry-Forward Review: for each carry-forward item from last retro — Completed / Not Completed / In Progress — with a one-line status note
- One-sentence theme for this sprint overall — the honest summary of what this sprint was
Tone: direct, constructive, specific. Written to be read by the engineering team, not stakeholders.
The root cause framing on what didn't go well is the part that separates useful retros from venting sessions. "We had three scope changes mid-sprint" is a complaint. "The root cause was that acceptance criteria weren't finalized before sprint start — we need a Definition of Ready check before grooming closes" is an action item.
5. Engineering Update for Non-Technical Stakeholders
Every EM writes this badly when they're tired on a Friday afternoon. The exec update is the translation layer — technical sprint work into business language, for the CPO who needs to know what shipped and what it means, not how the message queue was redesigned. Getting it wrong costs you credibility with business stakeholders. Getting it right is the thing that makes your team's work visible.
Paste your sprint summary, technical decisions, and blockers. Claude produces the exec-ready update.
I need to write an engineering update for [audience — e.g., CPO and product leadership, CEO and executive team, Friday all-hands]. Here's the technical context:
What shipped this sprint: [paste your sprint summary — features, bug fixes, infra work, anything completed]
Key technical decisions made: [paste decisions you made this sprint — architectural choices, tech debt trade-offs, build vs. buy calls — with brief rationale]
Current blockers or risks: [paste what's blocking you or what has the potential to slip — be specific about what's needed to unblock]
What's next: [paste your next sprint's focus or upcoming priorities]
Write an executive-ready engineering update including:
- What Shipped: each item stated in terms of what it does for the business or user, not the technical implementation — no jargon
- What It Unlocks: for the top 1–2 items, a sentence on what capability, metric, or business outcome this enables
- What We Decided and Why: 1–2 technical decisions stated in non-technical terms — what was the choice, why we made it, what it means for the roadmap
- What's Next: next sprint focus framed as business priorities, not engineering tickets
- Where We Need Input or Unblocking: specific asks from leadership — one sentence each, actionable
Tone: peer-to-peer with a non-technical executive. No acronyms, no system names, no architecture terminology. If a term must be used, define it in the same sentence.
"If a term must be used, define it in the same sentence" is the instruction that does the most work. Business stakeholders who feel condescended to by jargon stop reading engineering updates. Stakeholders who feel informed become advocates. The translation layer is not dumbing things down — it's respecting your audience. For business analysts who work with engineering teams on requirements and translation, Claude AI for Business Analysts covers the requirements and findings documentation layer.
6. Job Description and Leveling Document
Job descriptions are the document that shapes the pipeline before a single candidate applies. A JD that describes the work specifically — not "collaborate cross-functionally" but "partner with product and design on the technical feasibility of the quarterly roadmap" — attracts different candidates than a generic template. And a leveling rubric that's specific enough to run calibration against saves three debates per hire.
The caveat: Claude cannot post to LinkedIn, Greenhouse, or any job board. The output here is a draft you review and post yourself.
Paste your role requirements, team context, and level criteria. Claude produces the full JD and leveling document.
I need to write a job description and leveling document for [role title] on the [team name] team. Here's the context:
What this person will actually do: [paste the specific work — the actual responsibilities, not the generic template version]
What we're looking for: [paste the skills and behaviors — technical skills, ways of working, experience signals]
Why this role matters to the business right now: [paste the business context — what the team is building, what this hire unlocks, why we're hiring now]
Team context: [describe the team — size, current composition, how this role fits, what success looks like in 6 months]
Leveling context: [paste your level criteria or describe the levels — what distinguishes L4 from L5 from L6 for this role]
Write a full job description including:
- Role Summary: 3–4 sentences — what this person does, what team they're on, what impact they have; specific, not generic
- What You'll Do: 5–7 bullets — specific work, not generic responsibilities; each bullet should describe something a candidate could picture themselves doing
- What We're Looking For: 5–6 bullets — skills and behaviors, not just years of experience; include the behaviors that predict success on this team
- Why This Role Matters: 2–3 sentences — business context, what you're building, why now
- Team Context: 3–4 sentences — team structure, how this role fits, what good looks like in the first 90 days
Then write a separate Leveling Rubric section for internal calibration:
- One column per level (e.g., L4/L5/L6 or Senior/Staff/Principal)
- For each level: Scope of Work | Technical Depth Expected | Collaboration and Influence Expected | Indicators This Person Is Above/Below Level
The leveling rubric section is the part that most JDs skip and most hiring loops need. Having it written before the loop starts means your debrief calibration has a reference point. Without it, every calibration is a negotiation from scratch. For operations managers who run hiring processes and build workforce documentation, Claude AI for Operations Managers covers the operational layer of hiring and team scaling.
Why Claude Over ChatGPT for Engineering Leadership Work
100K+ context window. Paste a full RFC thread with comments and all prior revisions. Paste a quarter of 1:1 notes — every session summary from the last thirteen weeks. Paste the complete job description, the level rubric, and six months of team context. Claude processes the full document in one session with no truncation. That matters when your performance review document needs to synthesize a year of work, not a summary of a summary.
Conservative. Claude will not fabricate architecture patterns to fill gaps in your RFC. It will not invent candidate competency scores you didn't supply. It will not misrepresent a technical trade-off in an exec update. When the input is thin, the output says so. For engineering leaders who sign off on documents that shape hiring decisions, architecture choices, and organizational calibration, the conservative default is the right one. Claude vs ChatGPT: Which AI Is Better for Work covers this distinction in detail.
Projects per initiative. Build one Claude Project for Q3 hiring. One per major RFC. One for the current performance cycle. Load the relevant context at the start — the role requirements and team composition for hiring, the system design context for the RFC, the level rubric and 1:1 summary for perf. Every document you produce from that Project benefits from accumulated context. The JD, the hiring scorecard, the debrief summary, the offer framing — all produced with the same role context in scope.
Structured output fidelity. RFCs have specific sections. Performance reviews have specific sections. Scorecards have specific columns. Sprint retros have specific structure. Claude holds those structures across long, complex documents — the eight-section RFC stays organized through to the Migration Plan, the performance review doesn't collapse the Growth Areas and Level Assessment into one paragraph. That fidelity matters when you're producing documents that engineers, HR, and executives will read and reference.
Practical Tips for Engineering Leaders
One Project per initiative. One Project for the current Q3 hiring cycle. One per major RFC or architecture decision. One for the current performance review cycle. Context compounds — the fourth document you produce in a Project is better than the first because Claude has seen your team's context, your writing style, and your technical framing. Start the Project at the beginning of the initiative, not when you're staring at a deadline.
Notes in / structured docs out. Paste your raw 1:1 notes from the quarter. Paste your messy bullet points from the whiteboard session. Paste your interview observations exactly as you typed them during the call. Claude produces the structured version; you iterate on it. The discipline is: never ask Claude to produce a document without supplying the underlying substance. The analytical judgment is yours. The blank-page problem is Claude's.
Specify the reader. "This is for the CPO, no technical jargon, she cares about user impact and delivery timeline" produces a very different exec update than "this is for the engineering team." "This is for the calibration committee who will push back on the level assessment" produces a very different performance review than "this is for the engineer." The reader's context shapes the framing, the level of evidence, and the register. Always include it.
Use it for the blank-page paralysis moments, not the final polish. The hardest part of every document is getting from nothing to a structured draft. That's where the time goes — staring at a blank doc, knowing what you want to say but not having the structure on screen to react to. Claude handles the 0→1. Once there's a draft, your edits are fast and specific. The blank page is the problem Claude solves.
The Playbook
If you want every prompt above — refined, tested, and organized by use case — plus prompts for engineering roadmap narratives, technical incident post-mortems, promotion case documents, board-level engineering updates, and the full library of professional workflows across every business function, that's what The Complete Claude Playbook is.
$27. Instant access. The prompts that handle the writing layer.