Get my email lessons on how you can build a tech team you can depend on.

When NOT releasing is the right thing to do.

Tom’s team is preparing a highly anticipated release, but QA hasn’t gone well.  More bugs were found than were anticipated.  Too many fixes have been of the hack-n-slash variety, meaning there could be lingering problems after the deploy.  There’s also a concern that tech debt is being accrued which will have to be paid later (with interest).

Tom considers his options:
1. Deploying on-schedule.  Deploying allows Tom to keep his commitment to his customers but may cause weeks of clean-up and unhappy users.  Sure, there will be a lot of clean-up, but at least his team will get credit for hitting the target.

2. Delaying the release.  Delaying means breaking a promise and explaining to customers (and bosses!) what went wrong.  It also may hurt the delivery team’s reputation and credibility.  But his team will have time to fix things the right way, and the users won’t be frustrated by broken software.

Stuck between a rock and a hard space, Tom ponders what to do.

Have you seen this?

What did you do?

What did you take into account in your decision?

How did your team feel?

About Marcus Blankenship

Where other technical coaches focus on process or tools, I focus on the human aspects of your Programmer to Manager transition. I help you hire the right people, create the right culture, and setup the right process which achieves your goals. Managing your team isn't something you learned in college. In fact, my clients often tell me "I never prepared for this role, I always focused on doing the work". If you're ready to improve your leadership, process and team, find out how I can help you.

Pin It on Pinterest

Share This