Note: this blog is inspired by my recent podcast interview with freeCodeCamp’s Quincy Larson, where we talk about this in the last 15 minutes or so.
Looking for a technical co-founder? I was too. For many years. It was a difficult journey, because the prevailing “wisdom” is you need to go out and find a technical co-founder because all the successful startups had them (not true, by the way). But what happens when you're at the end of your runway, and your choice is to learn to code, or quit?
Technical co-founders are supposed to give you the stability, the complement of essential skills, and the accountability that are not possible being a solo founder. Of course, no one is tracking the countless examples where having a rubbish co-founder made your journey immeasurably harder, or thwarted your ability to progress altogether. But of course, what “they” mean is that you don’t need just a technical co-founder, you need the right technical co-founder, duh!
Well, of course.
None of this is particularly helpful advice. It’s like saying you need to be awake to have good ideas (seems obvious and intuitive, but not always true).
My experience as a non-technical (solo) founder
Here is what I’ve personally experienced in the many years I spent looking for technical co-founders:
- I spent a ton of time browsing forums, LinkedIn, and contact lists looking for people who met the minimum criteria
- I spent a great deal of time not being able to validate much, test much, progress much because I didn’t have anything to validate, test or progress other than a well-honed pitch
- I met a lot of people, and most were not interested in entrepreneurship, or didn’t have the necessary work ethic (aka masochistic streak)
- I met a lot of people who were interested but for all the wrong motivations (get rich quick, glory, fame…)
- I met a few people who had the right motivations and (as far as I could tell) the right skills, but who did not have the mentality to withstand the brutality of starting up
- I met a very few people who had experienced starting up and had the skills, but none of them were enthused by my concepts (statistical inevitability)
I knew diddly squat about software, though I wanted to start a technology company. So, here are my mistakes from back then:
- I had no clue about the fundamental, most basic aspects of software and its design
- I grossly underestimated the complexity involved (didn’t know how much I didn’t know)
- I grossly underestimated time involved
- I grossly overestimated the people I approached to be technical co-founders
- I significantly (but not knowingly) overstated my role in the initial period — “hustling” and “business development” were my skills, and I did not appreciate that some of the most successful startup companies spent a third of their time on those things, and most of their time building the product and responding to customer needs
For close to 4 years I told myself “I do not need to learn to code. My talents are better used elsewhere”. Sound familiar?
It’s only partly true. As someone with very limited resources, my talents needed to be used on whatever gave me the best chance at succeeding. I had some spare cash I could spend on developers. I had some time I could spend managing them, and that time was mainly created by cutting down on social activity, sleep and disallowing myself weekends. I had valuable experience I could use in putting together a business plan. I had strong social skills and communication skills I could use to pitch to prospects, and also to potential co-founders.
I did all these things, and inched closer to my goals. But it took far too much time. Of course progress is always slow, certainly slower than we would like. But we only slow ourselves down further by not looking at the situation objectively. Even when I did have co-founders (who eventually quit because it was too hard or their life circumstances changed) I found that managing their work ethic, expectations and moods took a great deal of my time and energy. That’s ok — but no one budgets for that.
You see, as aspiring founders, our greatest enemy is anything that causes us to lose time. With every week that passes without results you’re more likely to quit. And we never truly know what our time-cost is when we choose a course of action. And we never know when we are victims of the sunk-cost fallacy.
Looking back, it cost me 4 years and quite a lot of money. And at the end of that, the only way to start again was to repeat that expenditure of time, effort and money, doing the same thing — putting together a plan, and then desperately looking for a technical co-founder.
Here we go again…
A simple time-math
In 2014 I read a blog by Sam Altman, the president of YCombinator. In it, Sam says some of the most profound truths I’ve ever disregarded. Here is the tweet that I dug up for fun.
The first 2 or three times I read his piece I made really sensible sounding arguments as to why it did not apply to me. I was wrong and it cost me money, but worse, it cost me a lot of time (I made back the money).
He basically posits that it’s faster (much faster) to learn to program enough to build your prototype than it is to find a reliable, dependable co-founder who is a good fit, and will go the distance. Not just faster, but the odds of progress are vastly higher.
It’s obvious. Finding a good co-founder, technical or otherwise, is a long shot — like finding the right partner for life — and requires some degree of luck. Learning to code a bit is faster, needs no luck and therefore has a higher success rate.
In fact you can stop reading this blog right here if you like. Read his. It’s better. The only reason I’m writing mine is to share direct, personal experiences that confirm what he said. It’s telling that to date his blog has only had ~8,500 views — of which a dozen are mine. That is much less than the number of aspiring non-technical founders out there.
A dating analogy
In high school, I remember being told that if you’re desperate for the affections of someone, you will act in ways that compromise yourself — your standards, your values and your best interests. You will settle for people, behaviours and situations that aren’t right for you.
It’s exactly the same with looking for co-founders. As time went on and my fear and desperation increased, I found myself compromising — reducing my standards. Negotiating against myself. Making excuses for others. Settling.
Over time I made bad decisions and bad compromises. Fortunately, none of those bad decisions resulted in actual co-founding relationships.
My point is that I was prepared to make bad compromises, just to make progress. That is a bad start to something that you may have to spend the next 10–20 years of your life on.
The technical stuff doesn’t end at launch
It’s tempting to be tactical and say I just need to get to launch. That is not a sustainable plan. There is a difference between planning to “make it up when I get to that bridge” and having to do that because life left you no choice.
I learned the hard way that my need for technical help grew after launch. I thought the hard yards were getting to launch. Boy, was I wrong. Things break. Bugs emerge. Features don’t work as expected. Users have strong views on things. Iteration is the way to achieve product-market fit. And it has to be rapid, well coordinated and systematic. Data helps, and lot of valuable data comes post-launch!
That is why paying for developers isn’t sustainable unless you got lots of funding. And you’re not likely to get lots of funding before you even have a product. It’s possible, but not for most founders.
So what are you going to do when 4 weeks after launch things are breaking, users are reporting unexpected bugs, and the server crashed, or the app store has changed some policy? You spend more money. And beg the developers to hurry up. Meanwhile you’re doing your darnedest to find users, pitch, sell, etc.
You’re spending your time on things, for sure, and they’re important. But given a choice between fixing a bug / adding a features your users are clamoring for, and pitching your business plan to a potential seed funder, the best use of your time is product, not the pitch. And you cannot do it because you don’t know how. So you exert yourself on things of second-order consequence because you cannot exert yourself on things of paramount importance.
Developing technical empathy
As I mentioned on the podcast, I was (mortifyingly) one of those people who insisted that “it is a simple, quick prototype”. I totally, utterly, woefully, lacked any concept of what the development process is like.
Quincy, the founder of freeCodeCamp and the one who runs the podcast, summed it up very well:
It gives you empathy for the developer experience, and helps you make meaningful time-estimates, not only in terms of what is possible, but also what is straightforward, and what is complex. [paraphrased]
Imagine if someone who has no clue about your work comes to you and insists that something that takes a week should take 2 days — wouldn’t you want to knock them on the head, and just turn away in disgust?
I’m seriously embarrassed by all the times I did this (insist that it’s a simple app, not knock someone on the head).
Worse still, why would they take me seriously? Had I really showed them respect and commitment by at least trying to learn a little bit of their craft? From their point of view, I was hiding behind my skills and the reasonable excuse that coding is “not the best use of my time”.
Here is another sinister side effect of not being knowledgeable enough on the technical stuff. I could never evaluate the relative skills of the people I spoke to. I had to go on faith, trust or recommendations. I had no way to assess their fitness for the very purpose I needed them to fulfill.
Looking back, I could have saved myself a ton of money and months of effort, while building a skill that extends my runway almost indefinitely — had I learned to code earlier.
As Sam Altman says:
“When people like this say “I’ll do whatever it takes to make this business successful” (which they almost always say), I say something like “Why not learn to hack?”
Why not indeed. Do whatever it takes. Especially if it helps your startup “not die”.
Engineering is not the be-all-end-all
Not for one moment do I think coding is the answer to everything. If you are among those who have an interested and totally reliable technical co-founder, classmate, colleague, sibling etc, then yes it’s not the best use of your time — why? Because you’ve got a great resource in that other person. Then learning to code is duplicating skillsets.
But when you don’t have that skillset, learning a little of it is the best use of your time, if it saves you a lot of time in the long run. Here is the math I apply:
priority = probability of outcome in a given unit of time
So:
Find a co-founder in 6 months and start build in 7th month : 50% probability
Learn enough code in 6 months and start build in 7th month : 90%
This entire article would be totally obvious if it said that coders need to learn marketing and communication skills to pitch. Coders need to get out of the building and talk to their customers and not just code. This is now considered “obvious” advice.
So why isn’t the reverse just as obvious?
Give yourself credibility
Engineers are like the really good looking girl at the bar. They get “hit on” all the time. They get approached all the time. I don’t know directly, but I’m guessing that gets tired fast, and cynicism is just another “you’re going to love my startup idea” away.
You know what’s refreshing to someone you’re chatting up at a bar? Interest and awareness about them. The same goes for coders. If you’re aware enough of their world, and interested enough in the detail of their skills, they will respond and, at the very least, help.
This bit I do know from personal experience. Ever since I’ve learned to code I have many more engineers happy to give me advice, guide me, correct me, and even dive into my ideas with me. It’s not easier to find the right co-founder, but that has nothing to do with expertise, and more to do with their interests, priorities and life-circumstances.
And now what?
And now, for the first time in my life, I’m in a position where I can experiment with my ideas. Earlier it cost me time and money. Now it costs me a little time, and even then less time than finding developers, negotiating scope, supervising work, reviewing work, testing work. And that time is an investment as I keep improving the skill even if the idea pans out as commercially unviable.
I’m not a great coder. I don’t think I need to be (maybe in 5 years I will revise this view). But I know enough to build my own prototypes, and understand what is involved in building a viable product. And I know enough to take a call on which bits to outsource, how to describe what I want, not get taken for a ride, assess the output, and team up with other hackers to get results. I may never be a professional developer, and that’s fine. That is not what this is about.
But I have become my own technical co-founder. There may come a day when the best use of my time really is the non-technical stuff. But that day will come once I’ve built something that’s growing. I believe I’ve increased my chances of finding that something simply because I can run many more cheap, low-stress, experiments that do not involve me spending money or begging others for help.
All this in less than 12 months. Think about it. Maybe it really is the best use of your time if you want to be a founder.
I really, truly believe your most precious resources are your time, effort and money. Of these, the single most important resource is time, because the other two can be renewed and recovered. So if you’re going to spend time on something make sure it gets you closer to this goal.
If you would like to learn more about my journey into code, check out episode 53 of the freeCodeCamp podcast, where Quincy (founder of freeCodeCamp) and I share our experiences as career changers that may help you on your journey. You can also access the podcast on iTunes, Stitcher, and Spotify.
I will also hold a few AMAs and webinars in the coming months. If this is of interest to you please let me know by going here. And of course, you can also Tweet me at @ZubinPratap.