The Narrow Road Between Success and Failure

Before I started Likewise Software, I was in the venture capital business. Although my role was more on the “back end”, performing due diligence once we’d decided to invest in a company, I heard many, many pitches from aspiring entrepreneurs. For the great majority of these pitches (probably 95% of them or so), I recommended against investing in them.

It wasn’t that 95% of the proposed ideas were bad but, in most cases, either the idea or the team was weak. Venture capital folk like to say that they don’t “bet on the horse” they “bet on the jockey.” Occasionally, I’d hear weak ideas from good teams. In these cases, I’d try to guide them towards better alternatives. Most often, though, I’d hear reasonably good ideas from weak teams. It’s much harder trying to fix a weak team than a weak idea. Once in a while, a VC will try to do this. For example, they’ll propose funding on condition that a strong CEO be hired. This doesn’t always work. One of the founders might already fashion him/herself as CEO. Even worse, a founder might agree to take on a different role but then obstruct the new CEO once hired.

VCs like to bet on people because it’s been proven to be the most successful strategy. A good team can sell a weak product much better than a weak team can sell a good product. In practice, too, the good team will fixthe weak product while the weak team will find some way to ruin the good one. Think Betamax.

I’ve been a part of a couple of very strong teams during my career in the software business. From 1988 to 1994, I worked in the Developer Tools group at Microsoft. More recently, from 2004 I’ve been at Likewise (nee Centeris). In both cases we dealt with uncertainty and strong competitors and, through persistence and execution, succeeded. Weaker teams would not have fared as well.

In the early 90’s, the Microsoft “compiler group” was in trouble. Borland was kicking our collective behinds. We’d released Microsoft C version 6 to very negative reactions (we were one of the first products to eliminate print documentation in favor of electronic documents). We were mired in obligations to our operating system group and to IBM (for OS/2 support). Meanwhile, Borland had Turbo C and Turbo Pascal both of which were doing very well. Gates would frequently criticize our lack of killer product ideas. Nathan Myhrvold (effectively, the Microsoft CTO, at the time) wanted us to emphasize high-quality printed code listings. We’d gone from 60% market share to 40% (Watcom C was in there, too). Meanwhile, C7, our first C++ compiler, was mired in schedule delays and lack of focus. It was very easy to despair.

At yet, we didn’t. We gave up the IBM business (Borland took it and, I’m sure, regretted it). We basically told Gates and Myhrvold to stuff it. We released Quick C for Windows and Visual C++ 1.0 for NT — products that were received reasonably well. When we released Visual C++ 2.0 (the precursor of Visual Studio), we completely turned the tide. We got back more than our previous market share and never lost it. Within a year, Borland was firing/losing people and we were hiring/finding them.

Looking back, the interesting thing to me is that, at the time, we weren’t aware of any killer idea that we were counting on to succeed. In retrospect, it was “MFC” the Microsoft Foundation Classes and its coupling to our forms editor that turned out to be the killer idea (an idea on which .NET has built a billion dollar business). At the time, however, we were just doing our jobs and executing very well.

Back in the early 90’s, the Tools group was a very mature group for Microsoft. A lot of people wanted to work on operating systems or on cool applications. The only people who worked in the Tools group were nerdy folk who were into code optimization or writing debuggers and class libraries. Once in the Tools group, these people never left. We had old timers who’d been there for a decade. What this meant is that everyone knew their jobs extremely well.

Visual C++ 2.0 shipped on-time, with its full feature set, and with extremely good quality. To this day, I still consider it the most successful project I’ve ever worked on. In the course of 18 months, the Tools group had gone from being failures to being brilliant.

The road to success is rarely clear. To abuse the metaphor, if it’s an eight lane superhighway, it’s going to be jam-packed with competitors. More likely, the road to success is a poorly marked path through dangerous woods. Likely, you will have to bushwack. There’s no guarantee you won’t end up at a dead end or at a cliff. Your best best is to count on a good team, to be persistent and to not despair. Fate tends to favor the strong.