Brad's Books and Organizations

Books

Books

Organizations

Organizations

Hi, I’m Brad Feld, a managing director at the Foundry Group who lives in Boulder, Colorado. I invest in software and Internet companies around the US, run marathons and read a lot.

« swipe left for tags/categories

swipe right to go back »

Martingale Software – My First Company

Comments (16)

A few days ago I wrote that there wasn’t enough talk about failure.  I had an awesome run tonight in the mountains behind my house and pondered – among other things – some of my early failures.  As my mind wandered and I tried to keep from stumbling on the rocks, my thoughts drifted to my first software company – Martingale Software.

I co-founded Martingale Software in 1984 with three fraternity brothers.  Three of us were second term freshman (me, Andy Mina, and Sameer Gandhi) and one was a senior (Dave Jilk).  After Martingale failed, Dave joined Viewlogic Systems as their first non-founder employee and – after having success there – went on to start Feld Technologies with me (which succeeded.)  After college, Sameer had a strong run at Oracle in the late 1980’s, then spent some time at Broadview, before joining Sequoia Capital, where he’s been since 1998.  I’ve lost track of Andy.

Martingale’s mission was to write software for the Apple Macintosh computer.  We were all in love (at least I was) with the first Mac and thought there’d be a huge market for software for it.  Of course, we had no idea what kind of software we were going to write, how to market and sell it, or when we were actually going to find the time since we were all going to MIT full time.  We ignored those challenges and just barreled ahead.  We were all excited about the idea of simply starting a company.

As with most good stories, this will be a multi-part post so you can digest it in quick chunks.  I’ll try to have at least one lesson in each post, although you might have to work a little to find it.  In this case, the first lesson is that our excitement about starting a company dominated – not surprising for a bunch of undergrads, including three freshman.  We were wrapped up in the notion of “starting a company”, not in the idea of what we were actually going to do.

  • sigma

    Curious name, “Martingale Software”!

    The J. Doob decomposition says that every real valued
    stochastic process is the sum of a martingale part and a
    predictable part.

    The J. Doob martingale convergence theorem says that every
    martingale is either ‘$L^1$ bounded’ in which case it
    converges to some point or is not in which case it has to run
    off to infinity.

    You had J. Doob in mind when you started your company?

  • Dave Jilk

    Martingale is also a betting technique such that, every time you lose, you double your bet until you win.

    I recollect that a lot of the initial excitement was about playing with Macintoshes, not just about starting a company.

  • http://www.feld.com Brad Feld

    We were MIT nerds so we had this kind of thing in mind when we were coming up with a name. However, we were much more focused on the definition of Martingale as a betting strategy – basically, doubling down after every loss. Like the logical extension of this strategy, we didn’t have infinite capital, so we eventually had to fold completely.

  • http://www.performancevelocity.com Deb Miller

    While I was running this morning, I was pondering your previous post on failure, a recent failure of mine, and a comment by Lucy Sanders. I think Lucy said that only 5% of software startups are founded by women. I started and folded a software company between 2002 and 2004. There were lots of reasons for the failure, including the economy, but most of the reasons were personal to me and my approach. I wonder how many of those mistakes would be common with other women. I hope not many – with even a typical startup success rate, a 5% start rate isn’t going to leave many woman-founded companies. Without a discussion such as this, though, we’ll never know what might be common and learn from other people’s mistakes. It would be interesting, and potentially useful, to have a similar discussion with women. Any other women out there who’ve had a similar experience and want to talk?

  • http://entrepreneurevolution.com Adam C. Dudley

    I couldn’t agree with you more Brad…there isn’t enough talk about failure.

    So, when I recently gave a presentation on entrepreneurship to a group of MBA students here in Central Florida at Rollins College, I made a point of devoting at least 60% of my presentation to discussing my failed attempts, rather than highlighting and sugar coating my successes – as most speakers do

    Also, I’m reading a book right now featuring different stories by various entrepreneurs on their failures called Do As I Say, Not As I Did!: Gaining Wisdom In Business Through The Mistakes Of Highly Successful People by Carol Frank.

    It�s a very powerful book and features many �star� entrepreneurs revealing their shortcomings.

    You can learn a heck of a lot more from other entrepreneur�s failures than their successes.

  • sigma

    Yes, winnings in fair gambling ARE a martingale stochastic
    process. The optional sampling theorem shows that tricky
    betting systems cannot work. Yes, the gambling system was the
    origin of the name of the stochastic process.

  • Robert Zeek

    What is Failure?

    I was the 8th member of a Princeton based DBMS company. This is not the one that became CA. Our doors closed in 1992 after being founded in 1975 in the bowels of a defense research contractor.

    We were the first DBMS to run on a mini-computer (which hads way less than a MIP at the time). We were the first to have “text” indices as a feature of the DBMS. We were the first with cross record B-tree indices except that our indices were T-Tree, based on a footnote in Knuth, where each index page split into threes not two’s. Do the math. We could index over a billion entries on less than one Mip machines, with expensive 32 or 54k core memories and washing machine size 260MB disk drives. We were the first to have an fully integrated (as distinct from a standalone attachment) report writer and full screen data input forms, a transaction processor protocol (on the mini) and have all of these features integrated fully into a data dictionary that used our own products DBMS as its base. In 1980, Stonebreaker of U Berkley and INGRES fame declared our product’s output tools “state of the art”.

    Why do I crow so? Because, except for a short year in a half from 1980 to 1982, when we were the first and only product on the brand new DEC VAX and expanded to over 200 customers including some big banks, many government agencies and defense contractors, we were basically a blip on the DBMS screen.

    We simply responded to our customers and researched the answers and always thought “easy”, “integrated” and “consistent”. But, in 1984, when Oracle was still struggling to create a non-integrated data input and report generator that had no “data discitonary” feature, we were already essentially a dead company, captive to ITT and a few other company who needed our most advanced features, and living on our laurels. I had long since departed to the Pharmaceutical industry and it was not until Google and the Web tools that anything like what we had was available to all.

    Bottom Line: We make too much of cutting edge technology. I used to exchange stock tips with my Family Physician. I would exchange Info Tech plays for his Biotech plays. We both found after about 9 months, that if we bought Info Tech stock when he heard of them and Biotech stocks when I heard of them, we both made allot more money than buying in line with our expertise.

    Cutting edge technology and responding to customers only goes so far! A bit of caution, judgement, financing, timing and luck is also required.

  • sigma

    Robert,

    Sad story.

    You had a fantastic opportunity, bigger than the opportunity
    that got L. Ellison a 450 foot yacht.

    From 90,000 feet, the “failure” was when the company failed to
    take the opportunity. Somehow the company extracted defeat
    from the jaws of victory.

    For just those years, it was plenty clear — from the years of
    struggle with the beginnings of ‘data base’, from the
    struggles with both ‘hierarchical’ and ‘network’ data base
    systems, from the IBM R* and DB2 (Blasgen, etc.) work, the
    Berkeley (Wong, Stonebreaker, etc.) work, etc. — that RDBMS,
    with good tools, was one of the most important steps forward
    for business ‘information technology’. It wasn’t a secret.
    E.g., there are plenty of details in

    Jeffrey D. Ullman, ‘Principles of Database Systems,
    Second Edition’, ISBN 0-914894-36-6, Computer Science
    Press, Rockville, MD, 1982.

    Notice the publication date.

    For the details of just why your company failed, you have the
    background. What was it? Some people at the top of the
    company were already rich enough and didn’t want more? The
    COB didn’t have a wife who was thrilled that the kids were old
    enough to park in school and eager to rush off 12 time zones
    away to the tropics and give away billions to help the women
    not have babies? Too many people were just satisfied that the
    software worked and was so far ahead of what was in the market
    for ‘super-mini’ computers and didn’t insist on also building
    a valuable company? People didn’t see the brilliant future of
    RDBMS, especially on computers other than ‘mainframes’ and
    driven by Moore’s law? People in the company didn’t want to
    get rich? The sales people told the customers, “Our software
    is enormously powerful and valuable and way ahead in the
    super-mini world. If you can’t see that and benefit from it,
    then the loss is yours. If you want to be a customer, then
    give us a call, but don’t call on a Wednesday because that
    would ruin two weekends.”

    Had ITT as a good account? TERRIFIC! But in 1980 or so,
    tough to find a company in the Fortune 1000 that didn’t have
    numerous applications for your software. Basically a team of
    people with good skills with your software should have been
    able to call a company, give credentials, request an
    opportunity to give a presentation, ask for a sample
    application, study the application for a week, write the
    applications software for two weeks using your RDBMS and
    related tools, deliver the application, collect a check, offer
    to run a training program for their in-house software staff,
    collect more checks, make a RDBMS sale, grow the account, and
    do well.

    E.g., in about 1986, with VAX, DEC was getting more revenue,
    month by month, from DuPont than IBM was with their
    mainframes. IBM dominated the mainframe business at DuPont;
    still, DEC was getting more revenue. Some of the reason was
    that people in the DuPont laboratories that had been doing
    scientific computing on VAXes were growing those applications
    to production ‘business’ applications. One of the serious
    bottlenecks in this growth was lack of good software tools for
    business applications. You had one of the best of the missing
    tools. Last time I looked at a map, Princeton and DuPont are
    not so far apart. In fact, when we visited DuPont, we drove
    right by Princeton.

    E.g., in the late 1970s, FedEx needed a transaction processing
    application for the items in inventory at the FedEx Memphis
    hub ‘PartsBank’. Your RDBMS software tools were a really good
    fast start toward a good application.

    By 1981, Prime computer had really a somewhat nicer system for
    business applications than the DEC VAX, but Prime very much
    needed some good RDBMS software; they, and their customers,
    needed JUST what you had. Similarly for DG.

    Those were days when Cullinet, etc. were doing well: Your
    RDBMS with its good tools should have done MUCH better.

    Just then, Moore’s law was racing ahead. The Motorola 68000,
    e.g., in Apollo and Sun, was a powerful product. Porting to
    Apollo and Sun, and Unix generally, should have been a good
    strategy.

    You might have built some ‘strategic alliances’ with some
    companies that wanted to write applications for accounts
    payable, accounts receivable, cash application, general
    ledger, inventory control, ‘business analytics’, etc. on top
    of an ‘integrated’ data base built with your RDBMS and tools.

    You might have worked with ISVs to bridge from your products
    to running powerful valuable specific applications for
    specific customers. Around 1980, there were MANY such ISVs
    racing to bring up basic on-line business applications, on
    IBM, HP, DEC, DG, Prime, etc. ‘super-mini’ hardware, and far
    and away the one piece of ‘infrastructure’ or ‘middle-ware’
    software those ISVs most needed was a good RDBMS with good
    associated tools.

    As I understand the start of Oracle, their first sales were
    really just for some good ‘report writing’ and ‘business
    analytics’. E.g., someone would have a reel of tape with
    sales data in some simple format for the past six months and
    want some ‘report’ tables and some ‘charts’. So, they could
    read in the tape, and the Oracle software would help them get
    the output. You had such tools and much, MUCH more. If you
    needed a few more such tools, you could have written them,
    too. If you needed some highly caffeinated hot shot highly
    motivated sales people and a take no prisoners SVP Marketing,
    so be it.

    Heck, just writing solid software for disk-based balanced
    multi-way branched trees is not so easy, not nearly as easy as
    it looks in Knuth. Just that alone could be the basis for
    some decent business success.

    You had it all, on a platter in your lap. How’d you manage to
    blow it? TELL US! What HAPPENED!

  • 721

    As an observer in the fraternity, I seem to recall that you (Brad) once said that Martingale also had a “too many cooks” issue going on. Everyone was in charge and it was no one’s job to do the work.

  • http://www.practicevelocity.com VelociDoc

    It is true that we mainly seem to hear about amazing startup successes, but failure in software startups is probably the rule. Is anyone aware of SBA or other stats on failure rates of software company startups?

  • Pingback: adjustable dog collar

  • Pingback: cheap auto insurance in georgia

  • Pingback: cheap auto insurance in houston

  • Pingback: limo hire London , limousine hire London , limo hire , limousine hire , hummer limo hire ,London limo hire , London limousine hire ,

  • Pingback: cheap auto insurance delaware

  • Pingback: quote for car insurance

Build something great with me