Day 4 😫
You’ve been observing your team for the entire week. You are tempted to micro manage. To step in. To shut it down. It’s one of those moments when a simple task exploded. It seemed so simple on Monday.
It’s almost been an entire week.
You are tempted to shut it down. But you really need it done. Downstream commitments depend on this simple fix. Other teams depend on it.
Yet… you are second-guessing yourself.
Finally, someone tries something radical. It seems promising. Progress made… but no. That wasn’t it.
… SIGH …
Day 3 😣
The screen-staring has begun. The team is foolishly retrying past checks thinking they made a mistake. Everything is being second-guessed. Even their sanity.
Bizarre, experimental checks are being performed. Debug logs enabled.
To no avail, the simple tasks is now past the estimated time. Should we escalate? Should we cancel? Re-plan the entire cycle? Because of this small thing?
The managers are visibly irritated now.
Day 2 😐
Ok, yesterday was a setback but surely today we get it done.
“If it comes to the worst we’ll just re-implement it. The tests are already passing.”
Mid-day at lunch, the decision is made to rewrite the module.
Confidence rises, morale is high. It is a quick task. Tests pass.
Same behavior.
Frustration kicks in. Everyone goes home thinking about this problem at night.
Day 1 🙂
A confused ticket arrives on the team’s desk. A critical subsystem with only a few lines of code started misbehaving on production and staging servers. All tests are green. Looks like a mutated regression.
Should be simple!
The Final Day 🤯
Eyebrows raise. One of the devs noticed something weird. An assumption was challenged. Oh no… it can’t be.
The one thing we didn’t check.
The one thing we assumed couldn’t possibly be broken.
"There was a typo in the server secrets.”
!@#$% 🤬
An entire week gone. What went wrong?
Emotional Reframing — Self-talk 😭
Ben Meer highlighted a good technique to this. (first link is to his profile, second to the deck) Inspired by Tony Robbins he produced this deck to help us accept the negative states.
Not to judge our mental state. But to accept it to lower their intensity. So that we can deal with it on our own terms. To respond, rather than react.
I also had the fortune of being coached for years by one of Tony Robbins’ ex-trainers and a great business guru, Peter Sage.
Here’s an excerpt from Ben’s slide deck:
Are you exploring new angles?
Are you in demand?
Root Cause and Path Forward
This happens more often than we’d like to admit. But it keeps happening for a reason. This is escalating feedback to laborious manual tasks, error-prone slow procedures and a combination of bad habits.
By extracting lessons you can prevent this from happening again. But only if you act on what you learn.
Rather than blaming the developer who ended up doing this, have empathy and compassion. This is a symptom of systemic failure, not personal misconduct.
Here are some driving questions to help you along this exploration:
What assumptions did we that prevented us from exploring the now-known solution earlier?
What automation could re-do this check instead of a human much faster?
What tools would a human need to debug this faster?
Given the same original conditions, will an unsuspecting developer go down the same route?
What rules and procedures can be implemented so that the initial conditions cannot be recreated?
How can these conditions be alerted and detected automatically?
What automation could fix this automatically without human intervention?