Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I think a partnership can make sense if there is complimentary leverage, i.e. both parties bring something to the table that the other can leverage to their benefit + the combination of both parties creates additional leverage.

Just having the idea in most situations just isn't a lot of leverage for a developer to become interested. But if you pair an idea up with:

Idea + capital, Idea + connections, Idea + salesmanship, Idea + passion + market opportunity + timing etc..., Idea + hustle, Idea + mentorship / experience, Idea + proof of concept, initial customers etc, Idea + market knowledge with a significant edge over others, Idea + accounting / misc biz skills

or a combination of those...and then you should be able to find a developer that is able to see enough upside to work with an idea person. The default answer shouldn't need to be 'learn how to code' in most cases. My viewpoint is to not do what you're hopeless at in 99% cases. There's not a lot of leverage there - ideas like speed. It's more valuable to get better at what you're already good at. If you're stubbornly trying to learn how to code and design despite hating the process, you simply didn't exhaust other avenues that yield a more expedient route to launching whatever idea/vision you have.

I did go down the learn how to code/design/market myself route because it's fun to me and that's a form of leverage that gives a potent edge. But I really hate seeing people struggle because they suck at what they are trying to learn, don't enjoy what they are learning but yet are using such things as obstacles to be conquered that they falsely believe are necessary to succeed. Sometimes it's just an excuse not to be doing what you're good at.



Absolutely. Mutually complimentary leveraging maximizes team members strengths instead of focusing on their weakness. I love the analogy of that my high school coach used to use all the time about the Quarterback and the Wide Receiver. Both are necessary components to scoring. One throws, one runs, and as a dispassionate evaluator, coach would always argue that the best thrower throw to the best runner, instead of suggesting that either the thrower or the runner should do the opposite. I think solving technical problems is similar. Hustlers should hustle and hackers should hack, so that together problems can be solved, and solutions improved. Because in the end, that's what important. Isn't it?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: