Tell Me About a Time You Failed - 4 Sample Answers for Managers
A 'missed deadline' or a 'technical failure' are BAD failure answers for manager interviews. Instead, here are 4 stories covering - talent, delegation, coaching, and relationship failures.
Most manager failures I’ve seen (mine included) fall into four buckets listed below. You only need one, maybe two for your interview prep. Pick what resonates most with your experience, and then scroll down fow full sample answers.
The talent retention failure
You lost someone you should have kept.The delegation failure
You held too much yourself, and your team stopped taking on more independently.The performance management failure
You waited too long to address underperformance because you didn’t want to be “that manager.”The relationship failure
You were too unilateral with a cross-functional partner.
Why these failure stories work well for manager interviews?
These answers address the specific signals that interviewers are looking for. If you’re a manger and your answer to “tell me about a time you failed” says says “I underestimated the migration complexity and the project shipped six weeks late,” even if you nail the delivery - your debrief will likely say “limited leadership signal.“
The interviewer can’t tell from that story whether you’re a manager or a tech lead. On the other hand, a people failure - losing a high performer, mis-judging a coaching case, burning a cross-functional relationship - that can only happen to someone in the manager role. That’s the signal they’re hunting for.
If you're reading these and thinking 'I don't have any such management experience,' scroll to the end, I have an example for how to reframe a project failure so it still works for a manger interview.
If you’re not a manager, you might be on the wrong article. See the below instead for sample answers that work great for engineers:
Full sample answers for manager interviews
1. The talent retention failure
You lost someone you should have kept.
Context: Senior engineer on your team, strong performer, been asking for more scope. She was your most reliable person on a high-visibility project
Failure: You kept saying “next quarter” because the current project needed her where she was. “Next quarter” is sometimes manager-speak for “I don’t know yet, but the opportunity might reveal itself in time”
Diagnosis: You treated development as something you’d get to, instead of something you actively build
Action: She left for a team that gave her the tech lead role you’d been deferring. Two other engineers started asking about internal transfers within the month
Learning: By the time “next quarter” arrives, your best people have already made their decision
Behavior change: You now run quarterly growth conversations with every report, separate from perf, focused on what they want next and what you’re doing to get them there
If you’ve managed people for more than a year, you probably have one of these. Someone left and you know, honestly, you could have done more.
How to make your failure story land
Regardless of the story you choose, you need to signal 2 things in your answer: humility, and agency. You signal these by hitting 5 points: stating the failure, diagnosing it, showing what you did, naming the lesson, and proving the behavior changed. Check out the link below for a full breakdown on how to deliver this answer well.
2. The delegation failure
You held too much yourself, and your team stopped taking on more independently.
Context: Running a team of 6-8 engineers across multiple workstreams, two of which had dependencies on partner teams
Failure: You ran every cross-team sync yourself because you thought it was faster. You were also the only one talking to your skip-level about priorities. You’d built a team that worked great - as long as you were in every room
Diagnosis: Your tech lead told you the team felt like they were “just building what you decided.” Your skip-level didn’t know any of your engineers by name
Action: You’d optimized for speed and accidentally made yourself a single point of failure
Learning: You were the bottleneck, and you’d built the bottleneck yourself
Behavior change: You restructured so each engineer owned a workstream end-to-end, including the stakeholder relationship. Uncomfortable for a couple of weeks, but three people cited it as the most growth they’d had in their next perf cycle
3. The performance management failure
You waited too long to address underperformance because you didn’t want to be “that manager.”
Context: One engineer was consistently missing expectations - late on deliverables, shallow code reviews, your TL was picking up the slack - stretching to still meet deadlines
Failure: You kept giving them “one more sprint” because they were trying, and you told yourself they’ll get there. Meanwhile, your strongest engineers were carrying their work on top of their own and starting to burn out
Diagnosis: You were optimizing for your own emotional comfort, not the team’s. Being “nice” to one person meant being unfair to everyone else
Action: By the time you started the formal performance conversation, your top performer had already told you in a 1:1 that she was “thinking about what’s next” - and she wasn’t talking about the roadmap
Learning: Avoiding a hard performance conversation with one person can equate to creating a hard time for your whole team… they just might not be telling you about it
Behavior change: You now have a 4-week rule. Another similar concern came up last quarter, and after you provided lightweight feedback for 3 weeks in a row, you had had the hard conversation in week four.
If you haven’t had to manage someone out, you could use a version where you gave tough feedback too late, or avoided a performance conversation because you were telling yourself it would resolve on its own. That said, most companies expect explicit performance management experience - so elevate your story a bit if you can.
4. The relationship failure
You were too unilateral with a cross-functional partner.
Context: Shared initiative with a partner team, jointly funded, you owned the proposal
Failure: You built the entire roadmap without looping in the partner team’s EM
Diagnosis: The ideas were sound but the reaction was cold, they felt blindsided. Their EM escalated to your shared skip-level
Action: Spent the next two months rebuilding trust you’d burned. The initiative started 3 weeks late due to ‘lack of alignment’
Learning: Having the best doc doesn’t matter if the people who need to buy in feel blindsided by it
Behavior change: You now co-author anything that touches another team’s resources before it ever hits a review, for example <talk about an instance where you actually did it>. Adds a week upfront, saves months of friction
What if I only have project failures stories?
If you only have a project failure, it can still work but reframe it around the leadership call you got wrong, not the timeline. “The project was understaffed“ is a generic project failure, but “I didn’t push back on scope when I knew my team was stretched“ is a management failure.
One thing to watch: make sure your “what I changed” is structural, not just effort. Not “I worked weekends to fix it“ but “I changed how I run the team.“ Other structural changes are - a new 1:1 cadence, a delegation model, a co-authoring rule etc.
One last thing…
One last thing, your story should come from your actual experiences, so you can tackle the follow up questions. However, you can start with the samples above, at least one or two of those should feel familiar. Pick what you think you can carry, fill in the specific person, the specific project, the specific conversation - and that’ll be your own unique story.
New here? Start with Behavioral Interviews for EMs, Senior/Staff Engineers, PMs.