We’ve all been there. A technical choice you or your team made has come back to bite you. Maybe you introduced an abstraction which wasn’t quite right and caused a lot of confusion, or didn’t do the best job of organizing your team’s work on the last project. These are opportunities to grow and reflect, but only up to a point. There’s a limit to what you can learn from overanalyzing past decisions. Here are some lessons I’ve learned—mostly the hard way—about how to respond when things go wrong or the current approach just isn’t working.
Be wary of overcorrecting
When things aren’t going well, it can be tempting to throw everything out and start from scratch. That might mean going back to the drawing board and rearchitecting the whole app, or picking a totally new process for the team to follow. I won’t say that’s never the right choice, but more often than not, you were close to the answer the first time. What’s needed is not a fundamental shift, but rather a small course correction.
Have a retrospective
Allowing those who were affected by a decision to participate in finding a solution will lead them to feel more connected to the outcome. Celebrate where the current approach is meeting your needs, and be honest about where it’s not. Then make a few incremental changes to move things in a better direction. You’ll get clearer feedback that way—and avoid trading one big problem for another.
Don’t blame the tool
Just because your current Jira workflow is annoying and difficult to navigate doesn’t necessarily mean that Jira is an objectively bad tool. You can switch to Linear or anything else, but if you never take time to assess what about your previous workflow did and didn’t work, you’ll just recreate the same headache the next time around. Use tools you and your team are excited about, but don’t switch just to switch, and don’t make the mistake of thinking a new tool, library, or programming language will fix all of your problems. It won’t.
Assume good intentions
Whether you’re grappling with the fallout of your own decisions or someone else’s, give people the benefit of the doubt, especially if you’re communicating online. That unpopular abstraction? Maybe it was added to meet a deadline, or to satisfy a constraint you never knew about. Extend others the same grace you’d hope to receive when your own choices are being judged down the line.
Own your part, but don’t beat yourself up
Every decision carries some risk. Some won’t work out. If you, or someone you’re responsible for, makes a call that turns out badly, own the outcome. Accountability builds trust. A good leader isn’t someone who never makes mistakes, but someone who meets them with humility, learns from them, and gets better because of them.
But once you’ve done the work—reflected, made a plan, taken responsibility—move on. You don’t need to carry the weight forever. Setbacks are part of the process. What matters most is what you do next.