The Trouble With Non-tech Cofounders

This is a guest post by Scott Allison, CEO and founder of Teamly.com.

It seems learning to code has become a theme in 2012, and the demand is being met by Code Year and others. I want to reflect on my experience as a non-technical founder and reassess my original decision – almost two years ago – to stick to what I'm good at, and not waste time learning to code.

So, should people who can't write code do a startup? This is a tricky one, on the one hand I'm all for encouraging entrepreneurship and giving people the chance to give it a shot, but on the other, I know from personal experience how hard it is if you can't. I meet people all the time who have no technical background whatsoever, and they want to start an online business, perhaps build a mobile app, or launch a SaaS product. Sometimes, like me, these people have had previous business success in another area, so they naturally think they can make a success of anything.

Well, I'm sorry to tell you this, but the one skill you really need is the one skill you don't have: the ability to bring your idea to life by writing code. The process of iteration is far easier if you, the person with the idea, can actually code it and that's what ultimately makes a startup turn into a successful business: iterating to get to product/market fit.

Running a business is a repeatable skill; if you've done one well, you should be able to do another well. But a startup isn't a business, yet; it's an idea which may or may not work, and all the traditional business skills you've got don't count. Yes, you have good working knowledge of accounting, an idea of how to bring in sales leads, run a marketing and PR campaign, recruit people and build a great company culture, but that won't help you build a product that customers want. The problem with non-technical founders is that they don't know what they don't know, until they're in way too deep.

The Social Network is a great movie, and for many people quite inspiring as it tells the exciting story of how Mark Zuckerberg built – what is now a massively successful business – that he started at the age of 19 in his Harvard dorm room. But when you watch the film please remember that Mark Zuckerberg is both an exceptional individual, and a very skilled computer scientist. But it wasn't his idea; it was the Winklevii, those famous programmers Olympic athletes. That's why everyone says execution is everything, not the idea itself.

I've seen the problem with non-tech founders a few times now, different people, different ages and backgrounds, with different levels of skill, but all with the same thing in common: having to rely on someone else to bring an idea from paper to screen. The most common mistake I think people like this make is to think that they know in advance what they need to get built, and once they've paid for that to be done, and a website has been delivered, that they then have a business. They might, if they're really lucky, but more likely they have just spent tens of thousands on their hard-earned cash on nothing more than an initial prototype. It may look much more refined than that, but until you've got real people using it you won't find out if it really solves that problem or if people will pay you anything for it. If you still don't know what product/market fit is, and why it matters, please read up on it.

My experience: I exited my last company, an award-winning B2B telecoms operator, and knew that I wanted to build a SaaS product. I wanted to go back to my roots (my first business was ecommerce) and start something scalable that solved some kind of management or collaboration problem for businesses. While searching for an idea I educated myself, travelled to Cambridge, MA as well as Silicon Valley, attended conferences like Startup Bootcamp, BizTechDay, and LeWeb, and I started building my network as well as reading blogs from Marc Andreessen, Eric Ries, Steve Blank and others. I quickly realised what I was getting into and what my shortcomings were.

I wanted to maximise my chance of success, so I set out to find a technical co-founder who would complement me, which I did early in 2010, and with his help we launched Teamly into beta in the summer.

And then later that year, for personal reasons he left. Uh oh.

In a two-person startup, when the only person who can actually build the product leaves, it's more than a bit of an inconvenience. That would have been a perfectly sensible point at which to bail out, but I was encouraged by the reaction from some of our most enthusiastic users to the product and a deep conviction that this is a problem worth solving. (Three major acquisitions in as many months in this space confirm it is). But still, enthusiasm and determination will get you only so far, and when it comes to being able to enhance, amend, or even fix a web app, these qualities will get you precisely nowhere.

If you can't code, then no matter how much you wish you can, you still can't code. I resisted the temptation to learn, thinking that was a really dumb thing to do, "I know what I'm good at, why become a jack of all trades?", so I stuck to what I already knew but that didn't help me solve the problem. So, to plug the gap, I hired a contractor full-time with the goal that when funded he would come on as a permanent employee.

However, doing this turned out to be an incredibly high-risk strategy, as the significant cost shortened the runway considerably, and in the end I had to let him go because we came to the end of the runway, and he needed money and a stable job for his family. Part of the reason I took him on was that it's basically impossible to raise funding if you don't have a core team, so I felt like I had no choice because I didn't yet have a sustainable business and without the team wouldn't be able to raise funding to get to that point.

Things at Teamly have picked up since then significantly: I have an amazing new technical cofounder, and we're on the lookout for another to join us. But I was determined, persistent and frankly, lucky as well.

I also started learning how to code, not for the purpose of actually doing development work, but so I can better understand this most crucial element of Teamly. (Chris Dixon recently wrote a great blog, "Who should learn to program?", which hits the nail on the head very well). Part of the problem when you know nothing about the tech is that you think you just need "a web developer". But you'll quickly learn that all developers are not the same, and there's a range of skills: front-end, back-end, UI, UX, design, etc. Becoming familiar with them all will be time well-spent.

It was easier for me, I've always been a geek, as a kid I was coding in BASIC, and I wrote the html for my very first business's website by hand. (Sadly it was a class in C at University that put me off coding for life). Anyway, one of the things I did last year to improve my understanding of the tech side was to spend a day just sitting in front of my computer and creating my own crib sheet of terms; it was a day well-spent. It's important you know the difference between Java and JavaScript, MySQL and MongoDB, front-end and back-end; I could go on.

Not convinced? What if your technical person got run over by a bus tomorrow; could you access the code repository, reboot a stalled server, or edit something in the database? The starting point of this is to know what all the constituent parts are that make up your web app. Do you even have access to the above?

So, please, do keep working on that idea you have for the next Facebook, Linkedin or box.net, just be aware that you can and should take much more interest in what will make that a reality: lines of code.