Engineering managers don't own lines of code. They own systems, people, and outcomes — document all three.
Most engineering managers struggle with performance reviews for the same reason: your work is invisible by design. When you're doing it right, the team looks like it's running itself. That invisibility is a feature of good management — and a liability when review season comes.
This post gives you 75+ ready-to-adapt STAR examples organized by the seven areas that define great EM performance. Use them as drafts, not scripts — your specific metrics belong in the [BRACKETS].
How to Use These Examples
Read each example, identify the closest match to something you've actually done, then adapt the numbers and context to your situation. The structure (Situation / Action / Result) is the part to keep. The specifics are yours to fill in.
Every strong EM accomplishment answers one implicit question: What would have been worse without you?
Delivery and Execution
"Tell me about a time your team shipped something meaningful."
Example 1: My team had missed its last two quarterly targets — not due to poor engineering, but because scope kept expanding mid-sprint. I introduced a no-scope-change rule for sprints shorter than 3 weeks and held a half-day roadmap alignment session with Product every quarter. In the following 4 quarters, the team hit targets 3 times and reached 90% completion in the fourth. Stakeholder satisfaction in our quarterly survey went from 3.1 to 4.3 out of 5.
Example 2: A critical integration project was 6 weeks behind when I took it over mid-stream. I ran a root-cause session, identified 3 ambiguous requirements causing rework, and facilitated a 2-hour alignment meeting with Product and the external partner. We renegotiated scope to a shippable MVP, shipped 4 weeks later, and delivered the remaining features in a follow-on sprint 2 weeks after that.
Example 3: My team owned the payment retry service — it had 99.1% uptime, which sounds good until you calculate it's 7.9 hours of downtime per year on a service processing $2M/day. I led a reliability sprint: we identified the top 5 failure modes, added circuit breakers, and improved alerting. Uptime reached 99.94% over the next 6 months. Estimated revenue protected: $400K+.
Example 4: We had a major feature launch with a 6-week deadline set by a signed enterprise contract. I created a dependency map, identified 3 cross-team blockers 5 weeks out, escalated immediately, and negotiated parallel workstreams with two other teams. We launched on day 42 — 1 day early. The contract renewed and expanded.
"How do you handle a project that's going off the rails?"
Example 1: Three weeks into a 10-week project, I noticed the team was behind by 40% of estimated velocity. Rather than wait for the miss, I called an "honest accounting" session — no blame, just mapping what we knew vs. what we'd assumed. We found 3 requirements that were significantly more complex than estimated. I reset the timeline with stakeholders that week, not week 8. The project shipped 2 weeks late instead of the 6-week miss we were trending toward.
Example 2: A high-visibility data migration project hit a critical blocker: the source data had schema corruption affecting 12% of records. I stood up a war room, brought in a senior data engineer from another team, and we built a repair pipeline in 72 hours. We communicated daily status to 4 stakeholders. Total delay: 4 days on a 3-month project.
Team Health and Retention
"How do you retain strong engineers?"
Example 1: I inherited a team with 35% annual attrition. I ran 1:1s with every engineer in my first 3 weeks and asked one question: "What would make you stay?" The consistent answer was growth clarity. I built individual growth plans for each of the 7 engineers, tied to specific skills, projects, and timelines. Attrition dropped to 8% the following year.
Example 2: My strongest senior engineer had a competing offer. Rather than counter-offer on salary alone, I built a 12-month growth plan together — a new technical leadership role, ownership of a greenfield project, and a path to Staff. She stayed. 14 months later, I submitted her Staff promotion packet.
Example 3: I noticed 2 of my engineers were consistently working past 7 PM. I blocked their calendars for focus time, moved standup to 9 AM, and worked with Product to protect their sprint commitments from ad-hoc requests. Both engineers mentioned the change in our next engagement survey, scoring "workload sustainability" at 4.8 out of 5 — up from 2.9.
"How do you develop engineers on your team?"
Example 1: I had a mid-level engineer who was technically strong but consistently avoided presenting in design reviews. I gave her a low-stakes speaking opportunity — a 5-minute tech talk in our team meeting — then gradually increased scope. By the end of the year she was leading architecture reviews with stakeholders. She was promoted to Senior 11 months later.
Example 2: I identified that my team had a gap in distributed systems experience that was creating a single point of knowledge. I ran a 6-week internal study group — 45 minutes per week, paper + discussion. Three engineers got hands-on experience on a subsequent distributed architecture project they previously would not have been staffed on.
Example 3: A junior engineer was producing code that consistently failed review with architecture feedback. I paired with him on his next 3 PRs to model the thinking pattern, then had a senior engineer shadow-review his 4th. His PRs started passing first review within 6 weeks. He was promoted to mid-level the following cycle.
"How do you handle a performance issue?"
Example 1: An engineer was consistently missing estimates by 50-100% and not raising blockers proactively. I opened a direct conversation: I named the pattern specifically, asked what was making it hard to raise blockers earlier, and listened. He disclosed he was embarrassed to ask for help. I normalized it and set up a weekly blocker check-in. His estimation accuracy improved from 50% to 82% within one quarter.
Example 2: I had an engineer whose communication style was creating friction with Product — dismissive of requirements questions. I gave direct, specific feedback: I described the behavior, the impact (Product stopped including him in sessions), and what I needed to see change. I followed up monthly. Six months later, our PM proactively mentioned the improvement.
Technical Leadership
"How do you influence technical direction without writing the code?"
Example 1: My team was accumulating technical debt faster than it could repay it — new features were taking 40% longer than estimates. I introduced a "20% debt budget" policy: every sprint, 20% of capacity was reserved for refactoring. After two quarters, feature velocity improved by 28% as measured by story points completed per sprint.
Example 2: I noticed 4 engineers had different mental models of our caching strategy, leading to inconsistent implementations. I facilitated a half-day architecture session, produced a single Architecture Decision Record (ADR), and had every engineer review it. New caching code became consistent within a sprint. We reused the ADR process for 3 subsequent architectural decisions.
Example 3: My team owned a critical API used by 8 downstream services with no versioning strategy — any change risked breaking consumers. I wrote an RFC for a versioning strategy, circulated it to the 4 affected teams, incorporated feedback, and drove adoption. We migrated to versioned endpoints in 6 weeks with zero downstream incidents.
"How do you manage technical risk?"
Example 1: Before a major third-party dependency upgrade, I requested a risk session with the team. We identified 5 integration points that could break, assigned an owner to each, and built a rollback plan. The upgrade deployed without incident. We documented the process — the next upgrade took 40% less time because the playbook existed.
Example 2: Our on-call rotation was causing alert fatigue — 4 engineers were paged 6-9 times per week. I led an alert hygiene project: we audited every alert for actionability, eliminated 34 noisy alerts, and set thresholds based on historical data. Mean time to acknowledge dropped from 18 minutes to 4 minutes. Pages per week dropped from 7.2 to 2.1.
Cross-Functional Collaboration
"How do you work with Product and Design?"
Example 1: The relationship between my team and our PM was adversarial — engineers felt requirements were thrown over the wall. I proposed a joint discovery process: engineers attend the first user research session for any major feature. Within two quarters, "thrown over the wall" complaints disappeared and we started shipping smaller, better-targeted features.
Example 2: We were consistently building features that required 3+ rounds of design revision. I proposed a "design review as a gate" — no development starts until the design has been reviewed by at least one engineer for technical feasibility. Revision cycles dropped from 3.2 to 1.4 per feature.
Example 3: My team and the mobile team had conflicting API contracts — we were shipping backend changes that broke their build. I set up a weekly 30-minute contract sync with their EM. Breaking changes dropped from 4 per quarter to 0. We formalized the sync as a standing recurring with an agenda template.
"Tell me about a time you influenced something beyond your team."
Example 1: I identified that 4 teams were independently building variations of the same internal notification system. I wrote an RFC, presented it to 3 EMs and a VP of Engineering, got buy-in, and drove implementation over 6 weeks. We eliminated 14K lines of duplicate code across the org and now maintain one service instead of four.
Example 2: Our on-call rotation was causing burnout across 3 teams. I organized a cross-team "pager fatigue summit," mapped all alerts to their true owners, and redesigned the escalation tree with the other two EMs. Pages dropped from 7.2/week to 2.1/week across all 3 teams. The format became a quarterly ritual.
Example 3: The company's engineering onboarding was 2 weeks long and was producing engineers who still felt lost after 60 days. I volunteered to redesign it. I interviewed 12 engineers who had joined in the last 6 months, identified the 5 highest-friction points, and rebuilt the first 2 weeks with hands-on projects instead of documentation. The next cohort's 60-day confidence survey went from 2.8 to 4.1 out of 5.
Business and Strategic Impact
"How do you connect your team's work to business outcomes?"
Example 1: I introduced a "business impact" field to every epic in Jira. Engineers had to write one sentence connecting their work to a company metric before the ticket moved to In Progress. After two quarters, engineers were proactively quantifying their own impact in sprint demos — without being asked.
Example 2: My team owned the search feature. I built a model connecting search quality metrics to conversion data from our analytics team. When search quality improved by 12%, we could show it drove a 3.4% lift in checkout starts — $1.1M in additional quarterly revenue. Three other teams adopted the model to justify their own roadmap investments.
Example 3: Engineering was often deprioritized in roadmap planning because Product could not translate technical work into business value. I started attending quarterly planning with a one-page "Engineering Impact Report" mapping our last quarter's work to revenue, cost, and risk metrics. Engineering projects started getting funded at 80% of requested capacity — up from 60%.
"How do you make the case for technical investment to non-technical stakeholders?"
Example 1: I needed to justify a 6-week refactoring project to a VP with no engineering background. I built a simple model: current defect rate × average engineer-hours to fix × hourly cost = $180K/year in hidden engineering cost. The refactor would cost $90K in opportunity cost and eliminate 70% of the defects. Approved in one meeting.
Example 2: I needed executive buy-in for a 9-month monolith-to-microservices initiative. I framed it as a business enabler: "Today, shipping any feature takes 6 weeks because of deployment coupling. After this project, it takes 2." I modeled the productivity improvement and showed how it would let us ship 3 additional major features per year. The initiative was funded.
Communication and Stakeholder Management
"How do you communicate upward?"
Example 1: I implemented a weekly async status update sent every Friday to my VP, Director of Product, and Design lead. Format: 3 bullets on what shipped, 2 on what's at risk, 1 ask. It replaced 45 minutes of weekly sync meetings and created a written record both parties could reference. Three other EMs adopted the format within a quarter.
Example 2: We had a high-profile project slip by 3 weeks due to an infrastructure dependency outside our control. Rather than waiting for the exec team to notice, I sent a proactive update 4 weeks before the original deadline — with the dependency documented, the revised timeline, and two mitigation options. No escalation drama. The VP thanked me specifically for the early warning.
Example 3: I was managing a reorg affecting 6 engineers and 2 teams. I sent a written summary of the changes, rationale, and timeline to all affected engineers before the official announcement, and held a 30-minute Q&A the same day. Not a single engineer learned about the reorg from the company all-hands — they'd heard it from me directly.
"How do you give feedback?"
Example 1: I had an engineer who consistently missed commitments without communicating blockers. I gave the feedback in our 1:1 — specific behavior, specific impact, specific ask. I followed up in each of the next 4 1:1s with one question: "How did this week go on the communication piece?" After 6 weeks, the behavior changed. I cited it in his review.
Example 2: A senior engineer had earned a reputation for being dismissive in code reviews — junior engineers were avoiding submitting PRs to him. I shared anonymized feedback I'd gathered, described the impact, and asked what was driving the behavior. It turned out he was rushed. We blocked 30 minutes in his schedule for intentional PR reviews. Junior PR submission rates recovered within a month.
Growth and Learning
"What did you learn this year that changed how you manage?"
Example 1: I learned I was too involved in technical decisions, which was stunting senior engineer growth. I ran an experiment: for one sprint, I reviewed but did not comment on architecture decisions unless explicitly asked. Three engineers stepped up in ways they hadn't before. I made it a permanent practice and started tracking "decisions made without EM input" as a team health metric.
Example 2: After losing two engineers in Q1, I read research on manager-driven attrition and realized my feedback style was perceived as overly critical. I changed my 1:1 structure to lead with "what's going well" before anything developmental. In the next engagement survey, my team's "psychological safety" score went from 3.2 to 4.4 out of 5.
Example 3: I was managing through a period of high ambiguity — our org was reorganizing. I noticed my team's anxiety was rising and my communication was becoming vague in an attempt to avoid speculating. I switched to an explicit "here's what I know, here's what I don't, here's what I'm doing about the uncertainty" format in our team meetings. Team anxiety visibly dropped within two weeks.
"How do you grow as a manager?"
Example 1: I identified that I had a blind spot around conflict avoidance — I was letting disagreements between engineers persist too long before intervening. I asked a peer EM who was known for direct intervention to debrief with me after our team syncs. Her feedback surfaced 3 specific moments I had missed. I intervened in the next conflict within 48 hours instead of waiting 2 weeks. The team noticed.
Example 2: I joined an external engineering leadership peer group of 8 EMs from non-competing companies. We meet monthly. In the last year I've adopted 4 practices from peers: a structured career ladder, a sprint retro format, an async status update template, and a blocker escalation protocol. All 4 are now standard on my team.
Quick Reference: EM Accomplishment Template
Use this structure for every significant accomplishment:
SITUATION: [Context — team size, timeframe, what was the state before you acted?]
PROBLEM: [What specifically wasn't working, and what was it costing the team or business?]
ACTION: [What specifically did you do? Be precise about your role vs. the team's role.]
RESULT: [Measurable outcome — metric, timeline, scope, business impact]
Example filled in:
- SITUATION: Team of 8 engineers, 28% annual attrition, two consecutive missed quarters
- PROBLEM: Engineers felt unclear on growth paths; roadmap changed too frequently to build momentum
- ACTION: Ran skip-level 1:1s to surface root causes; published 6-month roadmap with explicit growth tracks per engineer; introduced 6-week delivery chunks with no mid-sprint scope changes
- RESULT: Attrition dropped from 28% to 8% in 12 months; team hit quarterly targets 3 of 4 subsequent quarters
FAQ
What accomplishments matter most for an engineering manager performance review?
Delivery (did your team ship?), team health (retention, growth, satisfaction), and business impact (does leadership know what your team's work was worth?). Technical accomplishments matter but they're table stakes — what differentiates EMs at senior levels is organizational impact.
How do I write accomplishments if my team did all the work?
Your job is to create the conditions for the work to happen. Document the systems you built, the blockers you removed, the people you developed. "I created the conditions for 8 engineers to ship X" is a legitimate and important statement.
How do engineering manager accomplishments differ from IC accomplishments?
IC accomplishments focus on output you personally created. EM accomplishments focus on outcomes your team delivered and the conditions you built to make them possible. ICs own lines of code. EMs own systems, processes, culture, and people development.
How do I quantify people management accomplishments?
Track retention rate, promotion rate, time-to-promotion, engagement survey scores, and hiring yield. These are harder to collect retroactively — set up a simple tracking doc now and update it quarterly.
What if my team had a bad year?
Document what you learned and what changed. Owning a hard year with clear-eyed analysis and specific changes made is more compelling than a smooth year with no visible growth.
Your Next Step
The best EM accomplishments don't get written in review season. They get documented every week, as the work happens.
Work Wins takes 10 minutes a week to log. By the time you need them, your evidence file is already built.
Ready to Track Your Wins?
Stop forgetting your achievements. Download Work Wins and start building your career story today.
Download Free on iOS No credit card required