Tuesday, December 29, 2009

Share Your World Changing Ideas

Every once in a while I get an idea that really knocks my socks off. It is an idea that sweeps my imagination and gets me passionate about seeing the idea through to completion. I will usually spend at least 100 hours of my own personal time doing research and coming up with a plan to ensure its execution. These are the a-ha moments, the ideas you just have to act on.

As for actually seeing them through to completion, I have a dismal record. After all that effort on all those projects, there are only a few successes that I can point to. When I consider the difference between the ones that make it and the ones that don't, though, it has nothing to do with how excited I am about an idea. It is whether I worked on it with someone else.



I've been relatively isolated throughout my career from coders who also get passionate about writing code in their spare time, the kind of hackers I referred to in a previous post. I have lots of friends who love to code and who do it all day at work but very few who head home to create their own masterpieces for the sheer joy of it.

Even when I do find people like that, I've been surprised by how many hoard their ideas. I've been told more than once during a casual conversation discussing ideas that more details can only be provided if I am willing to sign a non-disclosure agreement. They don't actually have one written up, yet, of course, but if I'd be willing to collaborate with them they'll get one drawn up and we can proceed.

People seem to have an overblown sense of the value of ideas. In our capitalist society, there is actually a very good test to see what value there is to an idea: How much are people willing to pay for it: Paul Graham has written an excellent essay on exactly this question. The answer is that people are willing to pay nothing at all for an idea. Nothing. This is true even for an idea that you think is your million dollar idea that will make you richer than Croesus. To the market, it is worthless.

The reaction of the rest of the world to someone's really great idea is so counter to the way the person thinks and feels about it that it can be hard for them to understand. But no matter how passionately you feel that your idea will change the world, the simple fact is that the idea alone can do nothing. It is only potential. Before it can have any effect, before it can be worth anything at all, it has to move at least partly from being pure potential to actually being executed upon.

Execution is the hard part, and the rare part. As Paul's essay explains, when investors put money into a startup, it has very little to do with the idea they are starting from because it is unlikely the idea will survive in its original form anyway. They are investing in people who can execute. That is where the market value is. And to be someone who can execute you need more than the world's greatest idea. You need talent, perseverance, and as Malcolm Gladwell's book Outliers makes clear, a whole lot of luck.

It turns out that the perseverance element in this equation is not static, at least not for me and I suspect not for most other people. When I look at which projects I completed from idea to shipping and which stagnated, I see a compelling pattern. About 1 in 10 of my a-ha ideas ended up being executed when I worked on then alone. When I worked on them with other people, the percentage approaches 100%. That is an order of magnitude increase.

When I first made that realization it surprised me. After thinking about it for a while, though, I realized that I shouldn't have been surprised at all. Working on your ideas with someone else has all the advantages of something called pair programming. Don't worry, I won't let this get too geeky.

Pair programming is a seemingly counter-intuitive idea that some software developers have found greatly increases their productivity. Two people working on the same problem at the same time are far more productive than each of them working on their own problem. Kent Beck, one of the principle advocates of this technique, likens it to training basketball players. You can have two players practicing shooting hoops, each going and retrieving their ball after each shot, or you can have one player shoot and the other retrieve and then trade off. The latter method is the one where the players get the most amount of practice shots in, even though each spends half their time not practicising.

Pair programming, or pair idea-implementing as I would have it, works similarly. By having another person working with you it keeps you focused working on the issue. If you start wandering down the wrong path, the other person is likely to notice and bring you back to the right one. There is also a sense of obgligation to make sure you do your part if someone else is doing theirs.

Paul Graham's essay mentions that you should always startup a company with at least one other person. I think that needs to be expanded. Whether you plan on creating a startup or not, if you think of an idea that gets you passionate enough that you want to spend a significant amount of time on it, broadcast it and try to find someone else who gets passionate about it too. It increases the chance of success immeasurably.

No comments: