Skip to main content

There is a lot of talk about technical debt these days. (There is a lot of talk about debt in general as we are still attempting to recover from the macroeconomic recession of 2008.) The question I would ask though is – If it is possible to build technical debt then it should it not also be possible to build technical equity? But what exactly is technical equity?

Before I explain the concept of technical equity, let me provide a simple explanation of the concept of technical debt. Often technical debt is created when the business pressures developers to rush a software product to market. Programmers have to find shortcuts in order to meet the deadline. So they begin to hard-code things that should be driven by a business rule or a database lookup. They skip the supporting documentation that is necessary to keep the code maintainable over a long period of time. And they avoid refactoring parts of the code that have become unwieldy. These incomplete work efforts do not simply disappear. They accrue as debts on the balance sheet of an IT organization as deferred work that must be completed at some point in the future. For more details on technical debt I recommend the following links:

Wikipedia on Technical Debt

Scrum Alliance on Technical Debt

Now back to the original question – What is technical equity? One way to think about technical equity would be to assume it is the opposite of technical debt. Instead of deferring necessary programming work to a later time (creating debt) you might alternatively develop new functionality in advance of when the market needs it (building equity). But there are not many companies these days that are taking a “build it and they will come” approach. And I am not sure many would place value on this type of equity.

I think we should decouple the concept of technical equity from technical debt. Technical equity should mirror the issuance of stock to shareholders in the capital markets. In other words – What if you could get your largest customers and a community of third party developers to become shareholders in your technology platform? What if you could get them to make investments that convert them into true partners vested in your long term success?

Companies such as Amazon, Google, Facebook, Apple, Salesforce.com and Microsoft have such a model. They have thousands of business partners and customers who have built extensions to their Platform-as-a-Service offerings. They do this by allowing customers and third party developers to build extensions to your platform via APIs or Software Development Kits (SDKs). As a result, their partners and customers now have a vested interest in their long-term success. And they have become shareholders who have technical equity in the platform.

More thoughts in a future post.

Steve Keifer

Steve Keifer has led marketing and product management teams at seven different SaaS and cloud providers ranging from venture-backed, early-stage startups to multi-billion, publicly traded companies - including several that experienced hypergrowth, filed IPOs, and reached unicorn status. In Bantrr, Steve shares many of the best practices and lessons learned from building and scaling marketing organizations. Topics include new category creation, brand development, and demand generation.

One Comment

Leave a Reply