Reframing Failure: Turning Mistakes into Career Growth
Recently, I was in an interview and the interviewer said to me, “This is my favorite question: Tell me about a time that you failed.”
As an interviewer, I love this question. As a candidate, I hate it.
And for good reason.
If you answer honestly, it tells the interviewer a lot about you. Not just whether something went wrong, but how you think when it does. And you can’t hide.
Did you plan well in the first place?
Did you own your part in what happened?
Did you understand what was in your control and what was not?
Did you actually change anything afterward?
The best answers do not dodge the uncomfortable part. They lean into it. When you answer this question, the best interviewers start to hear what your patterns and behavior are, good or bad.
Step Back to Move Forward
Anyone who has spent time learning a skill, whether that is dancing, sports, public speaking or even learning something new at work knows improvement does not happen just by doing the thing over and over. At some point, you have to stop and ask: what worked, what didn’t and what needs to change?
That is what a retrospective is.
I have always made time to review the successes and failures of a project or initiative, whether it is mine or my team’s. Wins matter. But failures, frustrations, and messy outcomes teach you more than the victories ever will.
Some call it a debrief. Some people call it a post-mortem (some people find that to be a little to goulish, but I happen to like this term). In agile teams, it is often called a retrospective, or “retro.” Whatever you call it, the purpose is the same: to pause long enough to understand what happened before rushing into the next thing.
There are many ways to do this type of reflection, but the basics are this: key stakeholders come together, review facts, discuss successes and failures, decide what next steps are and then execute those next steps. (for more information on retros, check out this article)
A retro is not about blame. It is not a performance review in disguise. It is a structured way to ask: what happened here AND (most importantly) what should I do differently because of it?
You don't need to be a project manager to run a retro nor do you need a team to do it yourself.
How to Run Your Own Retro
The simplest version asks three questions:
What went well?
What did not go well?
What would I do differently next time?
If you want to go deeper, add a few more:
What surprised me?
What patterns am I noticing?
What do I want my future self to remember about this?
What can I stop/start/continue doing?
Write it in a notebook. Put it in a Google Doc. Use sticky notes, Miro, Notion, a whiteboard - whatever works for you.
The tool does not matter nearly as much as the habit.
What matters is doing it while the experience is still fresh enough to be useful. Wait too long, and you are no longer reflecting, you are reconstructing.
And one rule: do not let the retro end without next steps.
A list of observations with no action attached is just journaling. The point is to learn something and then actually change something.
The Lesson That Keeps Showing Up
On Brené Brown’s podcast, she asks every guest a question I have always liked and enjoyed hearing the responses:
“What is the lesson the universe keeps putting in front of you because you need to keep learning it?”
What I love about it is that there are people at the top of their game who also have experienced their own Perfection Ceiling. Their stories depict moments, pivots, transitions. It’s not about the lesson they only needed to learn once or even their biggest takeaway.
What is the lesson you keep needing to learn?
That question matters because recurring challenges usually point to something bigger than a one-off mistake.
If the same issue keeps following you from project to project, role to role, or team to team, it may not be bad luck. It may be a pattern.
And patterns are where the real work lives.
When Reflection Actually Matters
At every level: individual, team, or enterprise wide, the biggest problems are rarely the ones no one saw coming.
More often, they are the ones people noticed and failed to address.
That is why reflection matters - ignoring repeated issues almost always makes them worse.
The point of a retro is not to obsess over what went wrong. It is to make sure the same preventable problem does not keep showing up.
Back to the Interview
So, let’s say you’re in an interview. Knowing everything above, would you answer the question differently then you would have when I mentioned the question the first time?
Probably.
Because “Tell me about a time you failed” is not really about the failure.
It is about whether you can:
Reflect honestly
Take accountability
Learn from mistakes
Adapt your approach
Before your next interview, run a retro on a real professional setback.
Walk in prepared to say:
Here is what happened
Here is why it happened
Here is what I learned
Here is what I changed because of it
That last part is what separates a decent answer from a strong one.
One Last Thing
Perfection was never the goal. Adjustment is.
Even the most experienced professionals get things wrong. Some mistakes happen because of poor judgment.
Some happen because circumstances change. Some happen because not everything is within your control.
What matters is not pretending you never fail. What matters is whether you pay attention when you do. You are going to miss a cue sometimes. You are going to get something wrong. You are going to have projects that do not go the way you hoped.
The retro does not erase any of that. It just makes sure you show up next time a little smarter than you were before. Give yourself permission to be imperfect.
Just don't skip the debrief afterward.
-Kristina
