10 AI Prompts I Use as an Engineering Manager

I've managed engineering teams for long enough to know the pattern: half of the job is technical decisions, and the other half is the writing that surrounds those decisions. 1:1 agendas. Performance reviews. Postmortems. Status updates the VP insists on. Hiring rubrics that no one will ever read until it's time to argue about a candidate.

Here are the 10 prompts that actually made my job easier. Each one follows a four-part structure I'll explain at the end. Every example output below is real, edited only for length.

1. The 1:1 Agenda That Surfaces the Real Topic

The biggest 1:1 mistake is walking in with your own agenda. This prompt flips it: it asks the model to generate what your report probably wants to talk about, based on what's happened since the last 1:1. You bring that draft, not a topic list.

Role: Staff engineer who has managed 20+ reports.
Context: I have a 30-minute 1:1 with [REPORT NAME] in two hours.
Their role is [ROLE]. Since our last 1:1 (one week ago):
- They shipped [THING SHIPPED].
- They raised a concern about [CONCERN].
- They were blocked on [BLOCKER].
- Their last 1:1 topic was [LAST TOPIC].
Constraints: Do NOT suggest topics I want to discuss.
Suggest only topics THEY are most likely to bring up —
including the one they're avoiding. Max 5 topics.
For each, write one sentence on why it's likely on their mind.
Output: A numbered list. The last item must be the
uncomfortable one (the promotion question, the burnout flag,
the conflict with a teammate). Label it "the one they won't raise first".

Real output (report = mid-level IC, last week shipped a refactor they were nervous about):

1. The refactor postmortem. They want to know if the production hiccup on Thursday will be held against them.
2. The new project assignment. You mentioned a new initiative; they're deciding whether to volunteer.
3. The pair-programming request from the junior. They're unsure if it's a time sink or a growth move.
4. The pay band question (they read a levels.fyi post this week).
5. The one they won't raise first. They're quietly checking if you think they're senior material — and whether they should wait or push.

That fifth item is what every 1:1 prompt should surface. The other four are the setup.

2. The Performance Review Without the Praise Sandwich

Most performance reviews read like Mad Libs: "[Name] is a strong contributor who [generic verb] [generic noun]." This prompt forces specifics — and refuses the "areas for growth" hedge.

Role: Engineering manager writing a calibration-ready review.
Context: Write the review for [NAME], [LEVEL], over [PERIOD].
Their concrete work this period, in five bullets:
- [IMPACT 1 with a number]
- [IMPACT 2 with a number]
- [IMPACT 3]
- [BEHAVIOR 1 — how they operated]
- [BEHAVIOR 2 — how they operated]
Constraints: No sentence may contain the words "consistently",
"strong", "valued", or "team player". Every impact claim must
reference the number or be cut. The "areas for growth" section
must name ONE specific behavior, the situation it appeared in,
and the suggested replacement behavior. Do not write more than
one growth area.
Output: Two sections. "Impact" (3 sentences max) and
"One thing to change next period" (2 sentences max).

Real output (impact = led migration that cut p95 latency 40%):

Impact: [Name] owned the API migration that reduced p95 latency from 420ms to 250ms (40%) and unblocked two downstream teams who had been rate-limiting around it. They ran the rollout in four feature-flagged stages, which meant the single rollback (stage 3) cost 20 minutes of degraded traffic instead of an outage. They also ran three brown-bag sessions that brought three other engineers to the point of shipping independently on the new pattern.

One thing to change next period: In the Q3 design review, you presented three options without recommending one, which extended the meeting by 45 minutes and split the room. Next time, present your recommendation in the first two minutes and use the rest of the meeting to defend or revise it.

The word "consistently" is a tell. If you can't name the specific instances, you don't have enough evidence for the review.

3. The Architecture Decision Record That Survives the Meeting

Most ADRs die in the meeting where someone says "wait, did we consider X?" This prompt forces the alternatives section to be real, not decorative.

Role: Principal engineer writing an ADR for a skeptical audience.
Context: We are deciding [DECISION]. The proposed option is
[OPTION A: short description + one concrete reason we picked it].
The alternatives seriously considered are:
- [OPTION B]
- [OPTION C]
Constraints: For EACH alternative, write exactly three sentences:
(1) the scenario where it would have been the right call,
(2) the specific reason we rejected it, (3) the trigger that
would make us revisit it. No "this option was less optimal" —
name the failure mode.
Output: ADR with sections Status, Context, Decision, Consequences,
Alternatives. Max 400 words total.

Real output (decision = adopt Postgres for the new billing service):

Status: Proposed
Context: Billing service must be ACID-compliant, auditable, and support read replicas within 6 months.
Decision: Postgres 16.
Consequences: Team learns Postgres ops; we gain row-level security for tenant isolation; we inherit one more data store in the fleet.
Alternatives:
MongoDB would have been right if billing documents were schemaless and append-only. Rejected because financial reconciliation requires transactions across multiple collections, which Mongo doesn't support cleanly. Revisit if the billing model becomes event-sourced only.
DynamoDB would have been right if the access pattern were single-key lookups at high QPS. Rejected because our reporting workload scans by date range, which is the case Dynamo is worst at. Revisit if reporting moves to a separate OLAP store.

The third sentence on each alternative — the revisit trigger — is what stops the "did we consider" re-litigation six months later.

4. The Blameless Postmortem That Doesn't Drift

Postmortems drift into either blame or vague "process improvements." This prompt forces the five-whys structure and refuses generic action items.

Role: SRE-trained incident commander writing a blameless RCA.
Context: Incident on [DATE]. Summary: [WHAT HAPPENED, 2 SENTENCES].
Impact: [DURATION, USER COUNT, REVENUE OR DATA IMPACT].
Detection: [HOW WE FOUND OUT — alert, user report, etc.].
Timeline: [3-6 KEY EVENTS with timestamps].
Constraints: Use the five-whys structure for root cause.
Each "why" must point to a system or process, never a person.
No action item may be "add more monitoring" or "improve
communication" — name the specific dashboard, runbook, or
checklist. Exactly 5 action items, each with an owner and
a due date placeholder.
Output: Sections Summary, Impact, Timeline, Root Cause (5 whys),
Action Items.

Real output (incident = checkout API 500s for 47 minutes):

Root Cause (five whys):

1. Why did checkout return 500s? The payment provider's webhook timeout leaked a database connection.
2. Why did the connection leak? The webhook handler didn't have a finally-block releasing the connection on timeout.
3. Why wasn't there a finally-block? The handler was copied from a non-transactional code path two quarters ago.
4. Why was copy-pasted code in production? The PR review checklist doesn't include "resource cleanup on timeout".
5. Why doesn't the checklist include it? The checklist was written for CRUD endpoints, not for external-webhook handlers — a class of endpoint added in the last 6 months.

Notice the fifth why points at the checklist, not the developer. That's what makes it blameless without making it useless.

5. The On-Call Runbook From a Loose Slack Thread

Every team has the Slack thread where someone explained how to recover from a thing. It's never been written down. This prompt turns the thread into a runbook the next on-call can actually follow at 3am.

Role: On-call engineer who has been paged at 3am and needs a runbook.
Context: Here is the Slack thread where [EXPERT] explained
how to recover from [INCIDENT TYPE]:
"""
[PASTE THE SLACK THREAD VERBATIM, INCLUDING THE WRONG TURNS]
"""
Constraints: Produce a runbook with numbered steps. Each step
must be one action a single person can complete in under
5 minutes. Mark any step that requires a second pair of eyes
with "⚠ second person required". Include a "What NOT to do"
section with the wrong turns from the thread. No step may
reference "the usual way" or "the standard procedure" —
spell it out.
Output: Sections Detection, Immediate Action (numbered steps),
Verification, Rollback, What NOT to do.

Real output (incident type = Redis cache corruption):

Immediate Action:

1. SSH to the cache node (see runbook-redis-access).
2. Run redis-cli -h <host> -a <password> INFO keyspace and screenshot the output. (This is your before-state.)
3. Identify the corrupted key prefix from the alert payload.
4. Run redis-cli ... --scan --pattern '<prefix>*' | head -50 to list affected keys.
5. ⚠ Second person required: Decide whether to flush the prefix (fast, loses cache) or delete individual keys (slow, safe). If in doubt, flush the prefix — cache is rebuildable.
6. Flush: redis-cli ... EVAL "return redis.call('del', unpack(KEYS))" 0 <prefix>* (wait — this is wrong, see What NOT to do #1).
7. Correct flush: redis-cli ... --scan --pattern '<prefix>*' | xargs redis-cli ... del

What NOT to do:

1. Do NOT use EVAL "return redis.call('del', unpack(KEYS))" 0 <prefix>* — unpack truncates at 8000 keys and silently drops the rest. This is the bug that made the March incident worse.

The "What NOT to do" section is the most valuable part. Every Slack thread contains the wrong attempts — those wrong attempts are the actual lessons.

6. The Sprint Retro That Produces ONE Experiment

Retros produce 12 action items that no one owns. This prompt forces one experiment with a kill criterion.

Role: Agile coach who has run 200 retros and is tired of
action-item graveyards.
Context: The team's retro board:
- What went well: [3 ITEMS]
- What didn't: [3 ITEMS]
- Ideas: [3 ITEMS]
Constraints: Pick exactly ONE idea. Frame it as an experiment
with: the hypothesis, the change, the measurement, and the
kill criterion (the signal that tells us to stop the experiment).
Do not produce more than one experiment. Do not produce a list
of "action items". The kill criterion is non-optional.
Output: One experiment card.

Real output (retro idea = "shorter standups"):

Experiment: Timed standup with a 90-second cap per person
Hypothesis: Standups run over because no one enforces the per-person limit; a visible timer will make the limit real.
Change: Use a phone timer passed around the circle. Each person gets 90 seconds. Timer resets between people.
Measurement: Standup length (target: under 12 minutes for a 6-person team). Survey after 2 weeks: "did you feel heard?"
Kill criterion: If average standup length is still over 15 minutes after 2 weeks, OR if "did you feel heard" drops below 60% yes, kill the experiment and revisit.

The kill criterion is what makes an experiment different from a resolution. Resolutions drift; experiments get reviewed.

7. The Status Update the VP Can Read in 20 Seconds

Your VP doesn't want the architecture. They want to know: are we on track, what's at risk, and do you need anything. This prompt enforces that.

Role: Engineering manager writing a weekly status update for
a VP who reads 30 of these every Friday.
Context: Team: [TEAM NAME]. Headcount: [N]. Quarter goal:
[ONE SENTENCE GOAL]. This week's work, in 5 bullets:
- [BULLET]
- [BULLET]
- [BULLET]
- [BULLET]
- [BULLET]
Constraints: Total length under 120 words. The first line
must be either "On track" or "At risk" — nothing else.
If "At risk", the second line must state the single biggest
risk and what you need to resolve it. No technical jargon
the VP would have to look up. No "making progress" or
"continuing to" — those are filler.
Output: 4 sections. Status (1 line), Shipped (3 bullets max),
Next week (3 bullets max), Needs (1 line or "none").

Real output:

Status: On track
Shipped: Checkout API cut p95 from 420ms to 250ms. Two downstream teams unblocked. Billing service schema frozen for Q3.
Next week: Migrate staging traffic to new Postgres cluster. Final review of the on-call runbook rewrite. Hire closed — start date confirmed for the 15th.
Needs: None.

120 words. The VP reads it in 20 seconds. You get your Friday afternoon back.

8. The Hiring Rubric From a Messy Job Description

Most job descriptions are a wishlist. Most interview rubrics inherit the wishlist and become uncalibratable. This prompt turns a vague JD into a rubric with testable criteria.

Role: Hiring manager who has debiased 50+ interview loops.
Context: Here is the job description:
"""
[PASTE THE JD]
"""
Constraints: Produce a rubric with exactly 4 signals.
For each signal: (1) the name, (2) how to test it in a
45-minute interview (specific question or exercise),
(3) what a "strong hire" answer looks like in 2 sentences,
(4) what a "no hire" answer looks like in 2 sentences.
Do not include "culture fit" as a signal. Do not include
"passion". Signals must be observable in the interview,
not inferred.
Output: A 4-row rubric table.

Real output (JD = senior backend engineer, vague requirements):

1. Systems thinking under partial failure
Test: "Walk me through what happens when our checkout API returns 500 for 1% of requests but 200 for the rest. Where do you look first?"
Strong hire: Asks about the request distribution first (time, user cohort, region) before jumping to logs. Names at least three hypotheses ranked by likelihood.
No hire: Jumps to "restart the server" or "check the logs" without considering whether the 1% is a deploy, a feature flag, or a downstream provider.

2. Code review judgment
Test: Show a 200-line PR with one subtle bug and one style issue. "What's your review comment?"
Strong hire: Finds the bug or asks a question that would reveal it. Mentions the style issue last, or not at all.
No hire: Leads with the style issue. Doesn't engage with the logic.

3. Tradeoff communication
Test: "Pick a technical decision you made recently. Argue both sides."
Strong hire: Can steelman the option they rejected. Names the specific signal that would flip the decision.
No hire: Can only argue their own side. Cannot describe the alternative's strengths.

4. Ownership of outcomes
Test: "Tell me about a thing that shipped and went wrong."
Strong hire: Uses "I" for decisions and "we" for outcomes. Describes what they changed in their own process afterward.
No hire: Blames the team, the requirements, or luck. No change to their own process.

The "no culture fit, no passion" constraint is the key. Both of those are where bias hides. Observable signals are where calibration starts.

9. The Tech-Debt Pitch for Non-Technical Stakeholders

Engineering says "we need to refactor." Product says "what does that buy us?" This prompt translates refactoring into business language without lying.

Role: Engineering manager pitching a tech-debt investment
to a product and finance audience.
Context: The tech debt is [DESCRIBE THE DEBT — what it is,
how it got there, what it currently costs us].
The audience cares about: velocity, risk, and cost.
They do not care about: code elegance, the "right way",
or what the framework authors recommend.
Constraints: No technical terms without an in-line
plain-English definition. The pitch must include:
(1) the current weekly cost in engineer-hours,
(2) the projected weekly cost if we do nothing for 6 months,
(3) the investment in engineer-weeks to fix it,
(4) the payback period, (5) the one risk of doing the work
that's worth naming. Total length under 250 words.
Output: A one-page pitch with those 5 labeled sections.

Real output (tech debt = the billing-service ORM that doesn't support transactions):

Current weekly cost: ~12 engineer-hours across the team — roughly 1.5 engineer-days per week spent on manual reconciliation workarounds.
Projected cost in 6 months (do nothing): ~22 hours/week. The workaround count grows roughly linearly with customer count, and we're adding ~40 customers/quarter.
Investment to fix: 3 engineer-weeks (one engineer, full-time, for a quarter of a sprint cycle). Includes the migration, the rollback path, and the runbook.
Payback period: ~11 weeks at the current run-rate; faster as we add customers.
Risk worth naming: During the 3-week migration, the billing service will be in a hybrid state (old ORM for reads, new ORM for writes). A rollback bug in that window could require a manual reconciliation — the same work we're trying to eliminate.

Numbers beat adjectives. The "risk worth naming" section is what gets the pitch approved — it's the line that signals you've thought about it.

10. The Onboarding Doc a New Hire Can Actually Follow

Most onboarding docs were written by someone who forgot what it was like to be new. This prompt forces a day-1 / week-1 / month-1 structure with specific tasks.

Role: Engineering manager writing onboarding for a new hire
who starts Monday.
Context: Role: [ROLE]. Team: [TEAM]. Stack: [KEY TECH].
The new hire is at [LEVEL] and is expected to ship their
first PR within [TIMEFRAME].
Constraints: Structure as Day 1, Week 1, Month 1.
For each section, list the specific tasks (not "get set up" —
"clone repo X, run command Y, expect output Z"). Each task
must have an expected outcome so the new hire knows when
they're done. Include the names of the people they should
ask for help, not "your buddy" or "the team". No task may
take longer than half a day. Mark any task that requires
access with "🔑 request access on Friday before you start".
Output: 3 sections, max 15 tasks total.

Real output (role = backend engineer, expected first PR in week 1):

Day 1

1. 🔑 Request access to the staging cluster, the on-call Slack channel, and the billing repo (ask Priya in #team-payments).
2. Clone the billing-service repo. Run make dev. Expected: local server on :8080, health check at /health returns 200.
3. Read the ADR on the Postgres decision (link in the repo README). Expected: you can name the one alternative we rejected and why.
4. 1:1 with your manager (that's me) at 3pm. Bring one question.

Week 1

1. Pick up the "good first issue" tagged in the repo. Expected: PR open by Thursday, merged by Friday.
2. Shadow one on-call rotation (ask Marco). Expected: you understand what pages and what doesn't.
3. Read two postmortems from the last quarter (linked in the runbook repo). Expected: you can describe one systemic fix.

Month 1

1. Own a small feature end-to-end. Expected: design doc reviewed, PR merged, deployed to staging.
2. Run a code review on someone else's PR (ask to be assigned). Expected: at least one substantive comment, not just nits.
3. Present a 10-minute talk at the team meeting on something you learned. Expected: slides or a doc, not just talking.

The "expected outcome" on every task is the whole prompt. Without it, the new hire stares at "get set up" and doesn't know if they're done.

The Structure Behind All 10 Prompts

Every prompt above follows the same four-part structure. Once you internalize it, you can write your own.

Role — Not "act as an engineering manager" — "act as a staff engineer who has managed 20+ reports". The specificity of the role is the biggest single lever on output quality.

Context — Concrete inputs: the report's name and level, the incident timeline, the JD verbatim. Vague context produces vague output.

Constraints — This is where most prompts fail. A constraint is a hard rule: word count, banned words, required structure, a specific first sentence. Constraints turn generic output into something you'd actually ship.

Output format — "A 4-row rubric table." "Five numbered topics." "A one-page pitch with five labeled sections." Without an output format, you get paragraphs you have to edit down.

How I Tested Each Prompt

I didn't ship any of these on the first output. Each one went through the same test:

1. Run it three times with the same inputs. If the outputs vary wildly, the prompt is too loose — add a constraint.
2. Run it on a different situation than the one it was written for. If it only works for one team, it's overfit — generalize the context.
3. Read the output aloud to a peer. If they can guess it was AI-written, the prompt failed. Good output reads like you wrote it under deadline.
4. Cut anything that could apply to any team. "Improve communication" applies to everyone and helps no one. Specificity is the test.

The Full Library

Every prompt above is open-sourced — but it's 10 out of a larger library I use for the writing part of engineering management. The full set covers 1:1s, performance reviews, postmortems, ADRs, hiring, onboarding, tech-debt pitches, sprint planning, stakeholder updates, and the inevitable skip-level meeting.

If you want the whole library rather than copying prompts one at a time:

• Developer Product-Launch Prompt Pack ($9) — 7 prompts for launch tweets, Show HN posts, changelogs, release notes. The entry-level pack. Get it on Gumroad →
• Developer Productivity Prompt Library ($49) — 30 prompts for code reviews, PR descriptions, bug reports, test cases, API docs. Get it on Gumroad →
• SaaS Marketing Copy Prompt Pack ($49) — 25 prompts for landing pages, ad creative, objection handling, email sequences. Get it on Gumroad →
• AI Startup Operations Prompt System ($199) — 50+ prompts across 10 workflows for running an engineering org with AI. The one most relevant to the prompts in this article. Get it on Gumroad →
• AI Business Transformation Playbook ($999) — 100+ prompts and 12 workflows for rolling out AI across a whole company. Get it on Gumroad →

Or browse the full storefront — every product has a free sample you can read before buying.

That's the set. If you found even one prompt here useful, the easiest next step is the $9 launch pack — it's the lowest-risk way to see if the format works for you.

What EM prompt would you want next — skip-level prep, promotion packets, or RIF planning? I read the comments.