Stop Looking For A Technical Co-founder
techcrunch.com
techcrunch.com
* Jamie came well-referred by technical people I trusted. That introduction makes a huge difference (being approached by a random "biz guy" cold is almost always a non-starter for me.)
* She produces -- objectively. Jamie got the initial version of the product built, brings in crazy amounts of press, and has don a ton of work to seed our marketplace. Oh...and she also writes HTML and CSS. I'm amazed by what she's been able to accomplish.
* During the "founder dating" phase, she never made me feel unequal. Too many business people do things (inadvertently or otherwise) that make potential technical co-founders feel like the unwanted, silent partner who is little more than an equity drain on a world-changing business idea. Jamie was looking for a business partner, not a coder.
The bottom line is that finding a technical co-founder is hard, but not impossible. You have no idea how many smart coders I know who would theoretically love to do a startup, but "don't have an idea", or are hesitant to take risks, or have some other form of inertia that's keeping them in a boring day job. If you bring demonstrable value to the table, have respect for the people you're recruiting, and treat them as equals, you've got a chance.
[1] I'm putting this down here because I'm honestly not trying to plug anything, but some of you may be curious: http://www.vayable.com
Take data representation as an example. In school one of my professors used to harp all the time that data representation is, in his view, the most important aspect of programming. He'd say something like: "Pick the wrong data representation representation and you can make a simple project into a nightmare to write, maintain and extend".
Programming is about having an arsenal of non-language-specific concepts come to your fingers as you think about the problems you are trying to solve. Data structures, algorithms, data representation, design patterns, optimization, tool selection, workflow, etc.
This is particularly true today when a programmer might have to be comfortable with half a dozen languages in order to create "a simple website" or a mobile app.
Yes, anyone can learn to code. Programming and building non -trivial products takes time, experience and lots of hours making lots of mistakes while you continue learning.
By all means, go and learn. Anyone can do it given time and dedication. I just don't agree with articles that seem to imply that an art student can go out and buy one of those "learn in 21 days" books and become a programmer. Not how it works.
Whenever I hear "just learn to code," the rationale is totally wrong. As you said, anyone can code, but to expect a non technical guy to learn and maintain a product can be unreasonable in some cases (the blog posts section on MVP and simplifying your product can only go so far in some cases). The true value in learning to code is gaining an understanding of whats involved in the process. No matter how minute the experience is, anything at all can help
As for "how much is enough", I would suggest that you should be able to hack together a prototype of whatever product you're trying to build. It doesn't have to be pretty, just show the interaction.
I think with the tools available today, most people should be able to go from zero to something workable in six months or so.
You don't need to be a seasoned hacker to throw together some desktop/mobile frontends in a free trial of Dreamweaver, put that on EC2, design a barely functional data model in phpMyAdmin, and glue the whole thing together with hacked up PHP. Hell, you could even get most of the way there without touching code at all before hiring a freelancer to take you the last mile (if you can't make a Dreamweaver mockup and a relational data model – even if they both suck – then you have no business being in charge of any product, much less an entire company).
After you've earned some traction from people who are willing to use your product, in spite of its inefficiencies, because it succeeds at solving a legitimate problem for them – that's when you'll have a shot at convincing me to quit my day job in exchange for 30% of the company.
MVPs can be rewritten from scratch after it's been demonstrated that the product is worth creating in the first place.
I originally learned to program via QBasic in 21 days. DOS in 21 days. VB 6 in 21 days. ASP in 21 days. Borland C++ in 21 days. HTML 5 in 21 days. PHP+MySQL in 21 days.
Because that's what we had! The books came with CDs of code examples and compilers you could try that worked on windows. And by the end of the book, you had a working chat program.
Was it great code? Secure? Scalable? Efficient? We'll never know because that code is long gone. But I wrote quite a few chat servers, hit counters, and dentists' websites back in my day.
And that is basically what "Learn Python the Hard Way" is. Teaches you the basics, builds up to some neat little projects, and since most of the software problems in the world are variants on "how do I loop through a list of blog entries and display it in a table" then I am not convinced that this is a complex enough problem that 21-dayers can't come up with a good data representation.
For the vast majority of us who will never ever face scaling problems, not understanding the cost of a hash table lookup is perfectly okay for an MVP.
The stuff you learn in school is completely valuable. But sometimes I feel like the things I learned (caching algorithms, design patterns, etc) put me in a mode of "spend a lot of time trying to architect" rather than "building something that works and upload to github."
"Just learn to code" emphasizes the latter, and I think that is a good thing.
No, what I am saying is that becoming a good programmer requires a lot more than what is covered in these 21 day books. To be clear, I don't want to pick on those books, I've used them myself and they are excellent. However, I come at it with twenty years of having worked on everything from assembler to, well, all kinds of languages.
It's one thing to be able to to hack at a language. It's quite another to be a good programmer, regardless of what language you happen to have to use.
It's the difference between Luke flying the Starfighter with instruments and using the Force. One focuses on the mechanics, the other just flows through you.
OK, maybe I went too far on that one...
I completely disagree with this. You want to find a co-founder, not an employee. In the early stage your technical co-founder will be doing 90% of the actually work. To offer them a small equity stake because it's your idea is an absolute joke.
To me, it seemed like his advice boiled down to this: "If you want a technical co-founder, prove yourself and get some traction for an MVP first (it isn't impossible if you're committed). When you later meet with a potential co-founder, don't sound like you're desperately seeking the first person who knows how to fix a sinking ship."
In particular, offering equity as part of a freelance arrangement is just dumb all round. It's a lose-lose situation.
A freelancer wants cash, not lottery tickets in your non-existent startup. And giving away a chunk of your company to someone who's only going to be around for a few months hurts you too. I know there's one UK startup that was founded that way (built by a web agency that got a chunk of equity) and it caused no end of problems. Either get a co-founder who's in for the long haul and reward them with equity, or get a freelancer and reward them with cash.
http://www.humbledmba.com/please-please-please-stop-asking-h...
Sometimes opportunities are fleeting and you need a team of people to succeed while the getting is still good.
A secondary problem with going it alone for coding your MVP is that you don't amass skills at the same rate as someone who is working full time as a programmer.
You can learn quite a bit more material if you are under the gun to get changes made for clients who are paying you, and this can be multiplied when you are working with other people who know more about solving programming problems.
For what it's worth, I aspire to be the "technical founder" for a couple of startup ideas that I work on, but I quit doing other things with my one-man-shop media business.
My strategy (as someone who programmed in HS/College and quit for a decade, and who is now moving from being a wordpress hack to owning a more diverse set of programming tools to solve the problems I am give) has been to find work as a freelancer for a progressively higher-level agencies.
Even though ultimately my goal is to have the tech chops to realize my vision (and working for other people is a sideline to that), it doesn't hurt that I've been making a really good living programming for other people while learning how to do a diverse set of technical tasks.
This plan, of course, has taken me two years so far, and I have budgeted another two years for the same path.
If your time frame is short for a real product, indeed: "you need a team of people to succeed while the getting is still good".
The way to tackle large problems is to tackle enough small problems to build the experience and track record you need, not 'find-someone-to-pay-me-to-hire-someone-else-to-do-it'.
Agreed, a lot of the material has been covered before. A lot of the value in the piece is structure rather than particularly original insight (though I'd love it if the Peanuts/Monkeys meme caught on). I did my best to link to as many of the better pieces on the subject; I hope some find it useful.
So I've decided to try and hack together whatever I can, just to show my potential future technical co-founder that I'm willing to do the dirty work and pull my weight. Do whatever you can, use wordpress temporarily, get started by outsourcing the work, set up a landing page with email signups. Show your co-founder that you've taken significant steps, minimize their risk, prove your product or service has traction, and already start heading towards some kind of success. Make it so that your co-founder doesn't have to build everything from scratch.
A product/service is what makes a company. Asking a programmer to make your product is basically asking them to build the foundation of your company for you. And no one is going to do that.
1) Learning to code isn't hard? It is. But let's say you did learn some basic stuff and put up an MVP which is gaining traffic. You now need to hire more engineers. How are you going to vet them? When you hire them are you going to manage them or are they going to manage you? Are they just going to take over the product? How do you know if they are doing a good job or not?
2) Hire an external team. Good luck! You have all the same problems as above but now you are probably paying a lot more cash and less equity for the work.
3) Simplify your MVP. Wait, but I already did simplify it, and now I need to grow it! An MVP does not a company make, and once you do make an MVP all your problems don't naturally go away.
4) No settling for a mediocre team. I spend a lot of time interviewing people for engineering positions, I have a very strong technical background, and I can assure it is extremely difficult. Great people and mediocre people don't walk around with signs around their neck. They all blend together and it is your job to identify them, and it isn't easy at all.
As somebody mentioned in a comment post, I think this similar article which is linked to is significantly better:
http://www.humbledmba.com/please-please-please-stop-asking-h...
This response for how to find a technical co-founder is just perfect:
> I can't help you with that, but all the good entrepreneurs seem to figure it out. Hopefully you will too.
I also think it applies for a technical person finding regular co-founders as well.
You need to have skills that another person thinks would compliment them, and then convince them of that. I think the distinction between "technical" and "non-technical" already is bucketed too much, since being able to write code is just a skill on a talent spectrum just like anything else. You don't need one person who is amazing at writing code and one person who doesn't know anything. Two people who each know a little bit might work. One person who knows a little might work. There are no preset rules, because every company and idea is different. You gotta figure it out.
Would my expectation be that I could find a great baker to work with me for free or half-salary? Or that I could learn to bake well enough to keep up with the competition out the gate? No - chances are I'd either have to shell out good money to hire a skilled baker who actually knew what they were doing (and probably fail a lot regardless based on my total lack of knowledge in selling bread) and/or spend a few years producing deformed loaves of bread by myself before this plan would work.
So for the non-technical founder to start a technology company without the money to hire experienced technologists I think its completely unreasonable to expect anything less
That's just the tip-of the iceberg though. There're so many programming discipline that newbies need to learn if they're serious about building a great product and being a project manager.
Most? Really?
The thing that really gets me is the implied equivalence of salary and ability, surely a belief shared by all those floating on the startup bubble, but pushed sustematically by techcrunch et al. as subtly as the propaganda of fox news.
$99/month? Shouldn't that be $99/year?