A few years back I shipped a deploy on a Friday afternoon which took down checkout for forty minutes. Forty minutes of a live e-commerce site returning 500 errors to real customers with real carts. I remember standing in the office (we still had an office then) watching the error graph climb, my stomach dropping through the floor.
I wrote the mistake up. Root cause, timeline, what I missed, what I'd do differently. I sent it to the whole engineering team, not only my manager. I expected a quiet word about being more careful next time.
Instead my manager forwarded it to the rest of leadership with one line on top: "This is what learning from a mistake looks like. More of this, please."
This forty-minute outage taught me more about how software breaks, and how teams improve, than any release which went smoothly ever did. I still think about it more than I think about the good weeks.
We Only Tell the Highlight Reel
Walk into most standups, most all-hands, most LinkedIn posts, and you get the same pattern: the win, polished and framed. The launch which went well. The metric which ticked up. The client who loved the demo.
Nobody's leading with "here's the thing I got completely wrong this week and what it taught me." We've built entire cultures around hiding the off-days instead of mining them.
This is backwards. The off-days do more work than the good ones. You don't learn much from a release which goes exactly to plan. You learn everything from the one which doesn't.
Why We Bury the Bad Days Instead of Studying Them
I've sat on both sides of this. As an engineer hiding a mistake from a manager I knew would overreact. As a manager watching a team member bury a bad decision because the last time someone admitted one, they got quietly punished for it.
Neither version works, and here's the research behind why.
Harvard Business School professor Amy Edmondson has spent over two decades studying this exact problem. Her early research into hospital error rates produced a result she didn't expect: the better-performing teams weren't the ones with fewer errors. They were the ones which reported more of them. Not because they made more mistakes. Because they felt safe admitting the ones they made.
She built an entire framework out of this discovery, now known as psychological safety, and found teams and organizations with higher psychological safety have better performance, lower burnout, and, in medicine, even lower patient mortality, as she's written about extensively. A survey question as simple as "would a mistake be held against me here" turned out to predict how honestly a team reported problems, and how fast they fixed them.
The teams hiding their off-days weren't safer. They were quieter about the same amount of failure, and slower to learn from it.
Not All Bad Days Are Created Equal
Edmondson's later work, in her book Right Kind of Wrong, draws a distinction I wish I'd had language for earlier in my career. She sorts failure into three types.
Basic failures: a preventable mistake in familiar territory, usually with one clear cause. You skipped the checklist. You didn't test the edge case. These get fixed with process, not forgiven with a shrug.
Complex failures: several small things going wrong together in a familiar setting. No single villain. A deploy fails because of a timing issue, a stale cache, and an on-call engineer heads-down on something else. These need a real post-mortem, not a scapegoat.
Intelligent failures: the ones which happen when you're doing something genuinely new. You tried an approach nobody on the team had tried before, it didn't work, and you learned something real. These aren't failures to prevent. They're the cost of doing anything worth doing.
My Friday deploy was a complex failure. Config drift between staging and production, a monitoring gap which delayed the alert, and a rollback script which hadn't been tested in three months. No single person screwed up. Three unrelated weaknesses lined up on the same afternoon.
Once I saw it this way, the write-up stopped being a confession and started being a map. Fix the config drift. Close the monitoring gap. Test the rollback script monthly. None of it happens if the instinct is to bury the day instead of studying it.
What I Do With a Bad Day Now
I stopped treating off-days as things to survive and started treating them as data with a deadline. Here's the version of it I use:
Write it down within 24 hours, while it still stings. The emotional charge fades fast, and with it goes most of the honesty. The clean, polished version you'd write a week later leaves out the parts which matter most.
Sort the type before you assign blame. Was it preventable with a checklist (basic)? Several things stacking up (complex)? Or a real swing at something new which didn't land (intelligent)? Each one gets a different response, and treating an intelligent failure like a basic one is how you kill the exact behavior you want more of: people trying things.
Share it wider than feels comfortable. My manager forwarding my mistake to leadership felt exposing in the moment. It's also the single biggest reason I stopped hiding problems since. Admit a mistake and get praised for the admission instead of punished for the mistake, and you'll do it again. Bury it in a private message with a manager who's annoyed, and you won't.
Ask what would have caught it sooner, not who should have caught it. "Who missed this" gets you a defensive team. "What would have caught this three steps earlier" gets you a better system.
I wrote a longer version of this for leaders specifically at Step It Up HR, because the pattern doesn't stop at engineering. It shows up in every team where the boss's reaction to a mistake decides whether the next one gets reported or hidden.
The Off-Days Are the Curriculum
I've had better weeks since the Friday of the outage. Launches which went out clean, projects which landed ahead of schedule, teams which hit numbers I was proud of. I couldn't tell you much about most of them now. They went the way they were supposed to go, a fine thing to have happen, but they didn't teach me anything I didn't already know.
The outage taught me about config drift, about monitoring gaps, about what happens to a team's honesty when the response to a mistake is curiosity instead of blame. Six years later I still use the rollback checklist which came out of the outage.
If you're sitting on a bad day right now, the kind you'd rather not mention in standup, don't bury it. Sort it. Was it something you should have caught, something which stacked up on you, or something you tried because you were reaching for real growth? Write down which one it was and what it's telling you.
Your worst Tuesday might be teaching you more than your last five good weeks combined. Go find out what it's trying to say.