Startups often feel the need to discard the tech they’re working on and starting over. Here are some of the reasons why this happens . . . and how you can avoid a ‘big bang rebuild’.
‘We’ll probably have to rebuild this one day.’
What starts as an innocent comment can quickly turn into something that comes up at every technical meeting. The backlog is filled with bugs, and less of the sprint is focused on generating value for customers. Iteration cycles take forever, and new ideas are quickly shrugged off as impossible to implement.
Great effort is required for relatively low return and as progress slows, competitors start to rush past you. It’s demoralizing for the technical and non-technical teams alike. Eventually, it’s pure frustration for everyone.
If rebuilding is the topic on everyone’s list, it’s worth figuring out how you arrived here, before figuring out how to proceed. I’ve seen — and been in — this situation multiple times, so I can hazard a few guesses.
At the time, it made business sense: you needed to close the deal, implement the feature, and close the partnership. However, shortcuts can have a nasty habit of coming back to bite you. If you don’t spend enough time refactoring code, the interest on your technical debt will go through the roof.
Failure to invest in refactoring could be a symptom of inexperienced technical leadership, but it’s often down to technical leaders lacking empowerment . . . or maybe even being ignored altogether.
The design process needs to marry customer needs with technical feasibility. If you’re only involving programmers once the design has been finalized, you’re unlikely to make best use of your existing technology.
This leads you to create bespoke solutions, rather than leveraging existing libraries, conventions, or off-the-shelf solutions. It’s easy to underestimate how expensive custom code is to maintain.
Waterfall development is characterized by long iteration cycles in which scope is fixed. This can be useful for projects with a very high degree of technical and business certainty, but startups are about as uncertain as they come. As a result, a waterfall approach routinely leads to over-building and feature bloat.
This is in stark contrast to agile methodologies, which emphasize the importance of iteration and building feedback loops that allow you to accommodate your customers’ changing needs.
A ‘big-bang rebuild’ is appealing for a variety of reasons. It represents a blank canvas onto which you can project your hopes and dreams,. and best of all, there’s no more dealing with complicated code written by someone else.
However, by pursuing a big bang rebuild, you might be perpetuating most of the mistakes that led you here in the first place. Locking in scope and expecting nothing to change for six to twelve months is inevitably going to fail. It’s the antithesis of adapting to changing customer needs.
What’s more, big scopes are destined to be underestimated. Complexity increases exponentially with scope, so working on a large project that’s four times bigger is sixteen times less certain. Whatever your most conservative release dates might be, add six to twelve months (at least).
The initial excitement of any new project will soon wear off, and a few weeks in, the tech team will start to become demotivated. They’ll have underestimated many of the complicated challenges that are likely to come up. And as they won’t be shipping to customers regularly, most of their work will be completely invisible — not only to customers, but to the team at large.
If the product doesn’t improve over an extended period of time, non-technical employees in marketing and sales will feel trapped, and they’ll jump ship faster than rodents on the Titanic. Once the deadline is missed, the whole company’s morale will fall off a cliff.
The alternative to a big bang rebuild is far less appealing: think slow migration, not big bang. Rather than approaching all the different problems at once, look to slice off those problems one-by-one.
Here are a few tips to help you undertake a slow migration process.
If ‘rebuild’ keeps coming up it’s a signal that your team is frustrated. Try this exercise with your team: ask them to imagine that the rebuild is finished and the tech works perfectly. Then, pose these questions:
By asking these emotive questions, try to get the specifics of what will really make a difference to your team. This will help you focus your efforts on the real issues.
A rebuild is often a great time to invest in agile training for the whole team. And in my experience, agile training has a massive return on investment, giving team members a common framework to tackle problems just like this.
By the time you reach the need to rebuild, you’ve probably accumulated features that very few customers actually use. There’s no rule that says you must replace every single feature. Instead, look for opportunities to kill features and simplify your product.
Once you’ve broken your tech down into manageable chunks, prioritize the rebuild on a one-by-one basis, focusing on the smallest chunks that add the biggest customer value.
It’s tempting to take an incremental approach and keep working on the next thing. Instead, ensure that you make time to improve your existing code. For example, you could assign 25% of sprint resources entirely to proactive refactors.
A technical crisis is a true test of leadership for every founder. Migrating is never going to be the most popular option, nor the most exciting. But it’s likely to get you a better result than a rebuild.
Just as with every leadership challenge, it’s going to require a lot of empathy — and a lot of listening to your team. Communication is key and it takes discipline to keep the team aligned. And lastly, you need patience — there is no quick solution if you’re in this situation. Things are going to take longer than you want . . . which is why it’s time to be a little more agile.
Thoughtful essays on growing teams, building products and raising money by Serial Entrepreneur and Investor, David Bailey.