Tackling Tech Debt in Small Companies
Practical Strategies for Avoiding Development Hell
Audience: IT and development professionals, managers and business owners
Contents
The Definition of Technical Debt
Executive Summary
Introduction
· History Repeats Itself (Endlessly)
· Tech Debt as Organizational Cancer
· The Major Risks of Technical Debt
· Key Takeaways
· Notable Business Failures Caused in Part or Primarily Due to Tech Debt
The Path from Tactics to Strategy
· Minimal Viable Product (MVP)
· Keeping an Eye on the Bigger Picture
· Growth: Creating Order from Chaos
· Governance Matters
Conclusions
The Definition of Technical Debt
Technical debt refers to the future cost incurred when developers take shortcuts to expedite project delivery, resulting in suboptimal code, outdated infrastructure, or inadequate documentation that necessitates significant and costly additional work later. It is characterized by increased maintenance costs, frequent bugs, and slower development cycles.
Unlike routine business trade-offs, which involve temporary compromises with minimal long-term impact, technical debt accumulates interest in the form of reduced efficiency and scalability, ultimately hindering innovation and growth. Recognizing technical debt involves identifying recurring issues, dependencies on legacy systems, and a noticeable drag on development velocity.
We explicitly exclude from the present discussion debts better described as shortcuts in policy, company governance, compliance or culture, reserving these topics for the future. Although it should be clear that technical debt and governance interact in complicated ways, the former is primarily a technical question while the latter falls more into the category of politics and power relations, far less well understood and significantly more controversial. We’ll somewhat arbitrarily separate the two and pick off “mere” tech debt as the lower-hanging fruit for the present.
Executive Summary
Tackling Tech Debt in Small Tech Companies is a planned series of articles which provides a comprehensive guide for decision makers and managers to understand, identify, and manage technical debt effectively. We emphasize the strategic importance of addressing technical debt to prevent disasters, enhance productivity, innovation, and overall business success. Perhaps more importantly, long DevOps experience has taught us that accumulated tech debt can literally cripple a development effort if done inadvertently or mindlessly, a result any rational enterprise must avoid at all costs.
Understanding Technical Debt: We begin by explaining the origins, causes, and types of technical debt, highlighting its significant impact on small tech companies. We underscore the necessity of recognizing and addressing technical debt to avoid long-term detrimental effects on productivity, quality, security and innovation. In particular, we emphasize the intense necessity of taking on tech debt deliberately and with full awareness of the trade-offs made, likely consequences, future costs, and how to pay off that debt when the maturity date arrives.
Identifying and Prioritizing Technical Debt: Practical techniques for assessing and prioritizing technical debt are discussed, including tools and metrics for monitoring. The article guides readers on creating a technical debt backlog, ensuring that the most critical issues are addressed first. Perhaps most important of all, we offer ways of discovering past accumulated tech debt, which is likely to be undocumented. New managers and owners, entering into an ongoing enterprise previously established and developed by other people, perhaps no longer employed at the company, will need methods of assessing the often invisible tech debt accumulated prior to their involvement.
Strategies for Tackling Technical Debt: The core of the series presents actionable strategies such as routine discovery that debt is being incurred, planning for later settlement, code refactoring, improving documentation, and implementing automated testing. These strategies are supported by real-world case studies, demonstrating their effectiveness in reducing technical debt.
We believe the most important aspect of the tech debt arena is knowing that the debt is being incurred in the first place. Too often, technical debt happens at a low, often individual contributor level, most frequently to meet deadlines. Management never knows it happened, and often rewards the perpetrators for meeting the tight deadlines, rather than disciplining them for deliberately incurring and concealing hidden business risk.
The tendency of both individual contributors and management to experience job mobility, whether coerced or deliberate, exacerbates the ill effects of tech debt, effectively occluding it from decision makers who might otherwise be positioned to deal with it in a structured and deliberate manner. Laid-off employees, after all, have little to no incentive to inform remaining management of what they have done; the same goes, perhaps to a lesser extent, to employees voluntarily moving to a new position at a different company.
We also feel obligated to point out that the large-scale overuse of Agile methodologies, whether scaled or not, has further obscured the capability of senior leadership to understand and properly handle technical debt. From our point of view, Agile, in all its various forms, better fits a strictly tactical designation and should be viewed and used accordingly. It is fundamentally a short-term mindset, intended to present working software in an upcoming, near-term demonstration. It cannot replace operational nor strategic paradigms by its very nature.
Later, we will more thoroughly characterize the several development activity spheres. At this juncture, we borrow military terminology and merely point out that, most of the time, strategy (long-term) must dominate operations (medium-term), which in turn must dominate tactics (short-term). The world of software development has for too long abandoned the need for medium and long-term planning, leading to the steady decline in software quality over decades and the rise of frequent and often devastating security and operational issues.
Integrating Debt Management into Workflow: We advocate management acknowledgement of and openness on the subject, especially when it comes to direct reports practices. Managers should know when their direct reports take shortcuts, document the shortcuts taken and the “correct” way the work should have been done. A process must be created and maintained for incorporating technical debt management into daily operations through Agile and DevOps practices, regular reviews, and audits. Emphasis must be placed on the importance of building a culture of quality and continuous improvement within the organization.
Types of Stakeholders: For simplicity purposes, we identify only three major classes of stakeholders in an enterprise. The only properties we consider are gains and losses, which converts our topic into an instance of (hopefully) cooperative game theory.
Equity stakeholders are the owners of the business. If the business is successful, they stand to gain financial independence or even great wealth. If not, owners stand to lose their initial investment, their time, and possibly their livelihood.
Employees work for the business for a paycheck, possible promotion and possible stock options. If the venture is successful, they continue receiving at least their paychecks. If unsuccessful, they risk suddenly finding themselves unemployed.
Customers pay the business for goods and services. If the business is successful, they can continue to depend on the business for those goods and services. If not, they might find themselves having to seek new providers, sometimes at a considerable disadvantage.
These categories can overlap; active owners work as employees at the business, most often in a management capacity; employees can occasionally become part owners and frequently are also customers; customers can likewise buy an equity stake in a business and perhaps sit on the board of directors.
Leadership and Organizational Changes: The role of leadership in managing technical debt is highlighted, with a focus on engaging stakeholders, particularly equity stakeholders, and fostering a culture that prioritizes quality. The series includes cautionary tales, success stories and common pitfalls, providing valuable lessons for leaders.
Tools and Resources: The series includes recommendations for tools and resources to help manage technical debt, along with templates and checklists for practical implementation. This section ensures that readers have the necessary tools to start making improvements immediately.
Upshot and Goals: By following the strategies outlined in this article, small tech companies can begin to minimize the covert, careless or dishonest use of shortcuts, and eventually, effectively manage technical debt, leading to better reliability, enhanced productivity, innovation, and long-term success. Continued leadership effort towards exposing software time-bombs, and dealing with them rationally, will gradually lead to better and constantly improving control of overall development processes, eventually enabling true operational and strategic leadership and far more reliable and secure product.
Introduction
History Repeats Itself (Endlessly):
The New Development Manager
The new development manager, hired subsequently to the previous manager’s departure, convenes his first meeting with his team. He has a mandate from his management to find out what’s holding up development of new product features and bug fixes, and is optimistic he can accomplish this within the tight deadlines given to him.
As he scans the people in the meeting room, he sees a lot of serious to grim expressions on the faces of his team. He gets an uneasy feeling, but soldiers on and starts the meeting anyway. He asks the team leads to give a two-minute summary of the last several sprints to help him get oriented.
As each lead speaks, he understands that he is dealing with solid, careful professionals who know exactly what they have been doing. Each in turn describes the recent development history, always with mention of trade-offs taken and always referring to the development schedule, hinting that the schedule is excessively aggressive, necessitating various shortcuts taken to meet the deadlines. He listens intently and silently as the team leads speak their pieces.
Once the last one has spoken, he opens up the floor for commentary from the developers. Many of them offer their comments, re-enforcing the hints made by the team leads. The new manager gets the definite feeling that they have been talking with each other previously and coordinated their comments. From long experience, he knows that developers often disagree with each other during meetings, something noticeably lacking in this meeting. His gut tells him something is wrong.
He wisely decides not to bring it up during the meeting and makes a note to himself to have one-on-ones with every member of the team, starting with the leads. Instead, he spends a little time describing the goals management has asked him to accomplish and roughly outlining the timeline. He takes pains to note to the assembled team that he is aware the schedule is aggressive, but that external competitive pressure is the primary driver of the schedule.
With that, the meeting wraps up and the team leaves. He catches the eye of the senior lead, and motions him to stay after everyone else leaves. The rest file out, and he and his senior lead sit to have a serious talk. He notes to the lead that he has detected issues and asks the lead to tell him honestly what has happened and why development is nearly at a standstill.
The lead takes a deep breath, looks the manager in the eye, and tells him he is considering several other jobs and has already interviewed for several of them. He expects at least one job offer, and tells the new manager straight up he is likely to take another job if offered.
When asked why, the lead explains patiently all of the trade-offs the team has had to make to meet the schedule, that he has documented all his concerns meticulously in the work flow system, and brought them up at every opportunity, but that senior leadership has repeatedly ignored or minimized the issues. He adds that he is aware other team members have been quietly job hunting, guesses that more are doing so quietly, and that an exodus of team members can be expected if something major doesn’t change, soon.
The new manager takes the time and effort with the lead to understand what has happened, how it can be fixed, and how long it will take. He thanks the lead for his frankness and thoroughness, and asks him to consult again before accepting another job offer.
Using this intelligence, the manager interviews every team member, starting with the leads, and collects a list of issues that have to be fixed before any new development can happen. He puts all of it together into a single report, and schedules a meeting with his own management.
He has a dilemma on his hands; a good team of developers, most of whom are fed up with senior leadership and have little or no faith that anything will change; senior managers who are habituated to unrealistically aggressive schedules and callously ignoring developer gripes, and a potential mass exodus of a significant fraction of his team. He develops a plan for dealing with the problems in as organized a manner as possible. He also, on his own time, calls several of the other companies he has interviewed with recently, to let them know he might be back on the job market, soon.
Tech Debt as Organizational Cancer
It is trite but true that companies hire technical expertise for good reasons. Owners and management can’t write all that code, test it, build the systems, and support them, by themselves. Unfortunately, too often, senior leadership winds up believing they know more about software development than the people who actually do it, a perfect example of the fallacy of false attribution, also known as the “False Economy” fallacy.
Management, over time, often comes to view their staff as replaceable, drop-in “resources”, that aggressive development schedules are the real reason for past successes, and that tech debt is just normal business, and ignorable whining on the part of their staff. When that debt comes due, in the form of staff exodus, cobbled-together, low-quality product that is fragile, insecure, very difficult and expensive to fix, causing exploding support costs and resultant poor customer relations, loss of reputation and business, senior leadership and equity stakeholders are often caught by surprise. Perhaps their colleagues who actually appreciated the dire situation already left the company in frustration.
The cartoon above captures a large part of the problem. People, including managers, frequently job-hop, and, after they have definitely decided to leave for other options, have little or no incentive to document the issues, warn their management nor successors regarding accumulated tech debt. Enough of this happening over only a few years can cripple a company, silently. The owners who trust management to stay on top of shortcuts taken will be the last to know.
The lead-off story outlined above has happened again and again, and is still happening as we write this article. The pernicious interactions between tech debt, job mobility, self-interest and loss of vital company status information, the so-called “tribal knowledge”, continue to plague the tech industry to this day. Larger companies can often ride out the waves and recover, but for smaller companies with more limited options, this often isn’t so, contributing to the very high failure rate characteristic of small companies.
We liken tech debt to cancer; the victim rarely knows they have it until they receive grim news from a doctor. Cancer can and does kill people every day. Tech debt can and does destroy companies, likewise every day. The stealthy nature of both illnesses and the sudden, often catastrophic surprises motivates our comparison.
This present article is an introduction to a planned future series devoted to exploring systematic methods of using tech debt deliberately and wisely as one of several competitive tools available to leadership, and properly managing the risk from doing so.
The Major Risks of Technical Debt
Outages and service interruptions due to accumulated technical debt tend to happen at unpredictable times, with the severity of the issues ranging from negligible to show-stoppers. Since tech debt is rarely discussed nor quantified, it can accumulate invisibly, and cause major issues for the business.
A common enough example comes through the lapse of proprietary software licenses, or continued use of deprecated or discontinued software and/or hardware after its end of life. Both software license renewals and upgrades to software and hardware cost money, and are frequent subjects of neglect.
Proprietary software houses employ auditing and tracking of licensing, typically on an unannounced basis. The resulting fines and sudden costs, not to mention loss of support services, can easily be catastrophic for the company which neglects its contractual responsibilities.
Older software and hardware, especially after vendor support has expired, can contain exploitable bugs or fail entirely, again with potentially catastrophic results. Imagine the chaos that would happen if a Windows shop suddenly had no choice but to deploy Linux everywhere; yet this is a relatively benign example.
The important point to remember about sudden problems related to past tech debt such as these is that equity stakeholders will have to pay the damages. In extreme cases, they might find themselves the subject of lawsuits. Depending on the planning and financial condition of the owners, such issues can end the business, and rather suddenly.
Key Takeaways
The key concepts to take away from our development are:
Incurring tech debt is often necessary for time-to-market and competitive reasons.
Tech debt necessarily comes with enhanced, often hidden business risks, in that it is easily forgotten, later overlooked, and tends to return to awareness at inconvenient times.
It always involves higher costs for later, more systematic fixes or refactoring.
The likely consequences of short-term decisions to take on tech debt can and should be considered, consequences estimated and documented, and plans for later resolution, including costs and time, must be part of the decision-making process.
Senior leadership, and particularly owners, must know when technical debt is taken on, must know why, what risks are being incurred, must know how it is to be resolved, how much it will cost, and must be part of the decision-making process.
Equity stakeholders have the most to lose from poorly managed accumulations of tech debt. Non-equity stakeholders can always look for another job; owners are stuck with losses when the value of their holdings evaporates.
Notable Business Failures Caused in Part or Primarily Due to Tech Debt
It is instructive to consider recent, high-profile examples of business failures where technical debt played a significant role. We note that the businesses that ultimately failed below were at one time large, ongoing, successful enterprises, for a time, and the failures were not always due to tech debt alone. Our position, and reason for presenting these examples, is to point out that small businesses are significantly more vulnerable to issues caused by tech debt.
1. Nokia
Nokia was once a dominant player in the mobile phone market, but it failed to keep up with the rapid advancements in smartphone technology. A significant part of Nokia's struggles was due to its outdated Symbian operating system, which was burdened by technical debt. The complexity and inefficiency of Symbian made it difficult for Nokia to innovate quickly enough to compete with Apple's iOS and Google's Android. Eventually, Nokia's market share plummeted, leading to the sale of its mobile phone business to Microsoft.
2. Blockbuster
Blockbuster was a giant in the video rental industry but failed to transition to digital distribution effectively. While not entirely a case of technical debt, Blockbuster's failure to invest in new technology and digital infrastructure meant that it was ill-prepared to compete with more agile and tech-savvy companies like Netflix. Blockbuster's legacy systems and resistance to change left it with a cumbersome, outdated business model that couldn't compete in the digital age, leading to its eventual bankruptcy.
3. BlackBerry
BlackBerry, known for its secure and reliable mobile devices, fell behind in the smartphone race due to its technical debt. The company's proprietary operating system and focus on hardware over software innovation caused it to miss critical trends in touchscreens and app ecosystems. Despite its early lead in the mobile market, BlackBerry's inability to pivot and update its technology stack led to a rapid decline in market share.
4. Myspace
Myspace was one of the first major social networking sites but was quickly overshadowed by Facebook. Myspace's downfall can be attributed in part to its technical debt. The platform's codebase became increasingly difficult to manage and scale, leading to frequent bugs and poor user experience. Additionally, the lack of investment in infrastructure and new technology made it hard for Myspace to innovate and keep up with competitors.
5. Lehman Brothers
While Lehman Brothers' collapse was primarily due to financial issues, technical debt played a role in exacerbating the crisis. The company's IT infrastructure was outdated and unable to provide accurate, real-time data, which hindered its ability to manage risk effectively. This lack of technological agility and insight contributed to the firm's inability to respond to the rapidly unfolding financial crisis.
6. Credit Suisse
This example is in a class by itself: the almost total collapse of the second largest, and oldest major Swiss bank. The story is long and complicated, and we cannot do it justice here. Nevertheless, part of this complex story involved our subject matter, and is worth careful study.
Credit Suisse, a major global financial services company, faced a multitude of challenges that led to its eventual, government “encouraged” acquisition by UBS in 2023. While the primary causes of Credit Suisse's downfall were related to management failures, risk management issues, and involvement in several high-profile scandals, technical debt also played a significant role in its struggles. Here’s how the fall went down, and how it was related to technical debt:
Role of Technical Debt in Credit Suisse's Downfall
Outdated IT Infrastructure:
Complex Legacy Systems: Credit Suisse, like many large financial institutions, relied heavily on a complex web of legacy IT systems. These outdated systems were difficult to maintain and update, leading to inefficiencies and increased operational risks.
Integration Challenges: Mergers, acquisitions, and the organic growth of Credit Suisse over the years resulted in a patchwork of disparate IT systems. Integrating these systems was challenging, in fact, fantastically expensive, and often led to delays and increased costs.
Inadequate Risk Management:
Delayed Upgrades: Due to the burdens of technical debt, necessary upgrades and enhancements to risk management systems were often delayed or deprioritized. This left the bank ill-equipped to manage and mitigate risks effectively.
Data Quality Issues: Legacy systems often struggle with data quality and consistency, which can impair a company's ability to make informed decisions. For Credit Suisse, poor data quality likely contributed to inadequate risk assessments and management failures.
Cybersecurity Vulnerabilities:
Security Risks: Older systems are more vulnerable to cyberattacks due to outdated security measures and lack of regular updates. Technical debt can leave organizations like Credit Suisse exposed to cybersecurity threats, further complicating their risk profile.
Broader Impact of Technical Debt on Financial Stability
While technical debt was not the sole cause of Credit Suisse's collapse, it exacerbated existing issues and hindered the bank's ability to respond effectively to crises. The combination of outdated IT infrastructure, inadequate risk management, and integration challenges due to technical debt compounded the impact of strategic and management failures.
In the financial industry, where timely and accurate data is crucial for decision-making and risk management, the inability to modernize and maintain IT systems can have severe consequences. Credit Suisse's experience underscores the importance of addressing technical debt proactively to maintain operational efficiency, manage risks effectively, and remain competitive in a rapidly evolving market.
Conclusions the Collapse of Credit Suisse
Credit Suisse's collapse was a multifaceted issue, with technical debt being one of the contributing factors. The challenges posed by legacy systems, integration difficulties, and outdated risk management capabilities highlight the critical need for financial institutions to invest in modernizing their IT infrastructure. By doing so, they can enhance operational resilience, improve risk management, and better navigate the complexities of the financial landscape.
These examples illustrate how failing to address technical debt can leave companies exposed and vulnerable to more agile competitors, prevent them from adapting to market changes, and ultimately lead to their decline or failure. Fire-fighters are not system builders.
While the study of business failures should not be an obsession, we are of the mind that, especially in the early days, avoiding failure might very well be a small business’s most important priority. In light of this, we think that at least some regular consideration of business failure can serve the entrepreneur well, assisting in the perilous initial journey into business and in particular, to better guide tactics. Tactics, supporting nimbleness, must play a deciding role in a new business, with operational and strategic thinking delayed, at least for a time.
The Path from Tactics to Strategy
Having worked in DevOps for decades, we know that every software developer needs to be able to pump out quick, crude solutions to programming problems; it’s part of their skill set and absolutely necessary to satisfy time-to-market. Thus, programming “correctly” or “doing it right” from the start isn’t always practical, nor even possible. The initial priority is getting small pieces of crude software working as soon as possible, with the expectation of later, step-wise improvement.
This is why Agile is popular; it fits the chaotic initial phases of development, and is fundamentally tactical in nature. That being said, leadership that allows their operation to remain in Agile mode forever are taking large risks that eventually will catch up with them. As previously observed, equity stakeholders hold most of this long-term risk, and will need to remain vigilant lest their investment crumble under the mass of accumulated technical debt.
Wise leadership must steer their operations, however gradually, towards increasing degrees of planned operational and strategic execution. Part of this process will be the gradual introduction of modes of operation which resemble waterfall software development lifecycles increasingly as time passes. Doing otherwise risks considerable liability; we remind our decision making readers that software is a highly litigious business, regardless of disclaimers and EULAs.
Minimal Viable Product (MVP)
Nearly every nascent software organization must understand the concept of minimal viable product (MVP) and produce such software as the first iteration of their product. While mostly intended for demonstration purposes, the MVP gives the company a first chance to show their new product to prospective customers.
MVPs are almost always crude and riddled with tech debt. The priorities at this stage are simple: produce working software that is not too difficult to use, get it into the hands of a few initial customers who need it, with the understanding that those customers will provide feedback vital for the next few iterations of the MVP.
It goes without saying that those customers usually lack the resources to produce their own software; they have their own business work to do that may have little to do with software production. Providing feedback for development of software they need is far cheaper; the customers are essentially delegating software production and helping, in a business sense only, our development company enhance and improve their products and services.
Such arrangements happen all the time, often concentrated at the emerging frontiers of the industry. The customers in this situation can neither buy nor make the software they need, and so enter into an arrangement with the developers for mutual benefit.
Regardless of any vision the developers may have (i.e. operational or strategic notions of how development should go in the future), at this point, they are firmly in the tactical camp, and must take their customer’s feedback and feature requests as gospel to remain marketable. There is nothing wrong with the development process so far; this is a very common pathway for bootstrapping a software business.
Keeping an Eye on the Bigger Picture
During this phase of development, the programming team is likely small and nimble, and haply capable of fulfilling their customers’ needs. Leadership, on the other hand, needs to take enough time during the process to consider several important points towards developing first operational, and later, strategic planning.
The software being developed is littered with tech debt, of a necessity. As each such shortcut is encountered, it makes sense to consider the consequences, potential, possibly progressively sophisticated future fixes, later integration difficulties and costs, figured in at least three variables: staff requirements, time-to-market and total costs. The initial estimation of tech debt need not be sophisticated, but it does need to be complete enough to figure likely costs.
The shortcut taken should be documented in some sort of workflow system that leadership and programmers access frequently, perhaps indexed for easier future retrieval. The point of this habit is deliberate incursion of tech debt, with estimation of the cost of future fixes.
Priorities at this agile stage will be fluid and may not involve immediate shortcut fixes, but the pathway to such a fix when needed is already considered and documented. It is easy to imagine a startup software company generating a profusion of shortcuts in the early days, and that retaining customers takes priority over “doing things right”.
The difference between a company that operates in this way and a typical, chaos-driven startup are like night and day. Leadership is aware of the issues with their product and has insisted on leaving a trail of breadcrumbs so they can quickly find their way back to a previous shortcut decision, and take up a fix when and as needed.
Programmers are left more free to solve the many short-term issues that naturally arise in a rapid development scenario, with less chance of interruptions or chaotic, last-minute re-prioritization; they actually can finish more of what they start, important for their personal success, reduction of turnover, and arguably important to the overall success of the project.
Growth: Creating Order from Chaos
Shepherding a small, nimble, but chaotic software startup group into a mature organization capable of creating and maintaining reliable software is no small task. One need only look at the statistics: large companies are small in number compared with small companies, pointing to a high failure rate, and/or many mergers and acquisitions along the way.
Large companies are hard to manage well, and almost all of them eventually develop into soulless bureaucracies, with many layers of management, increasing office politics, and, almost inevitably, little to no regard for the welfare of their employees. Moreover, founders of startups, along with their equity investors, will, eventually and understandably, want to cash in on all their hard work, implying some kind of liquidation event such as an initial public offering (IPO) or outright sale. Once that happens, the founders lose control to other investors, even in the case where they retain a stake. The company changes character and culture rather quickly.
Prior to that happening, the startup has to grow, from perhaps one individual with a dream and a business plan, into a small group of dedicated hopefuls, later into a thriving small business, and finally into a medium sized business in a position for an IPO or sale. This process takes a long time, and there are many opportunities for failure along the way.
Proper control of tech debt during this growth phase is a necessary, but not sufficient, condition for success of the enterprise. Other necessary, but again, insufficient ingredients include sales, customers, financials, (possibly) investors, staffing, management and luck; these are subjects for future articles. Our focus in this piece is control of tech debt, since out-of-control debt is easy to accomplish, often fatal, and potentially quite difficult to manage.
Above we described a procedure deliberately creating a way of recognizing technical debt, estimating its future cost and effort, and documenting the specific instances in preparation for eventual fixes and integration. We also intimated that such a process is nearly inevitable; creating and managing a commercially important software project is a long process, at least partially dependent on skillful navigation of expedient, but deliberate trade-offs along the way.
Governance Matters
As noted earlier, we limit our discussion here to technical debt. We merely note that, at some point in the growth of a company, how it is managed, i.e. governance, becomes more important than what it is managing (product). Leadership should understand that this transition will occur at some time during growth, have markers and perhaps even metrics in place for when it is happening, detailed plans for managing the change, and be prepared for the often uncomfortable growing pains that accompany this maturation step.
We’ll note that this transition is made much harder if leadership has neglected resolving technical matters along the way, to the point where liquidation of the company has been stopped, cold, due to discovery by prospective investors of significant product issues. More than one company has been forced into a fire sale of its assets and receivership due to this unfortunate phenomena. Few outside such a company debacle would view it as other than an unforced error.
Conclusions
Technical debt is but one of many devils that can beset a growing company. We have proposed here that:
Time-to-market and competitive pressures can make taking on tech debt imperative, especially early on; “quick and dirty” beats perfection almost every time.
Deliberate decisions on using tech debt are a must, to prevent later “Monday morning problems” from compromising the company efforts, stalling development, and possibly threatening its survival.
Decisions about when and how to resolve past tech debt should be a regular and routine part of the development cycle, with sufficient resources reserved for debt reduction when circumstances warrant.
Proper management of technical debt is a must, from the start.
Eventually, if a company continues to grow, governance becomes more important than mere technical matters. Most tech debt needs to be resolved by this point.
Future, more detailed articles on the subject of technical debt will be linked here once composed. Those articles may be reserved to our paywall, planned to be implemented in the near future.
More information about Overlogix can be found at Welcome to Overlogix! Our Substack, now our main content repository, is online and available for browsing. An index of Substack articles can be found at this link.
Our online portfolio can be found at our LinkedIn master index. Our articles on applied AI are indexed at our Applied AI index, business topics at our B2B Business Index, and our TL;DR series of rapid introductions to AI and related topics lives at our AI Mini-Wiki. Critical information on getting a job are detailed at our Getting a Job index. AI news, including our list of curated links to articles of interest, can be found at our AI News page.
Thanks for reading! More to come!