I've been an entrepreneur for as long as I can remember. As a kid, I started selling cool rocks even before I sold lemonade. At age 8, I hired my two friends to deliver newspapers and gave them 75 cents a day, and I kept 25 cents. I've gone on to start much larger companies, divisions within companies, both within the US and outside, that have led to both success and failure. Venture backed, partnerships, bootstrapped, high growth, retail, commercial real estate, technology, energy, B2B, B2C, B20 - nobody is there to buy) and more. I’ve learned my greatest life and business lessons from my failures. I recently completed a book for Wiley & Sons, entitled The 7 Non Negotiables of Winning: Tying Soft Traits to Hard Results, which you can read about here: http://www.7nns.com. My current company, Fishbowl, is a culmination of everything I’ve learned over my 30-plus business years.

The Hidden Debt That Could Be Draining Your Company

When you consider the financial strength of your company, there’s more to think about than your Profit & Loss report and the Balance Statement. You should also consider the two debts entrepreneurs are most prone to ignore: The first is technology debt. The second is the hidden cost of high maintenance people.

Manage these two costs properly and your company’s growth and profitability will soar. In my next column, I’ll address the costs of high maintenance people. Today, I’d like to provide a quick lesson on the ways to find and eliminate the insidious costs of “Tech Debt”.

Technology Debt is a term that emerged in Agile Methodology for programming (in our own company we apply it the principles of Agile to operation and leadership functions as well.) According to agile expert Pamela Szabo, “tech debt” occurs when companies do the following:

Engage in poor programming practices, followed by patches

Fail to maintain technical assets

Isolate their technology or product from compatibility with the rest of the world

Fail to keep up with universal product and technology trends.

Companies create tech debt when they write “corner cutting” code to rush a product to market too quickly, or they send their product over the wall to the testing department with expectations that testing will eliminate their risks and get the product to an acceptable level to ship.

The tech debt issues can apply to non-technology products as well. For example, a marketing company may make an “agile-like” decision to rush their product to market at 80% completion knowing it will fail for 20% of their customers, and will bank on apologies and fixes saving the day.

The company may make high revenue by hitting an aggressive deadline. But the additional revenue comes with a cost of unhappy clients, high returns, and escalating customer support costs. They’ve produced a product that carries a technical debt.

We experienced this phenomenon in the early days of Fishbowl. We coded like most traditional development shops. We banged out a ton of code and popped it over the cube to our testers. In the process, we created a tsunami of bugs – so big, in fact, that our tracking system actually broke.

A handful of our testers and programmers proposed a better way. They believed we could replace the “develop, then test” paradigm with a single higher quality development process. We closed the testing department entirely. Several individuals took the courageous step of eliminating their own jobs in the process (however, these testers have all become great programmers now).

The team moved its focus to creating as little technical debt as possible. Our Development team focused on the challenge of ensuring they introduced no new bugs when they created new features. Company wide, we adopted a “test first” attitude to help us write code that could not be broken again.

We agreed to refrain from adding new features if they might risk breaking something that already worked. In 24 months our products emerged with new life, yet our testing department was entirely gone. One of our programmers helped to eliminate our “national debt” by personally removing an estimated list of as many as 300,000 bugs.

Finally, in keeping with our commitment to transparency, Development began the process of posting its technical debt ratio continuously for all our company to see, along with our financial results. Yes, we now release new products more slowly. But the technical debt has been paid.

How do you find and eliminate your own technical debt? Experts in agile methodology offer multiple templates. But in short, you should consider the following steps:

Identify the areas of debt. Call a team meeting. Brainstorm the results. Your employees will know where your inefficiencies lie. Take their feedback to heart.

Think in terms of “products” instead of “projects”. This will allow you to address the challenge holistically. At Fishbowl, we think of our product as a living entity (we give the product its own chair at every development meeting, in fact) to help us keep the bigger vision and mission at the top of our minds.

Use metrics to measure the costs. There are multiple tools available to help find and assess the costs of problems in the various aspects of code. The metrics will also be helpful as you assess the priority level of the issues you choose to address.

Prioritize as a team. With the metrics in hand, where can you gain the most reward the most quickly in eliminating your technical (or overhead) debt? The team can identify the prioritization and one by one, you can pay down the debt by addressing these areas.

Identify human bottlenecks. Are there critical tasks in your development or leadership process that rely on one key person to proceed? This is a case for the agile principle of paired leadership. A process that is collectively owned is more resilient to risk and is better able to represent the team and company ethos as opposed to the preferences and idiosyncrasies of a single member of the product development team.

Appoint a leader a (or even better, a leadership team). In our case, the developer who identified the technology debt and in the process actually eliminated his own job (in testing) now co-leads our entire development process. His name is Kevin Batchelor. His co-leader, Heber Billings, is the heroic programmer who played the leading role in eliminating our mountain of bugs.

Document the evidence. Keep the evidence and report the results of your debt-decreasing efforts. This is the surest way to keep everyone in the organization bought in and involved.

How is your own company doing in the prevention and elimination of technical debt? Could you be doing better?

Starting January 28, Fishbowl (together with Intuit) is proud to lead out as a Competition Partner in Grow America’s 30 day Product Innovation Competition, available to entrepreneurs throughout the U.S at www.growam.com. Alan Hall writes indepth about the competition in his Forbes column here.

For additional information on agile development or the Fishbowl story I’ve written about it some more here.

Contributions for this article were provided by Mary Michelle Scott, Brett Campbell and Kevin Batchelor.

Post Your Comment

Post Your Reply

Forbes writers have the ability to call out member comments they find particularly interesting. Called-out comments are highlighted across the Forbes network. You'll be notified if your comment is called out.

That’s for sure Trent! Not just sales reps, but anyone in Fishbowl that has any interaction with customers can speak with belief and confidence when they talk about the Fishbowl products. This is not just a sale. It is giving SM businesses affordable tools that will really help them. It is business helping business.

Marilyn, very true – in any company, everyone is responsible for sales. And as you note, their success depends on their ability and their willingness to help other businesses succeed, whether it means a bigger sale, a smaller sale or just a bit of helpful advice. Thanks very much for your note. Regards, David

One of the things that wasn’t mentioned in the article but that is a byproduct of the Agile methods Fishbowl uses is an improved working environment.

When we were using a standard waterfall programming model the programmers always had increased stress and worked late hours. Now, using the Agile methodology we have a much more carefree environment to work in and we can usually get our work done within the normal 40-hour workweek.

The improved working environment directly contributes to fewer bugs and less technical debt being created each week.

Interesting article – I love stories like these – my great grandpa regularly told my grandpa who told my father who told me “if you can’t do it right the first time don’t do it at all.”

After some life experience, I’m beginning to appreciate the time costs of “maintenance” on anything. It’s easy to fill your day with maintaining things to the point of no longer being able to do anything new.