Circle of Incompetence

For many years, Bruce Greenwald has taught value investing courses at Columbia, where Ben Graham himself once taught. In the newest edition of his book “Value Investing: From Graham to Buffett and Beyond” and in recent appearances, he has emphasized the importance of specialization to generating market-beating returns.

In the book, he notes that the idea of specialization dates back to Graham:

“A well-established principle of Graham and Dodd investing is to remain within one’s “circle of competence”…. A circle of competence delineates one’s area of specialization.” (in Value Investing: From Graham to Buffett and Beyond)

But specialization has become more important in today’s world, he says, where outperformance has required properly valuing growth companies:

“When you have to do difficult things like judge the value of growth, which is fairly far out into the future, you’d better be really well informed. And to be really well informed… you have to be an expert.” (on the Multigreen Podcast)

He has noted that Warren Buffett only outperformed the market through his investments in four industries — banking, insurance, consumer non-durables, and media — with his investments outside those industries only matching the market (or worse). If Buffett can only master four industries, then those of us without Buffett’s lifetime of experience studying businesses probably can’t hope to master more than one or two. Indeed, Greenwald suggests we focus on depth of knowledge in one area rather than breadth:

“The more specialized specialized you are, the better you are going to do.” (Ibid)

Let me present my investing experience, however, as a cautionary tale toward the idea of specialization.

I have been a computer programmer for 30 years now. I worked at software companies for about half of that time. I have a Ph.D. in computer science, and I teach computer science at a university. If there is one area that I have expertise in, it is software.

Following Greenwald’s advice, then, you would expect me to have an edge in investing in software companies. I have detailed knowledge of the strengths and weaknesses of the products that these companies make and even of how difficult it will be for competitors to duplicate their work.

However, my track record of investing in software companies is absolutely terrible. If you don’t believe me, let me tell you some of the companies that I have passed on and the industry knowledge that led me to do so….

Amazon Web Services (AWS)

It may be news to some that Amazon was not the first company to offer what they called “web services”. The first such companies appeared in the late 90s. In fact, Amazon, in the mid-late 2000s, was one of the last to enter this space. (This area was renamed “cloud” in the 2010s, so newer entrants like Google and Microsoft offer “cloud services”, while Amazon uses the anachronistic term “web services” from that earlier era.)

The reason that I am familiar with the earliest web services companies is that I actually worked at one during the tail end of the dot-com bubble. We built all of the same technology in 2000 and… it was a complete failure. Here’s what we learned: no respectable business is interested in moving its private data off premises, onto servers run by other people. I actually laughed when I heard that Amazon was going to give this business a try.

Apple’s iPhone

The iPhone was not the world’s first smart phone. Once again, I have fairly direct knowledge of the earlier efforts in this space. A close friend / relative of mine worked on Microsoft’s smart phones, dubbed “Pocket PCs”. Like many of Steve Ballmer’s projects, this was a total failure. Consumers simply weren’t interested in a phone that also let you edit documents and play Pac-Man.

The iPhone was certainly a better product, but there was nothing in its software that was fundamentally different. It had faster hardware and a higher resolution screen (as you’d expect 5+ years later), but the software was largely the same thing Microsoft had built before. I saw no reason why consumers who were indifferent the first time would change their minds now.

Microsoft

Microsoft is probably the company that I know better than any other. I got my first programming job there in the late 90s, and nearly all of my programmer friends worked there at some point. I live mere miles from their campus. Its culture is all around me and still in my veins.

Throughout the Ballmer era, I desperately wanted to invest in part of Microsoft: the enterprise software part. In that area, Microsoft had an obvious moat and a decade plus of growth ahead of them. Unfortunately, if you bought the stock, you had to buy the whole company, which included Ballmer at the head pouring their free cash flow into one failed product after another — Pocket PC, Zune, Bing — and poor acquisitions ideas (e.g., Yahoo).

When Satya Nadella became CEO, he said the right things: no more trying to run the 1990s playbook of copying other people’s successful products. Instead they would focus on areas where Microsoft was already winning, especially enterprise software. In order to do that, however, they would need to embrace open source software like Linux and open standards like JavaScript.

It’s hard to put into words what a culture change that would be for Microsoft. The idea of using Linux at the Microsoft I knew was impossible to imagine, likewise for the idea of embracing open standards instead of owning the API themselves. While Nadella was obviously correct, I thought the 100k+ employees and Microsoft’s culture would resist this, and that the company would continue to flail while its moats slowly disappeared.

MongoDB

Even today, I am still surprised that MongoDB and its competitors were able to make “No SQL” somehow sound like a feature instead of a defect. For those familiar with the idea of “low code” / “no code” software, note that NoSQL is the opposite bet: instead of giving people a no code interface (SQL), you instead ask them to write code. Technologically, this is moving backwards.

NoSQL databases also generally skip the hard part of writing a database, namely, implementing “joins”. If you remove SQL and joins, a distributed database is incredibly straightforward to write, so it should be easy for competitors to duplicate. There was no question that Microsoft, for example, could build something better. (Google’s internal distributed database systems were light years ahead of MongoDB at the time.)

The other advantage that these sorts of databases claim is support for “unstructured data”. However, data has to be structured to be processed, so really what they mean is that you can store data without structuring it. But that simply means you have to find structure when querying the data. That just moves work from one part of the code to another, and in general, the total amount of work for developers will be larger.

—

I have more examples. I was skeptical of Slack and Twilio because I built similar software myself and expected it would be easy for competitors to duplicate. I was skeptical of Splunk, Elastic, and DataDog for reasons similar to what I said about MongoDB. I was skeptical of Alteryx and Appian because I didn’t think their technology was “the right solution”. I could go on and on.

Conclusions

Ultimately, it doesn’t matter that I don’t think MongoDB is the best database solution if there are thousands of developers who do. Actual sales matter infinitely more than my opinion.

Looking back at these examples now, I can accept that it is hard to figure out which products will click with consumers, so perhaps I should be more upset at the fact I didn’t change my mind once the subsequent sales numbers made clear that customers were buying these products. But as I described above, in most of these cases, my software knowledge led me to believe that competitors would quickly emerge and take away most of the growth, which did not happen. I think the reality is that each of those products have unique consumer appeal that would have been more apparent in a customer survey than it was from the internals of the software, meaning that my knowledge of software was largely a distraction.

Greenblatt does give compelling examples for his thesis about specialization:

“If I’ve been doing on-shore, south Texas, gulf coast oil leases for 20 years, and that’s all I do, and you fly down from New York and buy a lease from me at my price, who do you think is on the right side of that transaction?”

However, his example seems like one where the profits are quite predictable (at least probabilistically). In contrast, with high growth software companies, no one can say with much confidence what the those are going to be. They are simply much harder to forecast.

We know from the study of expert judgement (see “Behavioral Problems of Adhering to a Decision Policy”, 1973) that more knowledge, beyond some point, does not increase forecasting accuracy — it just increases (over)confidence — and I think that fits my experience here. My software background made me unreasonable confident that these products would not succeed and that, if they did, they would lose out to competition. An investor without that knowledge would have been open to the possibility that their growth could continue for years to come, which is what in fact happened.

In short, for high growth software companies, having little software knowledge may be advantageous for investing if it keeps firmly in your head the idea that the outcome, especially the potential upside, is unpredictable.