Posted on

Handshakes, Term Sheets and Trust

I read this story yesterday about a failed startup acquisition. It’s one of the big nightmares of an entrepreneur: Big Company shows interest in Startup. Acquisition talks go well. Handshakes and gentlemen’s agreements happen. Startup day-to-day is disrupted during the lengthy acquisition process. For whatever reason, acquisition falls through. Startup is now much worse off than before: less money, low morale. This paragraph stuck with me:

As I look back on it, there were a few things we could have done differently, although I suspect we’d have gotten the same result. We could have insisted on a term sheet, even though term sheets are non-binding. Maybe we could have negotiated a breakup fee in case the deal fell through, although I don’t think we had the leverage to force them to agree to one. Ultimately, the real lesson learned is this: get your business to a level of success where you don’t care if the deal falls through.

In my opinion, this is not the best lesson to learn from that experience. Sure, if you build a successful business then you’ve won. Become Facebook, go public, write posts like “hey, look at our beautiful desks.” That much is obvious, but these guys are a little startup. There are other lessons here, one of which is about the art of trust. The “art of trust” you may say? Just sign contracts, and don’t believe in any words anyone says. Trust but verify. No need to ever blindly trust anyone.

If that were the case, businesses couldn’t function. In the world of business you trust people every day who (in game theory parlance) could defect at any time. Your employer can fire you for no reason. A big customer can stop paying a bill on which your livelihood depends. Ah, but you have a contract so there are penalties. Right? Let me tell you a short anecdote.

Many years ago I was running a consulting business, and one of our customers was a famous internet company at the time. We had a contract, they were paying us 20k per month on an indefinite basis. The contract stated that they had to give us a 90-day notice before canceling it. Of course, the day came that Company no longer needed our services. The new person in charge had no idea about this clause in our contract, so I brought it up. “Let me think about it, and I’ll get back to you tomorrow.”

The next day, Person In Charge tells me “you’re right, we cannot cancel the contract without 90-day notice. This is your 90-day notice. For the next 90 days, here’s what we want you to do.” This was followed by a description of the most horrendous task the company could think of, the software equivalent of the escape scene from The Shawshank Redemption. At that point I conceded, we shook hands and parted amicably.

So contracts between a small company and a big one are mostly a psychological anchor. It comes down to who’s willing to sue, or who can afford it. Contracts assume everything goes well, and more than anything they spell out in writing what the parts are supposed to be doing so there’s no confusion.

What does this have to do with the story above? I believe the startup should have pushed for the term sheet as soon as possible. Either the acquirer would have said no (end of story right there), or the sheet would have been signed. A term sheet increases the likelihood that the acquisition will go through, even if it’s non-binding. This is because putting it together and agreeing to it takes a serious amount of work. As the acquirer puts work into the deal, biases like the Endowment effect and sunk costs start kicking in. This makes it psychologically harder for them to back out. 

The bigger question: who to trust and when? Maybe there is a formula for that, but I don’t know it. Experience certainly helps; the more you’ve been exposed to bullshit, the sooner you recognize the smell. Of course, in an ideal situation both parties work hard to align interests so there’s little need for trust. The challenge in that case is to periodically verify that the interests are still aligned, because they can drift apart very quickly. If you happen to be working with a party that has a public reputation, you want to try to set things up in a way that betraying your trust would hurt that reputation. Of course, sometimes you can’t do any of those things, and all you’re left with is your intuition. Well, at least you can study the history of the other party, and ask other people who have dealt with them. That’s why it’s so hard to get business when you’re a startup: you have no history.

The gist of this meandering post, if any: in business sometimes you have to trust others even though they could defect. That can be especially costly in a startup, but those are the breaks. May The Trust Be With You.

Posted on

Why Do Alumni Donate to Their Alma Mater?

If you go to college in the US, after graduation you’ll start receiving requests to give money to your university. Given that universities in the US are businesses (usually run very efficiently), I always wondered what would motivate alumni to donate. There are many worthwhile causes in the world (e.g. hunger, malaria, preventable diseases). Why choose a school that may use your money to build a world-class swimming pool or running track?

Maybe it’s the way things have always been done in the US. I have a different perspective because I got my first degree at the University of Buenos Aires, in Argentina. The UBA is taxpayer-funded and free (as in beer, students don’t pay a dime). The quality of the education we received was excellent. I don’t remember ever receiving a request for a donation after I graduated; I suspect the university is not even set up to receive donations. Of course I always felt a sense of indebtedness to my fellow taxpayers, which was one of the reasons I chose to start a company in Argentina. Mind you, I’m not a bleeding-heart altruist. I probably wouldn’t have done it if it hadn’t been a great opportunity. However, I did feel that creating local jobs and spreading some lessons learned in Silicon Valley provided a sort of return on the taxpayer money spent on me.

With Carnegie Mellon, it’s a different story. When I first got there in 1997, I was taken aback by what I perceived as a display of wealth on campus.  The facilities were world-class, all buildings looked beautiful to me (and it is no Stanford!). The manicured lawn was a stark contrast with the graffiti-filled walls of UBA buildings. The fact that I had to pay hundreds of dollars for textbooks added to my surprise. In Argentina professors typically do not have their own textbooks. They suggest a few titles, and it’s up to students to figure out if they want to buy them, borrow them or learn the material in other ways.

I graduated from CMU many years ago. Since then I’ve been receiving emails asking for donations, and I’ve even given money once or twice. Because I recently had a “startup exit” a fellow alumnus asked me to join him in a slightly larger donation. This got me thinking, why? Carnegie Mellon has 2.3 billion dollars in assets. Furthermore, their assets increased by 278M in 2011. They certainly don’t need my money. Don’t get me wrong, I’m extremely proud of having attended graduate school there. Going to CMU for my Masters in Software Engineering was one of the single best decisions I’ve ever made. I have no doubt that I wouldn’t be where I am if I haven’t done it. But unlike other classmates I wasn’t corporate-sponsored. Getting the degree was very expensive, especially for a foreign student. During that time my net worth went from positive to negative. All the money I saved during my first year working in the US went to pay back school-related debt.

Having said all this, the title is an honest question. I have no motivation to donate money to CMU. Why do others donate to their universities? To clarify even further, I’m talking about disinterested donations: if you expect a political favor, or to have your child admitted, that’s not really a donation in my view.

So no, I’m not donating money to universities in the US. Here’s what I believe is a worthy cause:

Posted on

Do You Know How Long It Took to Develop Word for Windows 1.0?

Those of us who work in software live in a world of lean practices. We are encouraged to prototype, fail fast and iterate. We have seen software-based companies go from an idea in a kid’s brain to a billion dollar business in the time it would have taken him to get a college degree. Of course, those are the outliers on the positive side. For every extremely successful software project there are a large number of failed ones that we’ll never hear about.

There are also projects that managed to survive only because they had the backing of an already successful company, flush with cash. Microsoft Word for Windows could be a good example. Not many people know the story of what would become one of the most widely used software products ever. I learned about it from a case study for my Software Project Management class in 1997, what follows is my summary (original here, or Google it).

In September of 1984 Bill Gates wanted a word processor that would run on Windows (being developed at the time). He gave the project to John Hunt, Andrew Hermann and Lee Arthurs. Greg Slyngstad (who would later become the program manager for the project) said:

Gates put three real hotshots on the project. Hunt, who had single-handedly written the first version of PC Word, became the project manager. Arthurs, who had a Ph.D. in psychology, was responsible for user interface and documentation. Hermann had been at Wang and was supposed to know the word proces­sor business inside and out.

The project was codenamed Cashmere, and it was scheduled to take a year or less. At this point you can probably guess that this did not happen. The scope for the project turned out to be too ambitious. At the end of the first year, all the team had to show for their efforts were some design papers. The design included features such as email, spreadsheet capabilities, document protection, and much more. Hunt left the project in the summer of ’86. Slyngstad came on board, along with Doug Kurtz (lead developer for the DOS version of Word), and other MS stars. The new team decided to throw away all the work done to date, and start from the Word for Macintosh codebase. The project was renamed to Opus, and was staffed mostly with new hires.

The next year went by as the team wrote a new spec for the product. Soon it was 1988, and the team was under extreme pressure to deliver. One development manager put it this way:

Opus got into a mode that I call “Infinite Defects,” When you put a lot of schedule pressure on developers, they tend to do the minimum amount of work necessary on a feature. When it works well enough to demonstrate, they consider it done and the feature is checked off on the schedule. The inevitable bugs months later are seen as unrelated. Even worse, by the time the bugs are discovered, the developers can’t remember their code so it takes them a lot longer to fix. Furthermore, the schedule is thrown off because that feature was supposed to be finished.

To make a long story short, the project was deemed “code complete” in late ’88, but it was full of bugs. It took one full year to stabilize it enough for release. The release date was November 30, 1989. This is more than five years after the start date, and four years behind schedule. Needless to say, this project taught Microsoft a number of valuable lessons. Their software development process improved tremendously over the next decade. A blue screen of death here and there is nothing compared to the above 🙂

You’d think the software industry as a whole has improved enough that schedules no longer stretch by 5x. If you work in software, you know it still happens. Why? Hint: not because of the explanation given in what was the Quora Answer of the Day a few weeks ago. If only it were that simple. A much better argument was made (in 1986!) by Fred Brooks: No Silver Bullet – Essence and Accidents of Software Engineering.”

Posted on

Open Source and Big Data: Two Things I Love About LinkedIn.

Today is InDay at LinkedIn. We are encouraged to spend one day each month learning, inspiring others, and sharing knowledge with the community. I’ve been at LinkedIn for four months now, and this day gives me the perfect excuse to write a post about two things I love about this place: open source code and big data.

Open source: I think LinkedIn has contributed some great open-source products to the world. My favorites so far are:

  • Apache Kafka: a distributed publish-subscribe messaging system. The design document is a great read, I believe anyone working with distributed systems should check it out. [btw, congratulations Jay on the new baby!]
  • Krati: a simple persistent data store with very low latency and high throughput. It’s similar to BDB but written natively in Java. It’s hash-based, which gives it better random access performance than BDB’s BTree structure. Jingwei Wu is one of the best systems programmers I’ve met, and I’m so happy that he’s on our team.
  • Project Voldemort: a Java implementation of the Amazon Dynamo paper. It’s some of the cleanest code I’ve seen, and a great place to start if you want to learn about distributed key-value stores. Also, you should follow Alex Feinberg on Twitter and Quora.
  • IndexTank, of course 🙂

There are too many to count at this point (SenseiDB, Zoie, Bobo, etc.). Take a look at our group’s page.

Big Data: we have a treasure chest of people profiles and activity, and a beefy Hadoop cluster to mine what we can out of it. More importantly, we have stellar data scientists like Daniel Tunkelang and his team. They perform daily acts of wizardry to improve our products, as well find out unexpected insights about the professional world. When I got to play with the Hadoop cluster a couple of months ago and try out a little idea, it was nerd Nirvana for me. Of course I have my hands full with search, but one of my goals for the next few months is to write a few more Pig scripts.

Of course LinkedIn is hiring like there’s no tomorrow; we need to understand that data even better, and we have a laundry list of apps we want to build on top of it. Check out some jobs.

BTW, this is what we had for lunch yesterday 🙂

Sushi


Posted on

Starting a Company Is Not Risky

In Silicon Valley we have this notion of the entrepreneur as the lone hero. A risk taker who shoots for the moon and aims to knock the ball out of the park. A visionary, a dreamer, a jack-of-all-trades. In another time he would have been a discoverer of new continents, a warrior, an inventor, a heretic. I could keep the clichés going but I’ll save some for another post.

Obviously such one-in-a-million individuals need all the help they can get. They are misunderstood by the world, ignored, ostracized, ridiculed. They need inspirational quotes and self-help articles about the importance of sleep, how to overcome “schlep blindness“, or how to survive fundraising (tip: always have your light saber handy during VC meetings; they are often traps).

Of course this is organic fertilizer of the bovine kind. I’m sure I’m repeating myself, but I’m not a fan of the self-help trope that pervades startup blogs and communities. First off, I’d like to end the myth that starting a company in the Silicon Valley is a risky endeavor. Risky compared to what? What could happen to you? Fail and go back to working for the man. Boo-hoo. Welcome back to the 99%.

What is risky? Working in underground mines (in lots of ways, not just odds of dying). Climbing Everest. Being an astronaut. Touching an electric train line [warning: disturbing].

The risk of starting a company as opposed to working for someone else is some opportunity cost, and maybe a bruised ego. Sure, you can work yourself to death and destroy your relationships in the process. Only that’s not because of running a startup. That’s just being a workaholic.

The next time I hear an entrepreneur bragging about being a huge risk-taker I’ll invite him to play Russian Roulette against me. With a nerf gun, of course.

Rant mode off, back to work (blogging is too risky).