Variable streams for fixed costs

Thoughts on Business, part 1

A couple years, Jonathan Schwartz, late CEO of Sun Microsystems, told a story about facing Steve (Jobs) and Bill (Gates). The substance of his post was around the usual IP patent staredowns that happen between powerful men who run large software empires. He threatens, you counter, etc, etc. The post itself made the usual rounds on the blogs, news sites and their ilk. While most of these articles focused on the obvious subject at hand, my wandering eye gravitated towards something interesting that Mr. Schwartz quoted from Bill:

…the software business was all about building variable revenue streams from a fixed engineering cost base…

It occurs to me that this is valuable insight for anyone looking to build a software business, web, client, or otherwise. Most regular businesses involve either manufacturing, physical locality (e.g. warehouse, storefront, etc), or both. This implies a significant cost during the creation and distribution of the product. For example, suppose you’re a toaster company and you design toasters in the USA, manufacture them in China, and sell them in Europe. Much of your cost structure is tied up in the latter two steps; in fact, they’ll likely form the majority of your overall cost. In order to drive down the cost of your business, you could:

• Move your factories to a place where land and labor is cheaper (see: China), if manufacturing is the most expensive part of your cost
• Move your factories closer to your retail channels, if shipping/distribution is your major cost
• Figure out ways to cut down on distribution cost (e.g. hedging on fuel prices, figuring out how to package more efficiently so your trucks can carry more items at a time, etc)

Now consider a software business. In this case, there is literally no manufacturing cost. There is distribution cost, either for downloading web pages or a software install package. However, there are well-known ways of reducing this cost (e.g. CDNs, bittorrent, etc). Hence, it is likely the largest fixed cost is going to be labor, i.e. the engineers that create your product to begin with. In most cases, the key to improving cost efficacy in a software business lies in the control of labor costs, i.e. how do I get the most bang out of each buck I pay my engineers?

There’s the obvious solution of hiring cheaper contractors (feasible for single-to-few release products like games) or outsourcing to countries like India or China, with their attendant disadvantages. However, there’s another possibility implied by Bill’s comment: code reuse for different products. Computer scientists are trained from the start to be abstractors, i.e. they are taught to create systems that provide the right level of utility to encourage reuse, and to avoid copying-and-pasting identical code as far as possible. This is useful within a particular system or product, but can easily be useful even across multiple products. A couple examples:

• Significant engineering resources are spent building a large e-commerce portal; in particular, complex systems have been built for managing machine resources efficiently across multiple software services. Rather than continuing to simply invest in this one portal, the company starts a separate cloud computing business around its resource management systems.
• A company builds a hugely successful business around an operating system for PCs. It looks to diversify into other businesses like game consoles or point-of-sale systems. In all cases, the company starts by reusing large parts of its existing operating system codebase for the new product.

In both these cases, the companies were able to leverage well-written code created by costly engineering talent into a different revenue stream. This, in my opinion, goes to the heart of Bill’s comment, and is critical to the growth and continued success of any software company. At the end of the day, unless you’re OK just surviving on a single product or revenue stream, you had better figure out how to leverage all the code that your expensive engineers wrote.