I used to treat bad weeks as personal failure.
Now I treat them like production incidents: acknowledge impact, stabilize quickly, identify root causes, and change the system.
This sounds clinical, but the trigger is not clinical at all. It is usually ordinary: too many chat threads, too many small promises, not enough sleep, and one hard decision postponed until it becomes the emotional center of the week.
By Friday, nothing may be obviously broken. The work still moves. Messages still get answered. But the quality of attention is lower. Every request feels heavier than it should.
That is when I need a recovery protocol.
Symptoms I watch for
- everything feels urgent,
- shallow replies replace thoughtful decisions,
- I avoid hard tasks and over-index on chat,
- I end the day tired but unclear on what moved.
When these signals cluster, I stop pretending it is “just a busy week.”
The key word is cluster. One tired day is normal. One delayed task is normal. The pattern matters when several signals appear together and start reinforcing each other.
24-hour recovery: stabilize
Goal: prevent further damage.
- Cancel non-critical commitments.
- Protect one 90-minute deep-work block.
- Write a single-page “state of system” note:
- what is actually broken,
- what is delayed,
- what can wait.
This restores control of attention.
I avoid big self-improvement promises in this phase. The job is not to become a better person overnight. The job is to stop the incident from expanding.
In work terms, this means I do not make large new commitments while my judgment is degraded. I also avoid using apology as a productivity tool. “Sorry, I’ll do it tonight” feels responsible, but it often turns one overloaded day into three.
72-hour recovery: diagnose
Goal: find repeatable failure patterns.
I ask three questions:
- Where did context switching explode?
- Which commitments were accepted without scope?
- Which decisions were postponed because I was mentally depleted?
Then I map causes into two buckets:
- structural (calendar design, unclear ownership, interruption policy),
- behavioral (people-pleasing yes, unclear boundaries, poor sleep discipline).
The distinction matters because behavioral fixes are fragile when the structure keeps producing the same pressure.
If the real problem is that every project reaches me through the same chat window, “be more focused” is not a fix. If the real problem is that I accept vague work before understanding scope, “try harder” is not a fix either.
The better question is: what made the bad behavior easy?
7-day recovery: redesign
Goal: make relapse less likely.
I make at least three concrete changes:
- response windows instead of all-day chat,
- explicit escalation criteria,
- weekly review of “decisions made vs decisions deferred.”
Small operational changes outperform motivational promises.
Sometimes the redesign is embarrassingly small:
- move one recurring discussion into a weekly checkpoint,
- ask for written scope before accepting work,
- stop leaving a difficult reply half-drafted all day,
- create a visible list of deferred decisions,
- decide which messages can wait until the next response block.
Small changes work because bad weeks are rarely caused by one dramatic mistake. They are usually caused by too many tiny open loops.
What changed for me
The point is not to eliminate hard weeks.
The point is to recover faster, with less self-damage, and with better learning each cycle.
A bad week is data.
If I can read it well, next week gets cheaper.
The part I still have to relearn is that recovery is not indulgence. It is maintenance.
An engineer with degraded judgment is part of the system. Pretending otherwise does not make the system more reliable. It only hides the failure mode until it shows up in rushed decisions, unclear communication, or commitments nobody should have accepted.
So I treat a bad week as a signal. Not a verdict. Not an identity. A signal.
Then I change the operating conditions.