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.
Before the samples, here is a quick recap on what makes a failure story land - interviewers are looking for 2 things in your failure 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 (Full breakdown here - how to answer the failure question)
If you’re interviewing at Sr Manager or Director+, the scope of what counts as a meaningful failure is different, lets leave that for another day.
4 Sample Answers (examples you can make your own)
Most line manager failures I’ve seen (mine included) fall into four buckets. You only need one, maybe two for your interview prep.
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.
1. The talent 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.
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 coaching 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 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. 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 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.
The most common mistake in ‘manager’ failure stories
“Tell me about a time you failed.“
If your answer says “I underestimated the migration complexity and the project shipped six weeks late,” even if you nail the five-part arc down - your debrief will likely say “limited leadership signal.“
I’ve made this exact mistake myself as an early manager, and then seen countless other managers do the same. I gave them a story about debugging a system. They wanted a story about debugging myself.
A missed deadline is a project failure, it could happen to anyone on the team. The interviewer can’t tell from that story whether you’re a manager or a tech lead who was around when things went wrong. 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.
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.