Honestly, I used to have the same sentiments as the author (I'll birth the idea, you code it), but the truth of the matter is that no technical person, friend or acquaintance, will feel in their heart of hearts that even 50% is an equitable split of work for the early stage of a tech startup, which is pretty much entirely coding. On top of that many young coders today are actively working on their own pet projects on the side and will feel even less compelled to work on a project that they had little hand in developing as an idea.
My solution? Why, learning to code myself, of course!
Exactly, and once more it puzzles me how people tend to overestimate the value of simple ideas (he was talking about a recruiting-related site, not that 2 years ago there wasn't any) and consider the actual implementation as just grunt work that everyone can execute just following a "plan" already defined by the original "founder".
And all that "making friend with a programmer to have my site built" it's even more sad.
The suggestion to evaluate what you are really bringing to the table in such cases is spot on. Evaluate fairly what your contribution is worth and make a meaningful offer to a tech co-founder you know. If you just need someone to work under your directives just hire someone.
In the first paragraph alone there are two huge, billowing red flags.
1. The author thinks that a technical co-founder is "a software engineer who works for no cash."
2. The author went through four "technical co-founders" inside a year.
My guess is the author was looking for freelance-type work, paying out equity "as if" it were cash (i.e., as a function of deliverables vs. a vesting schedule), and in general was micromanaging the engineers he found.
A co-founder is a business partner, not "your" employee.
Well there is this strange thing called open source software where I believe people work for free.
Jokes aside, I can understand why this guy has trouble finding a technical cofounder. It's all in his attitude. A partnership needs to be on an equal footing with a large degree of mutual respect. Of course it's hard to tell from just one blogpost, but it might be the problem.
"Well there is this strange thing called open source software where I believe people work for free."
Most of the time those people don't work for free, they just decide to release the code they've made with the goal of getting paid. Basically, open source software is not the goal, just a (generous) side effect.
He even says in his bio: "In addition to recruiting, Michael is active member of San Francisco's open source software community. He organizes events aimed at teaching people about technology, is a teaching assistant for Ruby on Rails courses..."
Mind boggling that he is an active member in the SF open source community and still thinks that developers don't work for free on worthwhile ideas.
Agreed. The other challenge is getting the software engineer to buy into the plan. Even if they're on equal footing, they may not feel like it because they ultimately believe it's viable. It's also harder to feel good about writing software without cash in the customer validation phase. If you have to pivot and walk away from code already written, it's hard to feel good about that.
Business people that just aren't that good will exploit you by trying to get you to work for free. Business people that are good will pay you for your work and will multiply that investment as their reward. It's amazing how often the latter is demonized (e.g., Bill Gates getting DOS for roughly $100K) and the former is held up as the ideal person to go into business with (e.g., complementary skills).
And what an idea? Lets make another recruitment site. Wow. Huge. I have started to see this with all recruiters these days, where they have their own job search engines on each and every recruiter site. They all want you to make accounts as well. Genius.
He sounds like every other jackass on craigslist who wants to find someone he can tell what to do but not have to pay. It's no surprise that he didn't have luck, it's an incredibly unfair proposition. A partnership requires both parties to have skin in the game, you telling someone what to build doesn't qualify as skin.
I was not too long ago told by a business guy that it was generous of him to offer me even a small fraction of 1% of some web-based service I would be building. Because he had cash, connections, etc. The problem with that logic (which was not completely without merit) is that while I could build the entire site/service 100% by myself without him, he could NOT do the equivalent by himself. So he needed me more than I needed him. (He didn't need me, literally, but he'd need somebody else to build it for him. So he would have to give that somebody something in exchange.) And you don't actually need a lot of cash or connections to get the particular service in question off the ground. Cash always helps, sure. And connections help, sure. But in theory I could build the entire thing myself, start with 100% equity and control and 0 politics, and then only later when it became useful to leverage industry connections to do bizdev and land sales and affiliate deals, would he become useful to me, and thus at that point it could make sense for me to grant him some equity in compensation.
In fact, I feel increasingly we live in a world now where a hacker/entrepreneur hybrid can just go build some web technology or SaaS by themselves in relative stealth mode, retain 100% equity, and then later maybe give up 10% to a designer to make it look purty and another 10% to a bizdev guy, and maybe maybe another 10-20% to a cash investor (and outside cash may not always be necessary or desirable anyway), and the hacker/entrepreneur still retains the largest share and majority control. There are 2 secret ingrediants here, which is probably why it doesn't happen more: 1. the hacker must be really good and talented not just average Joe code monkey; and 2. he must also have business/entrepreneur skills/knowledge. If he lacks either or both of these things he's not going to have the capability and leverage to pull this scenario off. But for those that do, watch out.
If the idea is so great, I think he should be willing to put some money into hiring a developer to work with him -- and probably shouldn't necessarily call that person a cofounder unless he wants to give them equal say in the direction of the product.
I'm a business person first and wannabe hacker second, and I think the thing that is missing here is respect for someone who can do things that you can't. The main reason I've been learning to code isn't so I can eliminate the need for someone who can... I know I'll never be as good as someone who has spent their entire career learning to build software. I just want to speak the language, understand what is hard and when to call bullshit or just how to ask better questions.
If you're looking for someone to code up your dream website, go to oDesk or to a friend who needs some extra cash to bootstrap HIS startup.
"I just want to speak the language, understand what is hard and when to call bullshit or just how to ask better questions."
I'm working for a client who did this and it's awesome. When things get technical I don't have to force it into layman's terms--he understands. He also understands the nature of coding and how some things that are easy to conceptualize can be difficult to code (and vice versa). His decision to learn about programming has made it possible to have a great, trusting relationship with good communication and great results (this is the most productive I've ever been).
I've actually been down that very same road - looking for a technical cofounder but finding it hard. There simply aren't that many people that are both smart, get things done and want to do a startup. At least not where I'm located.
As a business geek I took another route after thinking about how to remedy the situation: Learn to program. Best decision I've ever made.
More likely, there aren't many people that are smart, get things done, and want to do your startup. There're a whole lot that are willing to jump in for their own ideas. Almost everybody would rather be working on their own ideas than someone else's ideas; that's basically what fuels the startup industry.
There're two basic solutions to this: work on your technical skills, or work on your leadership skills. (And remember that leadership isn't telling people what to do, it's making them want to do what you want them to do anyway.) Working on your technical skills is the easier course; it's what I've chosen to do, it seems to be what you've chosen to do, and ultimately it frees you from being dependent upon other people to build your prototype. But working on leadership skills probably scales better, since at some point, you're going to have to work with other people anyway.
While I think your post is very insightful the problem for me wasn't really finding someone that wanted to work on my idea, it was simply finding someone skillful that was willing to risk doing a startup. I've never had problems convincing people to work on my (or their..) ideas, but I've always come across people that either didn't know what they were doing or quit when the going got tough. It probably has a lot to do with location and culture.
By the way, the added bonus of learning to program is that you'll be in a much better position to judge the merits of a technical cofounder.
The problem is that most "business" co-founders think they are better then they really, most of the time they try to ride on the back of the 'tech' co-founder. Lets face it the so called business people are good at BS and in the end its not what you say its what you do that matters.
I'm a fairly technical person (i.e. I can code), and I've gotten other technical people to totally buy into my idea, contribute to it, and "own" it in that sense. But I find that his thesis is still correct, most people need validation of the idea before they will jump into it.
In that, he doesn't need to qualify "people" with the adjective "software engineer". The same principle applies to design folks as well. The bottom line is, if you want to make it happen, you better pony up or do the work yourself. If such skills and effort came for free, don't you think someone else would have done it already?
As a technical architect / software engineering type person, I've helped out more than a couple of startups for equity, cash, or a mix of both. Have I done the "co founder" route? No, for two reasons -- first, the risk in focusing on a single idea and hoping for success -- I haven't run across such an idea that I am willing to dive whole hog into; and second, there are two phases to getting a startup going - the initial proof of concept and the engineering behind the actual service. I enjoy both, but the work needed for one is different than the second.
At this point, I am always looking for new ideas and interesting startups to help out. However, I am erring on the side of mercenary rather than owner. That is not to say, I don't wholly to commit to endeavors, but the ideas that interest me and the ones that provide opportunity to help out don't necessarily intersect.
Sounds to me like the author originally went in looking for technical chops, not friendship/compatibility. A cofounder isn't someone you throw a project at and expect results, it's a relationship. Compatibility means so much more when you're founding a company together (not just having the other person work on your idea), than technical ability.
If he is running a successful recruiting business it would seem that there would be some kind of revenue share model as a part of the business partnership. The story doesn't add up but it sounds like he had an evolving feature set that was driven by a vision not by a focus on generating revenue he could split with a technical co-founder.
I had someone approach me with one of these "ideas" a while back, I remarked that a finders fee is usually 10% and he got furious and hung up the phone. Then he called back and agreed to the term "finders fee" but then claimed that it was worth 50%. Needless to say I declined.