“The fact that you have technical debt is a good thing.”
I know this sounds counterintuitive.
A senior developer with over 20 years of experience once told me this, and it completely changed the way I thought about technical debt—especially in the fast-paced environment of small startups.
In case if you’ve never heard of the term, technical debt refers to the hidden costs and risks that accumulate in a codebase when shortcuts or compromises are made to achieve short-term goals—such as delivering new features quickly. For example, delaying updates to core dependencies or skipping key testing steps can accelerate development in the moment. But over time, these decisions add up, resulting in a backlog of issues that eventually hinder the team. This debt can lead to a range of future problems, including compatibility issues, maintenance challenges, performance limitations, and even security vulnerabilities. As technical debt grows, each new feature becomes harder to implement, testing becomes more cumbersome, and the system itself becomes more fragile.
When I joined the company as a junior developer, the company was already dealing with significant technical debt, and I struggled with it for over two years. For example, in 2023, while Rails 7.1 was available, we were still using version 5.2. This version lag limited our ability to use newer features and frameworks and left us with outdated dependencies. Furthermore, many libraries had critical updates available, but they hadn’t been applied (fortunately, we hadn’t experienced any security breaches). Additionally, there were several design flaws and coding practices that caused confusion, even among the developers. The lack of proper testing also made it difficult to ensure stability. However, when I observed the tasks assigned to developers, the focus was always on releasing new features by a set deadline. Nobody seemed to address the growing technical debt, and the codebase kept becoming more complex with each new feature built on top of it.
As I grew more anxious about the code’s state, especially as security patches continued to be ignored, I decided to bring up my concerns with a technical advisor at the company. I expected he might encourage me to push harder for code quality or maintenance efforts. Instead, his response completely reframed my perspective.
He explained that, having worked with many startups, he’d seen that most of them failed before they ever accumulated significant technical debt. “The fact that we’re facing these problems,” he said, “is a sign that the business has survived long enough to reach this stage.” This was actually a positive indication: it meant the company was moving forward, gaining users, and facing the same challenges that most successful companies face over time. Without this technical debt, we might not even have a product to work on. He also stressed the importance of prioritizing business success. “In order to for you to keep a job as a developer, the business needs to succeed first and foremost,” he said. “Everything we do should be driven by how it impacts the business, not just by technical concerns.” While code quality and system stability are important, he reminded me that our job as developers is to support the business—sometimes, that means balancing technical debt with the urgency to grow.
That said, he emphasized the importance of always being aware of technical debt and continuously improving the codebase. For developers who don’t control project priorities or tasks, it’s crucial to have good communication skills when discussing the state of the code. For example, if you come out and say, “There are technical debt and security issues, and it’s a problem that needs fixing,” non-technical stakeholders might just see a working product and not understand the urgency. However, if you frame it like this: “Currently, there are unpatched security vulnerabilities in key libraries that could be exploited by hackers. If left unaddressed, this puts the company at risk for data breaches, potential financial losses, and serious reputational harm, as seen in cases like Company XX.” Or, you could add, “Upgrading these libraries will not only mitigate these risks but also reduce ongoing costs, enhance the user experience, and streamline the development process, helping our team to work more efficiently.”
After the talk with him, I believe the way I communicate—not only within the dev team but across the entire company—has improved. By shifting the focus of the conversation to “How can I contribute to the success of the business?” rather than simply saying “Some problems need fixing,” decision-makers are more likely to pay attention and engage in the conversation. Framing the issue in terms of business impact makes it easier to align technical challenges with company goals. As a result, it becomes clearer why certain improvements are important, and it promotes a more collaborative approach to solving problems. Plus, it helps keep everyone on the same page—developers, business stakeholders, and the entire team working toward the same goals.
Top comments (0)