Comment by btilly | Hacker News Reader

Comment by btilly | Hacker News Reader

My advice is even simpler.

Start trying to do the technical work yourself. Contract out particular bits if you need to. A poorly coded and shitty prototype that fits what you want is massively better than a polished application that isn't what you want.

I can hear the "But, but, but..." Wait and hear me out.

There is nothing to give you appreciation for what a technical person brings than trying to walk a mile in their shoes. There is nothing more frustrating than a non-technical cofounder who underestimates what technical work requires. And honestly, the stereotype of "non-technical founder needs technical co-founder" is some asshat with no real clue who will make their partner miserable. Besides, there is a huge imbalance of supply and demand.

But potential technical co-founders are much more receptive to, "Non-technical founder needs technical founder to help turn crappy prototype into product. The idea is good, but I know how much I need your help."

Why are technical people more receptive to that?

- The fact that there is a prototype makes it much more likely that the idea isn't just vague handwaving.

- The non-technical co-founder is willing to put elbow grease in.

- The non-technical co-founder's humility is going to limit unreasonable demands.

So willingness to begin the work yourself makes you MORE attractive.

This is great advice, and I'd generalize it the other way too. Ideally you want both founders to be willing to do whatever the highest value work is regardless of how closely it matches their skills. We often put technical skills on a pedestal because there's a high bar just to get started, but often times building the next feature is not the most important thing you can do. Most people rationalize doing what they feel competent at, versus sober thinking about what is really needed and figuring out a way to do it well enough to get to the next stage. Eventually you can and should hire people do these things, but in the earliest stage having one or two brains fully dedicated to figuring out the repeatable business loop end-to-end gives you dramatically more agility and opportunity for insight than limiting yourself to well-defined roles and expertise.

In short: founders should have T-shaped expertise.

I was told that the crux of being a founder is to be prepared to do everything yourself at least somewhat, and delegate because you don't have time to do everything rather than because you can't.

More or less, it may not be optimal use of time but you should be able to run the show for a decent amount of time without it capsizing.

> "Non-technical founder needs technical founder to help turn crappy prototype into product. The idea is good, but I know how much I need your help."

Not all technical co-founders want to hear that. I see tons of inquiries that say something like "turn prototype into product", and that activates a lot of likely-seeming guesses about their product thinking, tech debt burden, and how they see the technical co-founder or first hire... and none of them are positives.

I want a non-technical co-founder to have skill and appreciation for: domain, product, business, and fund-raising. That's a ton of work and skills to develop, I know I don't understand all of it, and probably there are entire abilities some individuals have that I don't even know exist. And they should know that I'll bring a comparable pile of abilities and appreciation of difficulty, including some things overlapping with theirs, some things they don't understand, and some things they don't even know are things.

(I'm sure there are technical co-founders who see the role differently, and maybe more like a junior programmer hired to grind code and knock off sprint tasks, but that's not the holistic technical co-founder role that I see.)

Indeed. I understand how difficult it would be for a non-technical person to achieve that, but it could pay-off. I once worked with a sales guy, who owned a consulting business and planned to launch a SaaS. He coded a first version himself, using PHP, and began offering it free of charge as part of the courses he sold. His code was a complete mess, but the software he built significantly improved his chances to attract a technical person and establish a successful partnership, for both sides.

Reply on news.ycombinator.com