Understanding Technical Debt: Insights from the CTO of SafetyCulture
In the world of startups, technical debt is a term that often comes up in discussions among CTOs and development teams. To shed light on this critical issue, we recently had the opportunity to speak with Dan Harper (Homes.com.au) and James Simpson (SafetyCulture), two seasoned CTOs with extensive experience in managing technical debt. Their insights will provide some valuable lessons for those startups and scaleups aiming to navigate the challenges of technical debt while maintaining a competitive edge.
What is Technical Debt?
Before we get into the nitty gritty of how to navigate it, let’s take it back to basics by asking what is technical debt? Technical debt, or tech debt, refers to the consequences of prioritising speed and immediate gains over a more thoughtful, long-term approach to software development.
James explains, "It's decisions that we've made for today that are optimised for today that, in time, prove not to be the best or for whatever reasons they prove not to be the decisions that best fit in the future. And sometimes that's through a deliberate trade-off.”
In essence, technical debt builds up when quick solutions are chosen over robust, scalable ones. While these decisions might help a startup launch quickly or meet immediate demands, they can lead to significant problems down the line, requiring a large amount of time and resources to address.
Types of Technical Debt
Throughout our discussion, James and Dan identified two main types of technical debt: deliberate and accidental.
Deliberate Technical Debt: This happens when teams make conscious decisions to prioritise speed over quality, with a plan to address the shortcomings later. For example, launching a minimally viable product (MVP) quickly to capture market share, with the understanding that the underlying code will need to be refined later.
Accidental Technical Debt: This is more common and arises from unintentional decisions, often due to a lack of understanding or experience. As James puts it, "We look back and think those decisions weren't the best. That's when you start getting into different types of tech debt."
Managing Technical Debt: A Practical Approach
James shares a compelling example of managing technical debt effectively. His team faced a situation where the architecture of a product no longer aligned with market needs. They had three options: continue with the current system, rebuild from scratch, or pause development to rework the architecture.
They chose the third option, dedicating two and a half months to perform "open heart surgery" on the architecture. The result? "Once we got to the other side of it, the speed with which we could move was refreshing," says James. This strategic pause allowed the team to improve the product's performance and scalability significantly.
Selling the Idea to Stakeholders
One of the biggest challenges in managing technical debt is convincing senior stakeholders to invest time and resources in addressing it. James highlights the importance of framing the conversation around speed and quality. He argues that it's essential to provide tangible examples of how addressing technical debt will lead to faster development and higher-quality products.
However, he also acknowledges the discomfort that comes with committing to specific timelines. Engineering teams often struggle with this due to a fear of being held to account, however James believes that creating a culture where it's okay to take risks and potentially be wrong is crucial for overcoming this fear.
Bridging the Communication Gap
Dan and James both emphasise the need for better communication between engineering and business teams. Engineers often think in black-and-white terms, focusing on logic and certainty, while business leaders are more comfortable with risk and ambiguity. Bridging this gap requires engineers to become more comfortable with probabilistic thinking and to learn how to present their cases in terms that business leaders can understand.
James suggests that engineering leaders should focus on turning accidental technical debt into deliberate technical debt by making informed decisions and understanding the trade-offs involved. This means ensuring that the right level of experience is applied to each problem and maintaining clear communication about the reasons behind decisions.
Because many accidental technical debt issues arise from poor design decisions made by less experienced team members, James advocates for having seasoned professionals, such as principal engineers, involved in critical decisions to provide guidance and mentorship to less experienced team members.
Quality and Speed: Finding the Balance
Different products require different levels of quality, and it's essential to tailor the approach accordingly. James explains that while some products may prioritise performance and scalability, others might focus on data integrity or reliability. Setting clear quality standards for each product and involving the product and sales teams in defining these standards is crucial for achieving the right balance between speed and quality and reducing overall tech debt.
Addressing Tech Debt Head-On
Engineering leaders need to take a proactive approach to managing tech debt and understanding the root causes of it, whether deliberate or accidental, and addressing them systematically. By doing so, startups can ensure that they are building scalable, maintainable products that can adapt to changing market needs.
Technical debt is an inevitable part of software development, especially in fast-paced startup environments. However, by understanding its nature, making deliberate decisions, and fostering a culture of open communication and risk-taking, startups can effectively manage technical debt and continue to innovate and grow. The insights shared by Dan and James provide a roadmap for CTOs and engineering leaders to navigate this complex but crucial aspect of their roles.
Want to find your next top tech talent? Click here 👋
Join the conversation on LinkedIn 🎙️
