How to Fix a Broken Release

Greg Thomas
4 min readOct 11, 2022


At some point in your career, you are going to run into a software release that is either teetering on the brink or has gone completely off the rails. Not everyone will know there is something wrong, but you will, it will be gnawing at you in each and every status meeting, with each discussion on who is working on what, with every bit of confusion that you see with the team you will come to the conclusion that yes — this release is broken.

There might be those on your team that might feel the same way (and possibly know it for a fact) but will hide behind the familiar refrain — “we can’t stop and do nothing, we have to keep fixing it along the way”.

Have you ever seen someone change a tire while the car is barrelling down the highway?

Me neither.

You need to stop it, to change the tire, so it can get back on the road, and this is where we start.

Stop What You’re Doing

You know there is a problem, so now it’s time for everyone to stop what they are doing and investigate what that problem is. This doesn’t have to be some great massive proclamation at your next stand-up, it’s simply getting the key people together and making them aware of what will happen if you keep on this path.

In these meetings, the path to success is paved with what comes next as everyone always knows there are problems, but having a plan and a timeline for when they can be resolved is what is truly needed. However, I started with “Stop What You’re Doing” because this is for you, Stop, you know something is wrong, now is the time to fix it.

Identify all the Issues

Make a sheet with two columns, what the issue is, and what the impact is. The impact could be anything from team cohesion, accruing technical debt, not meeting customer needs, or simply taking too much time to get simple tasks done. What matters most here is that you identify what the issue is and what the impact is in a clear, concise manner.

You started this process with a gut feeling, that’s great, now you have to quantify it. If you can’t quantify it, you are going to have a hard time getting everyone else on board.

What’s the Plan?



Greg Thomas

Software Architect, Developer, Author and Leader helping organizations build scalable software delivery teams and implement cloud-based solutions