Xobni Man Walking Some thoughts from an entrepreneur

I’ve been thinking about why programmers/engineers are bad at selling things – products, ideas, themselves.

First, engineers suck at spin. They deal in facts, not emotions. The suspension bridge is going to stay up or collapse. The software works or it doesn’t, and no amount of framing, rhetoric, or rapport will change the facts. An engineer who spins things to themselves or others would be a bad engineer; facts are king.

It gets worse. Not only do engineers focus on facts, they focus on the negative.

Programmers survive by paying attention to the ugliness in their code. If you wake me up in the middle of the night and ask what I’m dreaming about, I’ll probably tell you what the two ugliest parts of our code are, and how I’m going to fix each of them.

So when someone asks me about the code, my instinct is to describe the bugs. They’re just the first order of business! We have a natural tendency to look for and focus on the things that are not perfect.

Redemption

Luckily entrepreneurs know that they need to be able to wear many hats. If you’re already an engineer, you just need to learn how to sell the company, what you’re doing, and the product to people when you’re hiring, raising money, or talking to customers. You need new skills to do this selling.

It’s quite possible to pull it off.

I went to a talk by Bob Metcalfe at MIT in aug-05 where he talked about selling. He recalled his personal journey of learning how to sell. Remember, Bob came into the entrepreneurship world from MIT and Xerox PARC.

Bob said he went through four stages of learning how to sell:

1. Build a better mouse trap and the world will beat a path to your door
2. Once he realized that doesn’t happen, he’d argue with the customer. “You really need this product.” He would win the argument, but that left the customer with a bad taste in their mouth. He told the customer they were wrong.
3. So that didn’t work. He switched to Suffering fools gladly. Tell them what they want to hear. Over promise and under deliver.
4. Finally, nirvana. Listen to the customers, understand their problems, and make sure you can create value for them. Under promise and over deliver.

I’d say I’m at about stage 2.5. When I’m talking to a recruit, my basic pitch is “Your life would be better if you joined us. We kick ass and you’d find much more fun/responsibility/learning here.”

I think this can improve. I’m working on it.

Machine learning (6.867) was my favorite class at MIT. I just ran across the report from my final project in that class: Friendship Prediction on Facebook.

As part of my project, I wrote a web site that allowed someone to type in their name and get back a list of people I thought they were friends with in real life but not on facebook. I put together the web site between about 10pm and 8am the day the report was due. [1]

The web site was the ugliest hack I’ve ever pulled off; it was in the final hour and I just needed it to work. Once someone entered their name, a task record was created in a MySQL table. I had a Java process polling the DB for new requests. Once pulled, that Java process would create 6000 feature vectors, one for each person at MIT that the query user might be friends with. Those were saved to a file. Then I needed to invoke a program called Weka to evaluate the feature vectors and output yes or no for each one. Trying to do this Shell() from Java wasn’t working, so I had the Java app write out a Windows batch file with the appropriate command. I wrote a VB app to poll for batch files, and execute them as they came up. [2]

I had another Java app poll for result files, parse them, and put them into the DB.

Each request, end to end, would take a couple minutes if there wasn’t any other load. The first java app kept about 1.8 GB of data in RAM that it needed to determine how close two people were in the friendship network.

Meanwhile, the client was being shown a page with a <META REFRESH..> so every 20 seconds it would invoke PHP to poll the MySQL DB for results.

Ah the beauty of throw away code!

Notes

[1] One of my favorite essays talks about the productive pressure of a deadline. Indeed.

[2] Here’s the main part of the VB app!

Private Sub Timer1_Timer()
File1.Refresh
For i = 0 To File1.ListCount - 1
Path = File1.Path & "\" & File1.List(i)
Open Path For Input As #1
Input #1, toexec
Close #1
Kill Path

Dim k As Integer
Math.Randomize
k = Int(Math.Rnd() * 984)
On Error Resume Next
Kill "c:\a" & k & ".bat"
On Error GoTo 0
Open "c:\a" & k & ".bat" For Output As #2
Print #2, toexec
Print #2, ""
Close #2
Shell ("c:\a" & k & ".bat")

Next
End Sub