Mistakes happen. Maybe you pushed a bad deployment on a Friday (oops), misconfigured an environment, or introduced a bug that only surfaced in production. At some point, you will mess up

So what do you do when you’ve messed up? Here are a few ways to handle it properly.

1. Own it

You check the logs, and there it is—you pushed something that broke production. Your stomach sinks. Now’s the time to take responsibility.

  • Acknowledge the issue: “I think I might have broken X.”
  • Take responsibility: Avoid shifting blame to tools, circumstances, or other people.
  • Communicate with affected users and/or stakeholders: If your mistake has an impact beyond the team, let people know what’s going on. Even a simple message like, “We’re aware of the issue and working on a fix,” can prevent frustration and speculation. Silence erodes trust—transparency helps maintain it.

2. Don’t isolate yourself

It’s easy to think that because you made the mistake, you have to be the one to fix it. You might feel like you need to prove yourself, to clean up your own mess before anyone notices. But that’s not how a team works. Your team should be there to help you—not judge you.

  • Pull in the right people: “Can someone help me figure out what went wrong?”
  • Trust your team: They don’t expect you to carry the weight alone. Mistakes happen, and working together leads to a better fix.
  • Keep communication open: If the mistake affects others, keep them in the loop. Depending on the severity of the incident, have a quick call, set up a temporary Slack channel, or create a dedicated thread to ensure everyone stays informed and aligned on the resolution.

You might have messed up personally, but you’re still part of a team. Problems get solved faster when people work together, and you don’t need to prove your worth by handling everything yourself.

3. Contain the damage

Before diving into debugging mode, focus on stopping things from getting worse. 

Depending on the situation, this might involve:

  • Rolling back a deployment.
  • Deploying a quick fix to patch the issue while you work on a more permanent solution.
  • Temporarily disabling a feature if it’s causing widespread problems.

This buys you time and relieves the stress, making it easier to approach the problem with a clear head rather than rushing into a fix that might create new issues.

4. Share what you’ve learned

The issue is fixed, the incident is over—but that doesn’t mean you just move on. If you don’t learn from a mistake, you’re setting yourself up to repeat it.

  • Write a short internal post-incident (focus on facts, not blame).
  • Share key takeaways in a retrospective.
  • Suggest changes to help prevent similar issues in the future.

This is also the time to identify gaps in documentation or processes. If something was unclear or missing, update internal guides, onboarding materials, or checklists. If the mistake was made easier by a broken or inefficient process, propose a change—maybe it’s an extra safeguard in CI/CD, a better rollback strategy, or clearer release guidelines. Good documentation and well-designed processes help prevent the same mistakes from happening again.

You might have made the mistake, but the team can learn from it together, making sure it doesn’t happen again—or at least that you’re better prepared next time.

5. Move on

At some point, you have to let it go. No one wants to be the person who keeps replaying their worst mistakes in their head for weeks.

In my article On Being an Expert, I talked about how expertise isn’t just about having all the answers—it’s about knowing when to ask for help and being transparent when you don’t know something. The same applies to mistakes.

Being a responsible developer isn’t about never making mistakes—it’s about how you handle them when they happen. Do you own up to them? Do you communicate openly? Do you work with your team to fix things properly?

Mistakes don’t happen in a vacuum. Major incidents are rarely the fault of a single person—they’re often the result of multiple factors stacking up over time. Process gaps, unclear documentation, missing safeguards—an accident waiting to happen. Owning your part is important, but so is recognising that failures often expose deeper issues in a company’s processes or culture.

The real value lies in learning from them, improving systems, and making sure the same mistakes don’t happen again—not just for you, but for everyone.