Gunning for growth? You’ll have to put the brakes on some time.
“Behind our booming business was a technology powder keg with a lit fuse.”
Kevin Scott, Microsoft CTO and former SVP of Engineering and Operations at LinkedIn
Kevin Scott’s article ‘When your tech debt comes due’ will strike a chord with many scale-up CTOs. Especially founding CTOs of start-ups that are just beginning to grow at scale.
Start-ups often take a ‘keep your eyes on the prize’ attitude to development. Decisions are shaped by the urgent need to achieve product-market fit, sooner rather than later. New features are rolled out at speed, and technical shortcuts have to be taken to avoid losing momentum. But these small and seemingly benign acts accumulate and can put a stranglehold on your ability to grow at scale further down the line.
This concept is known as ‘technical debt’. In essence, organisations borrow from the future to innovate faster today. But, as with financial debt, it needs to be managed and repaid to avoid negative repercussions. At LinkedIn, Scott found eight years of well-intentioned and individually innocent technical compromises were “placing a very real strain on our ability to scale the business and develop software as fast as we needed to. The more engineers we added to the team, the slower things got. And everyone was fed up with all of the friction preventing us from moving as fast as we wanted and needed to go in order to continue to grow.”
Accept, acknowledge, address
Don’t beat yourself up about technical debt. During the start-up phase, you have to get things done fast in order to survive. And if you’re not accruing a lot of technical debt during this phase of growth you’re probably doing something wrong. So, accept that debt is inevitable, acknowledge where it’s causing problems, and then develop a strategy to address the issue sensibly and strategically.
Technical debt doesn’t just exist in your software. We see it creeping into tooling, operational process, security, and infrastructure. For instance, when you had a small team of developers who fixed problems on the fly, you may have got away with poor (or even non-existent) test coverage. But as your team grows and applications become more complex, the cracks in this approach start to show.
Likewise, we’ve seen countless businesses, large and small, overlook infrastructure resilience in a bid to accelerate new feature delivery. We’ve even seen a long-unpatched deployment server accessible on a public IP address. Again, as the business scales, value-at-risk increases, and this debt needs to be addressed.
However, doing things right as you move forward won’t unpick the problems that are already embedded in the system. You need to go back over old ground to address those properly. And for that to happen, you’re going to have slow things right down.
Putting the brakes on
It’s all but impossible to tackle technical debt in a going concern while rolling out new features at pace. So sometime, somehow, certain things are going to have go on hold while issues that are hindering performance and efficiency are dealt with. It’s not easy to convey this to investors, stakeholders and product managers who are champing at the bit for new features and faster growth. But unless those issues are resolved, the burden will become heavier, causing discord and preventing the business from reaching its full growth potential.
At LinkedIn, Scott froze new feature development for two months while technical issues were ironed out. It was an unpopular move. But it was the right move: “by mid-January of 2012 we were once again able to deploy cool, new features to our members. Even in those first few weeks where there were raw edges and bugs in the development infrastructure, things were objectively better than they were before. By the middle of 2012, the results…were unquestionably positive.”
A stitch in time
That old proverb ‘a stitch in time saves nine’ is pretty apt when it comes to technical debt. Once you begin the transition from start-up to scale-up, seek the breathing space you need to start tackling this issue. Begin by acknowledging where the debt exists and the problems it’s causing or the risks it represents (the interest payments). Categorising the debt and assigning ownership may be helpful, but ultimately you need to make sure it’s repaid. Not all debt needs a major refactoring while everything else is on hold, but it will inevitably impact other work in the short term. So, be transparent, track it in your backlog and develop a culture where the importance of maintaining low-debt is recognised.
Successful businesses with long-term records of continued high growth are rigorous and unrelenting in their continual battle with technical debt. Don’t be ashamed of your technical debt – and don’t try to hide it. Sooner or later it will come to the fore, and it’s far better to take a planned approach than trying to deal with it late while things are falling apart around you.
For more advice on building high-performance IT capabilities in a rapidly scaling business, check out our CTO guide: ‘Onwards and Upwards’.