The Real Reason I Will Not Be Your Technical CoFounder

I have been reading quite a few posts lately concerning the topic of becoming a ‘technical co-founder’ of a startup. Just search for the term on Hacker News, and I’m sure you will find posts on the topic from within the current week. Many other people have spoken eloquently on the topic, but I have always felt that the conversation was dancing around one key issue:

The #1 reason that I will turn you down is that I don’t respect you.

If you are not presently working on your product because you don’t have the skills, I will assume it is because you are lazy and not intelligent enough to do so. There I said it. It’s out there in the open, in all its cold mean glory.

I am not saying that I implicitly don’t respect non-technical founders, as quite the opposite is true! What I don’t respect is non-technical co-founders using their non-technical-ness as a roadblock.

Susan Koger, the founder of ModCloth is not a technical person, but I greatly respect her expertise in her industry, her leadership, and the company she and Eric have built. The Kogers cobbled together the first version of the site in a few days with some ugly PHP and did all fulfillment by hand for a number of years. There were tons of optimizations a more ‘technical co-founder’ would have done, but they didn’t let that stop them. They made it work and organically attracted the help they needed to grow.

The team I currently work with at TaskRabbit I respect more than any group that I have worked with to date. I am constantly impressed with the ‘non-technical’ side of the house. The best example I have is that one night while I was leaving, I was asked for an SSH tunnel to one of the database replicas by our Member Services team. It turned out the WHOLE MEMBER SERVICES team had taken the initiative to take online SQL classes together, and wanted to explore our data. I stayed late and granted that access. Today, I helped our head of Trust and Safety write some ruby that allowed him to automate rather complex data extractions into a single table. It was terrible, buggy code, but it worked. He didn’t want to give the task to the engineering team yet because he wasn’t ready to ‘production-ize’ it until he was able to try it out first. We have email marketers who write their own HTML and CSS, and write it well. We have PMs who create micro-sites and understand the gory details of oAuth because of it. We have Busniess Development folks who can solder and write python. I respect this team.

I’m a fairly terrible designer, but that doesn’t stop me from attempting to create a look & feel for my sites. I love the term "Programmer Art" which the video game industry uses when describing the blocky placeholder models which populate the pre-alpha releases of almost any game. Programmer Art is one of the best communication tools which exists. It communicates spacial layout, movement assumptions, rendering limitations, and most importantly, allows the rest of the team to clearly see which sections need the most help and can then prioritize their own work.

My point is this: If you are a ‘business guy’ who thinks you can’t start making your website or app because you need a technical co-founder, you are wrong and wasting your time. There are literally hundreds of tutorials, free software downloads, books, examples, and templates out there for you. There are tools like DreamWeaver that will let you make a website as easily as making a Power Point deck. And it will be terrible and incomplete. However, I would always rather see a terrible but functioning demo than a pretty deck (speaking as a potential technical CoFounder).

You will gain valuable insight into what will eventually become a key part of your business even if you try and fail. Your effort shows me you care enough to do it, and are smart enough to try.

Also, I have a job.