Too many bugs

Christopher is the co-founder and CTO of UberHire, a 5-year old online recruitment platform. Since the company's founding, Christopher's team had always prioritised adding new features, often on short-term deadlines, instead of fixing bugs and paying down technical debt. Both customers and colleagues complain that the platform is unstable and don't trust the engineering team. What should Christopher do?

Like most startup CTOs, Christopher did what he thought was his mission: ship new features so that the company could acquire new customers and, probably, raise their next round of funding. And everyone in the company was cheering him up at the time. This situation is a bit like aeroplane overbooking. Customers are happy to get an affordable plane ticket, only to discover at the airport that their seat was overbooked and they can't travel. There ain't no such thing as a free lunch.

While Christopher's current problem is to stabilise the platform and regain the trust of the "business", his less obvious problem is to fix his communication and how he manages colleagues and customers' expectations. A few years ago, I inherited a similar situation. The product I was managing was unstable, users were complaining, and one of the biggest customers was about to leave us for a competitor. When I heard about that, I was on the next plane to see them and came up with a solid resolution plan to solve the issues. Unfortunately, it was too late to save this customer, but they told me they would never have left if they had had such a plan a few weeks before.

And it's probably the same for Christopher. Because he didn't properly communicate the importance of fixing bugs and refactoring parts of the code, he ended up in this situation. Here is what I would advise Christopher to do:

1/ Make a full audit of the bug list and the code to determine what is needed to reach stability (from the customer's point of view, not the ideal refactoring).

2/ Craft written communication towards product and sales teams, ideally directly to customers, owning up to the "mistake" and announcing the stability plan with a clear deadline and the impact on the roadmap.

3/ Dedicate a good chunk of developers' time to bug fixing and refactoring (ideally 50% the first development cycles and then gradually decreasing to 20%). I don't advise focusing only on refactoring, as the business needs new features to grow, and the risk is to end up in an infinite refactoring loop. If possible, Christopher shouldn't affect bug fixing and new features to the same developers/teams, but instead, rotate them so everyone could have a turn at doing what they like. For the scheduling of the bug fixing sessions, Christopher could either do them every afternoon (bug fixing "happy hour") or dedicate entire days to it, depending on what makes developers more comfortable.

4/ Communicate the progress weekly to the whole company and ideally publicly to customers so that everyone can monitor what's happening.

5/ Organise a "stability party" when the team reaches their deadline to celebrate the developers' hard work and make peace with Product and Sales colleagues.

As a side note, if you're wondering how Christopher should tackle their technical debt, I usually like to think of it the same way as financial debt. One of the most known frameworks to manage debt is Dave Ramsey's Debt Snowball Method. According to Ramsey, "the debt snowball method is a debt-reduction strategy where you pay off debt in order of smallest to largest, gaining momentum as you knock out each remaining balance. When the smallest debt is paid in full, you roll the minimum payment you were making on that debt into the next-smallest debt payment." Applying this strategy to technical debt, here is how it should work:

Step 1: List your bugs from smallest to largest regardless of user impact.

Step 2: Make minimum fixes on all your bugs except the smallest.

Step 3: Fully fix the smallest bug.

Step 4: Repeat until you fix each bug.

The whole concept of the snowball method is that if you focus first on the largest bugs or refactoring, it will be a long time before you, the developers, and everyone else start seeing some results. Instead, fixing small bugs first will motivate developers to keep reducing technical debt and show customers that there is quick progress.