On screwing up

The worst thing you can do after screwing up isn't making the mistake - it's how you handle the immediate aftermath. There are two traps people fall into: defending yourself and making excuses, or going the opposite direction and publicly beating yourself up. Both are terrible. The first is obviously bad, but the second is just as damaging because you're asking people to reassure you when they should be solving the problem, you're removing yourself from the group best positioned to fix it (since you have the most context), and it's unprofessional. The answer is to do nothing for the first thirty seconds to ten minutes. Just ride out that initial jolt of panic and the impulse to leap into action. Most of the worst reactions happen immediately, so if you can simply stay calm during that window, you're already winning.

Once you're under control, communicate what happened immediately - to your manager or the relevant colleague. Be matter-of-fact about it. You often don't even need to say "I made a mistake" if it's obvious from context. Just say "I deployed a change and it broke X feature." Do this before you've figured out a solution, because the temptation to quietly fix it and hope no one notices is dangerous. Someone will raise a ticket eventually, and if you don't communicate first, you risk someone else discovering it and declaring an incident while you're working on a fix. Now they're paging teams, imagining worst-case database failures, causing all kinds of hassle - all because you deprived them of the context you had all along. Tech managers will forgive mistakes, but they won't forgive being made to look like a fool or being deprived of critical information.

The uncomfortable truth is that incidents are caused by individuals screwing up, not just systems. The popular wisdom that it's always the system's fault is technically true but practically useless. Managers have a mental shortlist of engineers who can reliably lead projects, and if you screw up repeatedly, you drop off that list. They don't have the technical context to evaluate your good reasons, so they judge you on results. This means the optimal amount of mistakes at work is not zero. If you prioritize always being right, you won't be able to lead projects, because leading always requires taking risks. You need to find the balance between always being right and taking enough risks to actually ship things.