A Tale of Two Startups

My life of work was not that storied, but I'm going to tell you about it anyway. 

After a stint at teaching, I worked in software development for over thirty years. Fifteen for corporate behemoths Control Data & Honeywell, a story for another day, and another 20+ with 2 software startup companies, one an intense 2 year ride into oblivion, the other a roller coaster ride to success.  

It is almost a certainty that startups will pull people into unhealthy lifestyles, akin to bipolar disorder. High highs, low lows, elation with successes, agony with failures. My sample size is just 2 instances but they cover both ends of the spectrum. Both had a common pattern - 60 hour weeks with frequent voluntary overtime; jelly donuts on demand, fast food dripping on a keyboard and lots of coffee; waking in the middle of the night to update the to-do list. I was that stereotype - a bit crazed - the bug-eyed, drooling middle-linebacker look. Too much stress, too little sleep, too much caffeine. It makes me cringe looking back. But I did it - twice.  

Of course, this cannot go on indefinitely. You would wind up prematurely dead. So if the startup is lucky enough to release a product, things tend to normalize. However, in the software business, there is never really a "normal".  There's always the Sword of the Next Release dangling by a thread over your head.

And the facts are - it is rare for a startup to feel the joy of victory. "In 2019, the failure rate of startups was around 90%. Research concludes 21.5% of startups fail in the first year, 30% in the second, 50% in the fifth and 70% in their tenth."  Let's see - 171.5% fails. Grim odds. 

Why did one fail and the other succeed?

Top notch people are the key to a successful new venture. But good people are not enough. Both of my experiences had terrific people, highly skilled software professionals, great people with great character, but one crashed and the other soared.

Case Study #1

Early 90’s. 

Every startup needs a strong vision. Something inspiring AND able to attract investment. Most startup failures simply run out of cash.

Startup #1 had a fantastic vision, albeit unachievably idealistic.

Mission: Develop an electronic medical record system with a backend data warehouse that can serve as a big data repository for research and an expert diagnosis and outcomes engine. 

Wow. It sucked me in. And it recruited people I knew and knew were good and easy to work with - all 4 of us. See what I mean about "idealistic". 

Unfortunately, this case study is a tutorial on what not to do.

Problem #1. Backing. The funding of this development depended largely on the pockets of the founder and a few individual investors. This budget limited the ability to increase staffing levels. Fairly early on an opportunity to move the work under the auspices of a large medical organization was rejected by the owner who did not want to relinquish control. That path might have given us a chance. However, that decision led to the resignation of a key member of the development team and the writing was on the wall.

Problem #2. Technology.  

Both examples took huge technology gambles. One was ill-fated, the other grandly successful. 

In case #1, we chose object oriented development (this was a relatively new thing back then) built with the O-O language, Smalltalk. Smalltalk seems like a strange choice in hindsight, but at the time Smalltalk was the hottest language in the development tool bag. (In my mind it is still the most flexible programming language I have ever worked with - and I have coded in 10 different languages.) It’s a wonderful language for rapid development and support for O-O concepts. Unfortunately, it failed to scale, had poor UI support and the database interfacing capabilities were not great. We toyed with the idea of using an Object Oriented Database, (OODB), another hot topic at the time, but that was a risk too far. So, we were forced to develop internally an object-relational interface layer, both time consuming and a performance bottleneck. And sadly, Smalltalk, the language, did not evolve quickly to address its deficiencies. All in all, our technology choices were, to put it kindly, unfortunate. 

"In the 1990's, all the Smalltalk vendors failed to recognize the significance of the nascent Web and did not adapt their products accordingly. Java came along and mopped up the market." 

Problem #3. Scope. From a product perspective, a major mistake was to try to swallow too much of the elephant. Rather than getting a prototype out quickly with known gaps but with capabilities that demonstrated value, we tried to address a big wish list with a small staff. We ran out of funding and folded up camp.

Problem #4. Customer Engagement. A significant headwind. The main source of requirements and review were individual physicians and staff with medical background - and one large medical organization with “slight” interest. We developers had sparse domain knowledge. At the time, while medical devices were leading edge technology, medical records wallowed in out-dated practices and a we faced organizational reluctance to any change in the status quo. 

Problem #5. Timing. Our development pre-dated the emergence of the internet. At the time, the internet consisted of ARPA newsgroups. I believe if we had launched 3 years later, and focused on a web-based application, our odds of success would have improved multi-fold, at least getting us to a point of being absorbed by an entity with more resources. (see "backing" above). Furthermore, Graphical UIs (GUIs) were in their infancy.  

I now look at Epic Systems with its MyChart and its now10,000 employees and sort of ache inside.

So, that's 2 years of my life in a cement mixer.

After a the crash and burn of startup #1, I spent two fairly calm and stable years working for Honeywell Technology Center, strangely enough utilizing my Smalltalk skills. And out of the blue came a phone call.  I had maintained connections with my former Control Data compadres, and one of them came to me with an opportunity to get in on the ground floor of a startup!

So why leave a solid position with interesting projects (I was a "Principal Research Scientist", la ti da) for another cement mixer? Well, I guess I got the bug again. Time and memory softens the bad experiences and elevates the good, so off I went. The itch to build a something from scratch was irresistible. It’s a rare thing.

Case Study #2

Movin' on up

Late 90's.

Startup #2 had what seemed on the face of it to be rather mundane, if not boring mission. A toolkit!

Mission: Develop an application development platform and toolkit for rapidly building enterprise web-based applications in multiple domains on a UI via the ubiquitous internet browser.  

Surprise. It turns out that this kind of development accelerator has a powerful appeal to internal development projects in large corporations.

Advantage #1. Backing.  This effort had, from the get go, the backing of a major software company with a 50% interest and augmented by some venture (vulture?) capitalist funding. This allowed a fairly rapid staff expansion. The 1st company directory listed 12 employees fit on a credit card size laminated card. Enough people to get a working prototype for customer review within a year.

Advantage #2. Timing. This startup launched just as the .com era was burgeoning in the late 90’s. Our development hit the dot.com window on the nose and generated enthusiasm and funding for the effort. Of course, the 2000 dot.com bubble burst nearly did us in. Four years in and we almost became a statistic. The development environment chosen was Java, this before the first release Java 1.0, essentially a beta version of the language. So this was a gamble. Strong server-side capabilities, interfaces to backend relational DBs coupled with applets that browsers soon supported yielded a modern looking user interface. Java exceeded expectations. In contrast to Smalltalk, updated Java versions released rapidly and targeted to “internet” development. 

Advantage #3. Customer Engagement.  The founder was/is a visionary and marketing genius and leveraged his many contacts from his previous life. So from the very beginning there was strong customer interest in this internet-based application generator concept. Major household name corporations from a variety of  industry sectors sent technical representatives to quarterly multi-day BOCA (Board of Customer Advisors) meetings. At the time, however, they were just interested. There was no commitment to buy.  Each quarter we demonstrated development progress, gathered feedback on that and input on next round priorities. It was a curious dynamic. These regular gatherings created personal relationships and actual friendships between developers and their technical counterparts in these companies who then became advocates for us with their decision makers back home. These trust relationships helped to drive acceptance of our initial product release.

Advantage #4. Adaptability. The product vision was a toolkit for rapidly building web-based enterprise applications. Two years in, our our corporate benefactor was acquired and de facto us as well. The mandate then changed. Use this toolkit yourself to build a specific product to add to the company's product line. And that’s what we did, validating the concept of rapid application development and delivering a product that became and remains the leader in its field. This sadly meant abandoning a number of toolkit prospects outside the new target domain, although a number of them became early adopters of our product.

Advantage #5. Need. This initiative was important to the profitability of the acquiring company. So the development group was important. We were a part of a rare company where revenue comes exclusively from selling software. So, as a software developer, what you did directly affected the success of the company, something not many software people can say.

So, I guess it’s pretty clear which startup succeeded and which failed. Startup #1 failed, a victim of the common causes hitting 90% of all startups. Defying the odds, Startup #2 became extremely successful, delivering a world class product that is still thriving 20 years later.

I am several years retired from that exhilarating ride. An idea coming to life. Like a musical composition produced by many people rallying together to add notes to the song [Sorry. Couldn’t resist a little schmalz]. What makes this happen? Serendipity? Blind luck? Stars aligning? A good deal of hard effort and dedication for sure. And the trust in each other to enable it to happen.

I stayed on perhaps beyond my time because of great people with great character and a special kind of camaraderie, cooperation and professionalism that is rare in the business world. You probably do not realize how unusual this is or even comprehend its possibility. That group of people was the most close-knit group I have ever worked with - perhaps driven by ‘courage under fire’. To this day, I have a real affection for many of those people - and to a lesser degree the product. It’s gotten a bit too large to be lovable.

Team building :-)

Team-agers

Copyright ©  2022  Dave Hoplin