I’m Technology Partner in a VC firm, Oak HC/FT. I help look at companies we’re considering investing in, and I help out as needed after investment. Recently I’ve been thinking about what I do, mostly because I’ve encountered multiple cases of technology due diligence performed on companies I know well. To put it plainly, I don’t do it the same way.
The firms whose work I’ve seen are professional, well-regarded groups. Their work fits into a pattern of similar work I’ve seen over many years. Their work can have value.
My Evolution in Tech Due Diligence
When I started performing tech due diligence for the VC firm Oak Investment Partners in 1992, I had no specific idea of how to do it. My background had been almost exclusively on the “other side,” i.e., working and building software, mostly for small, entrepreneurial companies. But I’d had occasion to dive into bodies of software over the years and figure them out, so I guessed I’d be able to figure it out better than any non-programmer could. All I can say is, I went through quite an evolution from there.
The starting point was clear and simple: evaluate the software. There’s a lot of work involved and not many people have the skills to do it well, but there’s no magic. I quickly developed an outline for what an evaluation consists of. It was a few pages long. Here’s the last part:
The earlier parts … well, let’s just say it was comprehensive.
I marched forward doing the work and interacting with the people in the company being evaluated and with the partners in the VC firm. I evolved my views of tech due diligence.
In the late 1990’s, I did an on-site tech diligence of a little company called Inktomi. It was started by a couple guys from U Cal Berkeley, one a young professor and the other a grad student. They were hard at work on a project called NOW – the network of workstations, which was an early attempt to build software that would enable a bunch of workstations connected by fast networking to solve really big computing problems, of the kind normally only so-called super-computers could handle. They built the software, and needed a big, big problem to solve to demonstrate that it worked. There were already full-text databases around that ran on standard computers. Also at the time, the internet was exploding, with no end in sight. There was an emerging need to help people find things on the internet. At the time, the best available solutions were “portals,” of which Yahoo was a leading example. A portal was a densely populated page managed by people who would put up links to the main things people were interested in. But what if you wanted more? Wouldn’t it be great to have a full-text search engine that could index and search the entire internet, even as it grew endlessly?
This is the problem Inktomi took on. No existing search engine could come within a factor of 100 of indexing and searching the whole internet at the time. The boys at Inktomi used their NOW infrastructure to attack the problem, first building a crawling and index-building system, then building the search. It wasn’t easy, but it turns out that it fit right into the NOW approach. If you understood it, you could see that by adding workstations to the NOW, you could scale the index endlessly, no matter how large the internet grew.
I walked into the second-floor warren of offices above stores on Shattuck Ave. in Berkeley, with machines and people crammed in anywhere they would fit. I already had heard the basic idea. I looked over people’s shoulders at screens, and noticed some things about the C code there. I asked questions and discovered they had implemented parallelism not by using standard UNIX multi-tasking, but by a super-low-overhead coding method. I saw the cables and boards, and found out the clever things they had done to minimize inter-workstation latency. And some more stuff.
Before long, and without doing anything like the exhaustive inventory of my original approach to due diligence, I had discovered the originality of their approach and their impressive implementation of it, which would give them a lead over any competitors that would emerge. I became a strong advocate of the deal.They took our money, the largest investment we had made in a company to that date, and ended up making over 100X return.
Of course today, we don’t “inktomi” for things on the internet, we “google.” That’s a story for another time, and happened after Inktomi had attained a public market valuation in excess of $10 Billion.
I tell the story to illustrate one of the fulcrum points of my evolution in performing tech due diligence. The way I did it and the resulting win helped spur me on to doing what the VC really needs, which is to leverage my experience and skills into getting insights into a potential deal that are invisible to the other members of the firm because of their lack of detailed knowledge of software and systems. The insights can range from “makes no difference here” to “OMG negative” to “how could I have known that super-positive.”
What I finally evolved to, and continue to work at, revolves around this simple fact: the VC firm wants to know if this technology, the way it is today and is likely to grow into the future, will make the company into a success and end up making money for us and our investors. That’s it! Everything else is a footnote or appendix.
The vast majority of tech due diligence I see performed by firms who specialize in performing that work, and who are regularly retained by groups doing investments and/or acquisitions, is not about this. What I almost universally see is something like what I started with long ago, with this very important added element: how do the tech, the people, the organization, the process, the deployment and the architectural choices made by the firm compare to widely held industry standards, best practices and regulations? When I look back at my old outline, I see this element entirely missing! Thinking back, I realize that the reason is that I had already decided that those widely held standards, unlike the ones in law and accounting, were a pile of crap. I had already noticed what I later began to systematically study and write about, the difference between the "war time" software practices of winning startups, compared to the widely accepted "peace time" methods.
Conclusion
If you want to acquire a tech-oriented company, you naturally want to perform due diligence. If you’re a big company, you may want to acquire it for its momentum and market edge; Facebook and Google do lots of acquiring for this reason, among others. You want to know how well the target company conforms to the kinds of standards, practices and procedures that your internal organization is held to. But if you’re a smart VC, you want different things from tech diligence. Does the tech give the company an “unfair advantage?” Do they approach tech with a speed-oriented, get-stuff-done attitude? The tech may be 2X better than the incumbents, but could a newcomer pretty easily get 5X? Sounds improbable, but this kind of thing happens all the time. If you’re a VC about to place a bet on an up-and-coming company, that’s the kind of tech input you should want.
