For a long time, I used the word “failure” too quickly.
- A meeting goes sideways? Failure.
- A plan takes longer than expected? Failure.
- I miss the “perfect” output on the first try? Failure.
- I took too long to complete a LeetCode problem? Failure.
That framing sounds honest, but for me it was expensive. It collapsed too many situations into one label and made it harder to see what actually happened. “Failure” felt final. It didn’t tell me what to do next.
The more “failures” I collected, the more I avoided trying new things. That created a fixed-mindset loop: judge quickly, protect ego, stop experimenting.
I think I got there from a mix of signals:
- school rewards right answers more than iteration
- culture praises outcomes more than process
- I spent years without understanding how my ADHD affected how I learned under pressure
Over time, I shifted: instead of assigning verdicts, I started treating challenges as feedback.
A challenge is not a failure. It is a signal.
This post is about that shift — the practical loop I use when challenges show up, and why it makes growth sustainable.
Why “Failure” Wasn’t Helping Me
I am not against accountability. I am against vague labels that slow learning.
When I called something a failure, I usually mixed together:
- execution gaps
- unclear communication
- bad assumptions
- context I could not control
- emotional reactions
- negative self-judgment
- impostor syndrome
Those are different problems with different fixes, but the word “failure” flattened all of them. The result was too much emotion and not enough signal extraction.
In my work, I already use feedback loops constantly: tests give signal on code, monitoring on systems, incidents on assumptions.
I realized I wasn’t applying that same logic to myself — no observability on my own process, just blame.
A challenge is not a verdict. It is telemetry.
Once I started treating challenges as telemetry, my retrospectives got sharper.
Instead of “I failed at this,” I could write:
- What happened
- What I expected
- What was different
- What I will change
That structure sounds simple, but it creates momentum. It turns self-judgment into system improvement.
A Real Example: Unexpected Demo, Useful Signal
In a high-stakes meeting, I had the floor for around 15 minutes to explain a project. I prepared, delivered the technical details, and answered deep questions.
Then I got an unexpected request: a live demo.
I was not ready for that part. I fell I ran the demo successfully, but afterward I reviewed the session and noticed something important: I went too deep too fast on technical details and did not spend enough time defining the problem first.
If I use the old lens, I might call that “I didn’t present perfectly.” End of story.
Using a feedback-loop lens, the output is more useful:
- Signal: The audience needed stronger problem framing before implementation detail.
- Assumption that failed: Technical depth alone would carry the room.
- Adjustment: Reorder future talks to Problem → Stakes → Approach → Internals.
- Next experiment: Use a 3-minute problem-definition block at the start of the next presentation.
No drama. Just better design for next time.
This is the practical difference. Feedback loops preserve confidence while still demanding rigor.
Key Point: A challenge is valuable when you convert it into a concrete, testable improvement.
The Experiment Format I Use
To stay in a growth mindset, I run challenges through a lightweight experiment format. I now use AI to help me capture and structure these loops, but the format is simple enough to do without it.
The core loop has five steps:
1) Capture Facts (without narrative)
Write only observable facts first.
Example:
- “I was asked for a live demo unexpectedly."
- "I answered technical questions successfully."
- "Problem framing was brief.”
No labels like “good,” “bad,” or “failure” yet.
2) Extract Signals
Ask: what does this reveal about my process?
Examples:
- My sequencing was optimized for technical peers, not mixed audiences.
- I need a default structure for high-stakes communication.
3) Pick One Small Adjustment
Not ten changes. One.
Examples:
- Add a fixed “problem definition” section to every presentation.
- Create a short checklist for demo readiness.
4) Define Success Criteria
Make the next iteration measurable.
Examples:
- “Did I explain the problem before architecture?"
- "Did the audience ask fewer context questions?“
5) Log the Artifact
Capture it in a note, playbook, checklist, or post.
If it is not captured, the lesson evaporates.
This step is underrated. Documented feedback loops become reusable assets. They compound.
(I have a longer template I use in Obsidian — I’ll link it in a future post.)
Why This Matters for Sustainable Growth
This lens also changed how I think about learning itself.
I used to spend too much time in open-ended exploration with no artifact at the end. Interesting? Yes. Compounding? Not always.
Now I prefer a simple rule: reduce exploration, increase building.
When I choose learning paths, I ask:
- Does this create an artifact?
- Does this improve real execution?
- Is this sustainable with my energy and attention?
This matters especially for how my ADHD brain works:
- Fast feedback is dopamine — it creates the forward motion that keeps me engaged
- Concrete signals short-circuit perfectionism paralysis — instead of spiraling on “did I do this right?”, I have a concrete next step
- Logged artifacts give me visible evidence of progress when working memory isn’t reliable
Without the artifact, the learning evaporates. With it, the loop compounds.
”Failure” can freeze momentum. “Feedback” keeps the loop alive.
That does not mean pretending everything is fine. It means staying honest while remaining operational.
Engineers already do this with systems:
- detect
- diagnose
- patch
- monitor
I just run the same protocol on my own process now.
Key Takeaways
- Challenges are telemetry: Treat them as signals about your process, not verdicts about your identity.
- Use structure under pressure: Problem → Stakes → Approach → Internals is a safer default for technical communication.
- Small adjustments win: One targeted change per loop beats broad self-criticism.
- Artifacts create compounding returns: If a lesson is not documented, it is easy to lose.
- Sustainable growth is operational: Reduce random exploration, increase outcome-oriented building.