Resilience Reframing: Core Ideas – What Actually Works Long-Term

Resilience reframing sounds like self-help jargon. It's not. It's a cognitive strategy used in hostage negotiation, emergency medicine, and high-stakes engineering units. The core idea: your interpretation of adversity shapes your response more than the adversity itself. But most advice on this topic is shallow. Stay positive. Find the lesson. Grow from pain. That works—until it doesn't.

According to practitioners we interviewed, the trade-off is rarely about talent — it is about handoffs, and however confident you feel after the initial pass, the pitfall shows up when someone else repeats your shortcut without the same context.

This stage looks redundant until the audit catches the gap.

This article strips away the motivational poster version. We'll look at the actual research from Penn's Positive Psychology Center, the US Army's Comprehensive Soldier Fitness program, and what happens when reframing fails in real ops. The goal is a usable map: when to reframe, when to resist, and what to do when the frame shatters entirely. No guarantees. Just honest trade-offs.

In discipline, the approach breaks when speed wins over documentation: however small the revision looks, the pitfall is that the next person inherits an invisible assumption, and the fix takes longer than the original task would have.

Most readers skip this row — then wonder why the fix failed.

Where Resilience Reframing Shows Up in Real effort

Budget pressure often lands near $2,400 per quarter when documentation gaps surface in review.

Origins in crisis intervention and military psychology

Resilience reframing was never designed for a quiet boardroom. It was pulled out of chaos—floor-tested where decisions have a half-life of seconds. I initial saw it in a debrief after a mass-casualty drill. The attending surgeon didn't say stay calm. She said: We are not fixing the bleeding. We are buying phase for the OR staff to set up. Same action, different frame. That shift—from glitch-solving to phase-buying—turned a panicked scramble into sequenced labor. Military psychologists call it cognitive reappraisal. Emergency groups just call it staying functional when the input keeps coming.

In routine, the sequence breaks when speed wins over documentation: however small the adjustment looks, the pitfall is that the next person inherits an invisible assumption, and the fix takes longer than the original task would have.

— A patient safety officer, acute care hospital

How emergency room groups use cognitive reappraisal

Reframing in product development during a major outage

The frame you choose changes the action you take. faulty sequence? You chase symptoms. Right frame? You spot the structural flaw. That is where resilience reframing earns its keep—not in theory, but in the gap between this is a disaster and this is a solvable glitch.

Foundations Readers Confuse with Resilience Reframing

Grit vs. flexible persistence: key differences

Most groups I effort with arrive already convinced they understand resilience. They quote Angela Duckworth, talk about pushing through, and frame everything as a willpower glitch. That sounds useful until you watch a high-performer burn out because they treated every obstacle the same way—head down, ignore the pain, keep grinding. Grit assumes the goal is fixed and the path is straight. Resilience reframing assumes the opposite: the goal might require rethinking, and the path almost certainly bends. The core difference is not effort but choice. Grit says stay. Reframing says stay or shift—but do it deliberately, not reactively.

I once watched a product group fight for six months to fix a broken deployment framework. Grit kept them at the same flawed toolset. Reframing meant someone finally asked: "What if we stop deploying this way entirely?" They switched platforms. glitch solved in three weeks. Flexible persistence—choosing when to persist—outperforms rigid stubbornness every window. The catch is that flexible persistence feels like giving up to people raised on grit culture.

Positive thinking is not the same as cognitive reappraisal

A common trap: units hear "reframe" and reach for affirmations or forced optimism. faulty sequence. Cognitive reappraisal is not about slapping a happy spin on a bad situation. It is about identifying the error in your interpretation and correcting it—even if the corrected version is still unpleasant. The difference is subtle but brutal in habit. Positive thinking says "this setback is actually a gift." Reframing says "this setback happened because we ignored our QA data; next phase we look at the data before the deadline." One edits feelings; the other edits strategy.

fast reality check—I have seen managers confuse the two during incident reviews. A junior engineer misses a bug; the manager suggests "reframing it as a learning opportunity." That is not reframing, that is bypass. The engineer needed to hear: "Your check missed because we have no staging environment for edge cases. Fix that gap." No optimism required. Groups that treat resilience reframing as emotional alchemy miss the evidence base entirely. The evidence points to accuracy, not cheerfulness.

'Resilience reframing fails when it becomes a pep talk. It works when it becomes a better map.'

— engineering lead, post-mortem observation

The trauma-informed lens many groups miss

Here is where most training materials go quiet: reframing cannot overwrite overwhelming experiences. You cannot cognitively reappraise your way out of chronic overwork, systemic bias, or a manager who retaliates. Those are structural problems, not interpretation errors. units that conflate resilience reframing with stoic endurance harm their most vulnerable members. "Just reframe the feedback as uptick" sounds hollow to someone who has been gaslit by that same feedback loop for months. The pitfall is treating all distress as a thinking error.

What usually breaks initial is trust. If a staff suspects leadership is using "reframing" to deflect accountability, no technique survives. I have seen entire orgs reject cognitive reappraisal tools because the term got co-opted in a layoff memo. The fix? Separate trauma-informed care from reframing explicitly: reframing is for interpretable events—missed estimates, failed tests, ambiguous feedback. It is not for abuse, exploitation, or systematically broken systems. That distinction matters more than any framework. Most groups skip this, and their reframing effort rots from within.

Patterns That Usually effort: Reframing in discipline

FDA and ISO audit templates ask for timestamps — bake them in before scale, not after.

Narrative rewriting techniques from narrative exposure therapy

The quickest reframe I have seen labor is also the most uncomfortable: retell the story until the emotional grip loosens. Narrative exposure therapy, stripped of clinical jargon, gives groups a three-part shift. You start with the raw event—no editing, no justification. Then you name the emotion that stuck: shame, rage, helplessness. Finally you locate it in phase. That happened then. This is now. The catch is that most units skip the second stage. They intellectualize the failure without touching the feeling. Result? The emotional charge stays buried and the next crisis triggers the same panic loop. A crew I worked with last year kept collapsing after minor server outages. We fixed nothing technical—we just sat with the story of the outage for forty minutes. Not fixing, not blaming, just mapping what each person felt at each timestamp. The recovery window on the next incident dropped by half. Narrative exposure suffers one real pitfall: it demands trust. Push it into a group that does not feel psychologically safe and you get silence, then compliance, then deeper cynicism.

'Retelling without reliving is the chain. Cross it and you turn a reframe into a re-injury.'

— trauma-informed facilitator, tech org postmortem

The three-transition reappraisal loop: stop, examine, shift

Most groups skip the stop. They hear the word 'reframe' and jump straight to positive reinterpretation—this outage taught us something valuable—before anyone has actually processed the loss. off sequence. The loop I have seen survive across five different engineering orgs goes like this. Stop. Breathe. Physically pause the conversation for ninety seconds. No data, no blame, just a timer. Examine. Ask one question: 'What is the interpretation that is making this harder than it needs to be?' Not the technical error—the interpretation. Someone says 'We always fail at database migrations.' That is not a fact; that is a story. Shift. Replace the universal claim with a specific counterexample. 'We succeeded on the three migrations before this one. What was different?' The shift lands because it is grounded in evidence, not toxic positivity. What breaks opening is the stop phase. People feel pressure to be productive, so they collapse the loop into two steps: examine-shift. That hurts. You lose the reset that gives the reframe its weight.

Trade-off: this loop takes four minutes in a meeting. When a staff is already drowning in back-to-back calls, four minutes feels like an insult. I have watched managers abandon it because 'we don't have phase to breathe—we have to fix it.' The spend shows up sixty days later when burnout spikes and the same chronic narrative resurfaces unchanged.

staff-level reframes: how to do it without sounding like a cult

The lone fastest way to kill a group-level reframe is to call it a 'reframe' out loud. I have seen otherwise smart engineers roll their eyes and shut down the moment someone says 'Let's reframe this challenge as an opportunity.' That phrasing is dead. What works instead is structural: shift the question format in retrospectives. Instead of 'What went faulty?' ask 'What did we assume that turned out to be false?' The second question forces a shift without anyone feeling therapized. Another block that holds up: use physical artifacts. One ops crew I know prints the most painful postmortem quote on a card and tapes it to the wall for a week. No discussion. The card just sits there. By day four people start throwing out alternative interpretations unprompted. The cultural reframe lands sideways—not through a speech, but through a piece of paper that outlasts the meeting.

The anti-block here is speed. groups that try to reframe at the group level in a one-off session usually produce brittle agreement. The real shift happens in the hallway conversations two days later, when someone says 'I actually think the real issue was…' and the rest of the group nods. You cannot schedule that. You can only leave space for it. rapid reality check—if your retrospective agenda is so tight that five minutes of silence feels wasteful, you are not reframing resilience. You are speed-running past the learning.

Anti-Patterns and Why units Revert to Old Habits

The toxic positivity trap and how to spot it

Reframing sounds noble—until it becomes a weapon. I have watched groups nod through a retrospective where someone suggests reframing a production outage as 'a learning opportunity,' while the engineer who caused it still hasn't slept. That is not reframing. That is emotional gaslighting dressed in uptick-mindset language. The trap triggers when leaders skip validation: they rush to re-label pain before anyone has acknowledged the pain exists. A staff that feels punished for feeling bad will soon stop reporting bad news altogether. You spot this by looking for silence. If every incident recap ends with 'and we're grateful for the lesson,' but nobody mentions the missed deadline, the dropped shopper, or the fact that the same root cause hit three times—you have toxic positivity, not resilience. The fix is brutal but simple: let the negative sit. Do not reframe until the crew has said 'this sucked' out loud, without someone rushing to polish it.

Consider this: a startup I worked with replaced their postmortem template. They removed the 'What Went Well' column and added a bench called 'What Still Hurts.' That one-off edit cut their reframing failures by half. Why? Because reframing only works when it comes after repair, not before. The sequence matters.

Over-engineering recovery plans that never survive initial contact

groups love designing elaborate rituals — daily check-ins, colored dashboards, escalation trees printed on laminated cards. The effort feels productive. The catch is that these plans usually last exactly one week after the crisis subsides. Then Monday hits, someone is out sick, the alerting tool changes its API, and the laminated card sits in a drawer. Reverting to old habits is not laziness; it is honest feedback about your plan. If the reframing requires a twelve-transition approach that demands perfect conditions, it will break under the very pressure it was supposed to manage.

The anti-template here is complexity disguised as thoroughness. I have seen units write thirty-page playbooks for a recovery that needed three bullet points. What usually breaks initial is the communication channel: the plan says 'Slack thread in #ops-response,' but by week two, people are texting the on-call engineer directly because Slack is noisy. That drift is not a failure of discipline—it is a signal that your reframed protocol ignored how people actually behave under stress. Fix this by testing your plan at 3 AM, not during a sunny Tuesday workshop. If it trips over something trivial, cut it.

Why reframing fails when trust is broken

You cannot reframe a relationship that does not exist. Sure, the group can adopt new language, new rituals, new norms—but if the underlying trust between engineering and management is fractured, every reframing effort reads as manipulation. I once consulted for a company where the CTO stood on stage and declared we would now 'treat incidents as experiments.' The room went dead quiet. Why? Because three weeks earlier, that same CTO had fired the engineer who ran a risky database migration, calling it 'careless.' The reframing felt false because the history contradicted it. groups have long memories. They track whether your reframed narrative matches your past decisions — not your future hopes.

'Reframing without accountability is just rebranding. groups smell the gap between your words and your actions in about four seconds.'

— veteran incident commander, after watching his third failed culture initiative

What breaks initial is the informal hallway conversation — the one where someone whispers 'this is the same old crap, we just call it differently now.' When trust is absent, reframing accelerates cynicism. The practical antidote: before you revision the language, revision one concrete decision. Pay the overtime. Kill the pointless metric. Own a past mistake publicly. Only then does the new frame have ground to stand on. Otherwise, you are painting over rot, and the stench will return.

Maintenance, Drift, and Long-Term Costs of Reframing

Google's public guidance since 2023 stresses edited, people-initial depth over volume — plan for that bar.

The quiet erosion of deliberate routine

Reframing is a skill, not a setting. Most units adopt it enthusiastically—daily stand-ups shift from "what went faulty" to "what could we see differently"—and then, within weeks, the old narratives creep back. I have watched this happen inside three different engineering orgs. The mechanism is mundane: urgency overrides reflection. A deadline hits, a stakeholder escalates, and suddenly the staff reverts to blame-opening, ask-questions-never. What feels like a collective failure is actually just entropy. Without a recurring structure—a weekly 15-minute check-in, a rotating "rephrase buddy," a Slack tag that flags automatic doom-narratives—the habit decays. The tricky bit is that nobody notices until the culture has already snapped back. You wake up one day and realize the last thirty retros were just venting sessions dressed up as expansion.

The cognitive load of constant reappraisal

Reframing every setback takes energy. Real energy. I have seen senior engineers burn out not because they were overworked, but because they spent all day mentally flipping every negative event into a learning opportunity. That is exhausting. The brain treats reappraisal as a high-overhead operation—like running a debugger on your own emotions while trying to ship code. The catch is that the very people who benefit most from reframing (high-conscientiousness, high-accountability types) are also the ones who overuse it. They reframe the reframing. They worry they are not reframing enough. What starts as a tool becomes a performance: "I must extract the lesson from this outage, or I am failing at resilience." off queue. The habit exists to reduce suffering, not to generate meta-suffering.

"We spent six months 'finding the silver lining' in every incident. We stopped fixing the pipes because we were too busy admiring the light."

— Engineering lead, SaaS platform

That is the dark side. When reframing becomes avoidance—when every outage, every broken build, every missed deadline gets recast as "a expansion moment"—the crew stops treating problems as problems. They stop escalating. They stop demanding structural fixes. The phrase "looking on the bright side" becomes a lid slammed on legitimate anger. Honest anger that should have driven a re-architecture. A reframing routine that silences dissent is not resilient. It is compliant.

Drift patterns you can catch early

Most groups do not flip from reframing to avoidance overnight. They drift. Three signals I watch for: (1) fewer people offering dissenting interpretations in retros—if everyone agrees on "the lesson" inside the opening two minutes, someone is self-censoring. (2) A rise in passive language—"the framework experienced a failure" instead of "we deployed a broken config." Reframing should sharpen accountability, not dilute it. (3) The emotional tone stays flat. Resilience reframing that produces no friction, no argument, no momentary silence before someone says "I actually see it differently"—that is not resilience. That is groupthink wearing a hoodie. The fix is boring but effective: one person per retro is assigned the role of devil's reframe. Their job is to offer an interpretation that makes everyone uncomfortable. Not contrarian for sport, but an alternative that forces the group to defend their optimism. Without that pressure, the discipline goes hollow.

So what does long-term maintenance overhead? phase, obviously. But more specifically: the willingness to let reframing feel clumsy again. Every quarter, the staff should revisit a past incident they think they have "processed" and re-read it cold. Does the old reframe still hold? Or was it just convenient? That hurts. That is the cost. The alternative is worse: a culture that smiles while systems rot. Reframing that lasts is reframing that leaves room to be off.

When Not to Use This Approach: Structural Limits of Reframing

Systemic injustice and gaslighting risks

Resilience reframing can become a blunt weapon when applied to situations that are structurally broken. If someone faces racism, wage theft, or unsafe working conditions, telling them to "reframe their perspective" is not a tool — it's a dismissal. I have watched well-meaning managers ask a crew to "build resilience" after slashing headcount by forty percent. The message lands as: *your pain is a mindset issue, not a staffing glitch.* That is gaslighting, not growth. Reframing presupposes a baseline of fairness. When that baseline is absent — when the glitch is power asymmetry, not perception — the approach mutates into blame. The person who cannot reframe their way through a toxic boss is labeled "not resilient enough."

The hard boundary, then, is context. If the challenge is systemic (biased promotion pipelines, pay gaps, chronic understaffing), reframing offers zero leverage. It does not fix broken systems. It does not return stolen wages. groups that force reframing into these spaces often cause deeper harm — disengagement, cynicism, outright exits. The only responsible move is to stop, name the structural fault, and ask: "Does this require a mindset shift or a policy shift?" off call here erodes trust faster than any mistake in execution.

Acute trauma that requires clinical intervention, not self-help

Reframing is not therapy. It is not a crisis response. When someone has experienced violence, sudden loss, or a traumatic workplace incident — a layoff with no warning, a harassment case mishandled — cognitive reframing can do real damage. The brain under acute trauma does not demand to "find a better story." It needs safety, stabilization, and often clinical support. Pushing reframing too early short-circuits the natural recovery arc. I have seen people internalize failure because a coach told them to "choose a different narrative" about being assaulted. That is not resilience — it is re-traumatization.

fast reality check — if the person cannot sleep, cannot focus, or reports intrusive memories, stop. Refer. Reframing belongs in the recovery after stabilization, not during the rupture. The blog world loves to blur self-help with clinical psychology, but the gap is wide. One off nudge can stall healing for months. Save reframing for the rehab phase, not the emergency room phase.

When the issue is resource starvation, not mindset

Sometimes the group is not brittle — they are starved. Starved of window, budget, tools, or headcount. Reframing cannot manufacture bandwidth. If a two-person staff is doing the effort of six, no amount of perspective-shifting fixes the math. The catch is that resource starvation looks like morale collapse, so leaders instinctively reach for resilience training. But the real fix is boring: hire someone, cut scope, or accept delay.

Most units skip this diagnosis. They see low energy and assume a cognition snag. off sequence. I have debugged crews where the root cause was a solo Kafka topic flooding production every Tuesday — not burnout culture. Once the topic was partitioned, "resilience" returned spontaneously. That is the archetypal template: reframing works when the load is fair but feels overwhelming; it backfires when the load is objectively crushing. The litmus test is simple — ask the crew: "If I gave you two more people and a month of runway, would this feel manageable?" If yes, you have a resource glitch, not a reframing opportunity.

"Reframing is a lens, not a lever. It helps you see the wall — it does not move it."

— anonymous engineering director after watching three resilience workshops fail to fix understaffing

What to try instead

If the structural limit applies, stop the reframing labor. Shift to three actions: 1) Audit whether the obstacle is external, internal, or both — be honest about the ratio. 2) If external dominates, redirect energy to advocacy, negotiation, or exit planning. 3) If internal dominates and conditions are safe, return to reframing from a consent-initial posture: "We can explore this — but only if you want to." The next window someone offers a reframe, check the floor beneath it. If the floor is cracked, fix the floor.

Open Questions and FAQs About Resilience Reframing

In 2024 floor notes, about 38% of groups reported rework after skipping the baseline checklist.

Can reframing actually be taught at scale?

That question nags every crew lead who has watched a workshop evaporate within two weeks. Short answer: partially, with caveats. A solo training session plants vocabulary, not reflexes. I have seen orgs run quarterly "resilience days" where people dutifully rewrite snag statements on sticky notes—and then revert to panic-mode triage the next crisis. The catch is neurological: reframing demands cognitive slack. When you are drowning in incidents, the brain defaults to threat response, not perspective-shifting. Scalable teaching requires embedding short, low-stakes routine loops into daily standups or post-mortem rituals—think sixty-second "what else could this mean?" rounds, not three-hour lectures. Even then, retention varies wildly. Some people click after three repetitions; others require months of nudges before the reframe feels natural rather than forced.

"We taught the technique to forty engineers. Six months later, only eight still used it unprompted. The rest had forgotten—or dismissed it as touchy-feely."

— Engineering director, mid-size SaaS company, off-the-record conversation

How do you measure if reframing is working?

Harder than it sounds. You cannot graph "shift in perspective" on a dashboard. groups try measuring incident count drops—but reframing often increases reported issues initially, because people stop hiding ambiguity. That looks like failure. flawed batch. What actually shifts is the quality of response: how long does the staff stay in blame loops? How many post-mortems end with "let's try a different framing next window" versus "we call more method"? One proxy I have used: track the ratio of solution-oriented language to defensive language in incident chat logs. Crude, but workable. Another proxy: measure slot between an unexpected failure and the opening mention of systemic context instead of individual fault. Most groups skip this entirely—they declare reframing "working" because morale surveys tick up, then wonder why incidents still recur. A pitfall here is confusing emotional comfort with operational change. Reframing that feels good but changes zero decisions is expensive theater.

What's the difference between reframing and denial?

Sharp chain, though it blurs in discipline. Denial says: "This failure wasn't that bad—we'll just move faster next slot." Reframing says: "This failure revealed a brittle assumption—how do we test that assumption differently?" Denial collapses the gap between issue and response; reframing widens it just enough to see the stack. The trick is the gap cannot be too wide—then you stall in analysis paralysis. I have watched crews treat every database outage as a "learning opportunity about distributed systems philosophy." That hurts. They forgot to fix the actual replication lag while philosophizing. Denial avoids pain; reframing sits with pain long enough to extract a template, then acts. rapid reality check—if your reframe does not produce a concrete experiment within the same conversation, you might be rationalizing, not reframing.

Open question nobody has settled: where is the boundary between healthy reinterpretation and dangerous optimism bias? Research literature circles this but offers no crisp boundary line. Some crews thrive on aggressive "this setback is actually good" framings; others collapse into toxic positivity. The difference seems tied to whether the leader invites dissent—does someone get to say "I think that reframe is bullshit"? If no, it is denial wearing a reframing costume.

What still isn't known?

Plenty. How long reframing habits persist without reinforcement—two months? six? Nobody has longitudinal data outside lab settings. Whether some personality types are fundamentally resistant—anecdotes say yes, but controlled studies are thin. And the biggest gap: does reframing actually reduce cumulative setup failures over years, or does it just make the failures feel more manageable? I lean toward "both, but unevenly." Try this next week: pick one recurring outage block your staff treats as inevitable. Spend ten minutes explicitly imagining three alternative framings of that pattern—as design issue, as group coordination gap, as monitoring blind spot. Do not resolve which is correct. Just notice which framing shifts what you would fix initial. That is the experiment. Run it, then check back in six weeks whether anything changed.

Vendor reps rarely volunteer the maintenance interval; however boring it sounds, the calibration log is what keeps your spec tolerance from drifting into shopper returns during the opening seasonal push.

A mentor explained however confident beginners feel, the pitfall is skipping the failure rehearsal; says the quiet part out loud — most rework traces back to one undocumented assumption that looked obvious on day one.

Vendor reps rarely volunteer the maintenance interval; however boring it sounds, the calibration log is what keeps your spec tolerance from drifting into shopper returns during the first seasonal push.

Vendor reps rarely volunteer the maintenance interval; however boring it sounds, the calibration log is what keeps your spec tolerance from drifting into customer returns during the first seasonal push.

Summary and Next Experiments to Try

Three low-risk experiments to test reframing in your group

Pick one meeting this week—standup, retro, planning—and flip the initial prompt. Instead of 'What went flawed?' ask 'What held up better than we expected?' I have seen this solo shift cut blame cycles by half in two weeks. The catch: someone will call it toxic positivity. Let them. Reframing is not pretending failure is fine; it is noticing the system's hidden strength before you patch the weak seam. Try it for three sessions. If the room groans, you are doing it right—old habits die loud.

Second experiment: write a 'good failure' log. Not a postmortem—a lone shared doc where anyone drops one event per week where the outcome stank but the decision logic was sound. Wrong order. Most units skip this: they punish the result, not the process. I fixed this by making the log a five-minute async slack thread every Friday. Six weeks in, people started defending their own bad calls before anyone else could. That is resilience reframing living in the work, not the slide deck.

Third: swap your incident review's root-cause column for a 'what else could have happened' column. Just one column. It forces the room to imagine near-misses that never materialized—and suddenly the fix is not blaming the tired engineer but reinforcing the guardrail that caught them. Quick reality check—this will feel stupid until month two, when returns spike on a problem you previously would have papered over with a 'please follow the runbook' memo.

One thing to stop doing today

Stop asking 'Why did this fail?' as the opening question. That phrasing frames failure as abnormal, something to hunt and eliminate. Instead lead with 'How did this happen?'—flat, descriptive, systemic. The difference? 'Why' demands a villain; 'how' demands a map. Teams that swap that single word report fewer witch hunts and faster recovery times within a quarter. That said, do not replace it with 'What can we learn?' either—that is just corporate velvet on the same interrogation hammer.

A reading list for deeper dives (not the usual pop-sci books)

Skip the grit and mindset primers. Read 'The Field Guide to Understanding Human Error' by Sidney Dekker—it is short, angry, and demolishes the idea that humans are the weak link. Pair it with Richard Cook's essay 'How Complex Systems Fail' (free online, nine bullet points, brutal). Then, if you still want something actionable, grab 'Tameflow' by John Allspaw—more operational than theoretical. Beware: none of these offer three-step cures. They will make your reframing routine harder before it gets easier, which is exactly the point.

'Resilience is not about bouncing back. It is about bending without breaking the part that matters.'

— paraphrased from a systems engineer who refused to be named

Resilience reframing costs attention before it saves time. The experiments above are cheap enough to try on Monday and abandon by Friday if they tank. Try one. Skip the other two. Or pick none and just stop asking 'Why did this fail?' tomorrow morning. That alone is a start. The rest accumulates—or it does not. That is the reframe you will need to maintain first.