Are you ready to recruit a technical co-founder for your startup idea?
“How do I recruit a technical cofounder?” If I ask a group of non-technical startup founders, that’s easily their most commonly-asked question.
My usual answer is, “How do you know that now is is the right time to recruit a technical cofounder?”
Because if you are technical, or already know someone who wants to collaborate with you on your startup, the right time is now. But for everyone else, the right time may be later. For most of the startup industry them’s fighting words, so I better take some time out to explain my reasoning before the mob arrives with the pitchforks and flaming torches.
Admit you have no way of judging a good tech cofounder
Finding a great tech cofounder can be so hard it feels almost impossible to a non-technical startup founder. For starters, they’re just not a very abundant commodity and probably never will be. Next, it’s important to admit that for most of us, trying to tell a great one from a bad one is like trying to choose your own neurosurgeon: for most of us, what a software engineer is doing while they’re coding is as unknowable to us as what a neurosurgeon does — we’re effectively unconscious for the whole experience. We have to wait and see if our arms and legs still work when it’s all over.
Engineers’ brains are wired to answer “yes” to the question, “can you build/improve/fix that?” and they will consciously or unconsciously answer that question with a whole wad of mental fine print if necessary which they may not always disclose until after you’ve decided to work with them. Some of that fine print may be along the lines of “As soon as I teach myself how to do it,” or “As long as I’m the one who defines what ‘improve’ means,” or “As long as I can take as long as I need to do this.”
But to get a great tech cofounder on board without paying them a big salary you can’t afford, the established wisdom is you have to offer them a big chunk of equity in your company.
So if you continue down this path you may be giving a big chunk of your business to a new cofounder without knowing for sure if they can do what they say they can do. And if this ‘operation’ goes off the rails it’s not like you can snap out of anaesthesia and finish the surgery yourself. You’re locked in. Hopefully your arms and legs will still work.
If you’re going to make a bad choice, can you postpone that choice?
Consider the possibility you may not need a tech cofounder yet. Maybe you just need a prototype or Minimum Viable Product (MVP) to get started testing whether your startup idea may be a viable business. Consider that you may not need to surrender 50% of your equity to a CTO to get that done. Maybe all you need is a software developer.
Yes, using BlueChilli’s prototype development and validation services is one way to outsource the development of a prototype or MVP. I’d humbly suggest it’s an excellent way to do so. But alternatively you could offshore it, take it to a digital agency or employ some freelancers. If you’ve always fancied learning some coding there are some great online schools and General Assembly runs some great training courses that will help you pull your own prototype together.
Some advice from an experienced software developer can be useful to help you scope and cost out your prototype, and may help you understand whether your central idea is technically feasible, but much of the work of building a basic prototype isn’t rocket science, and compensating a rocket scientist to do it, whether with cash or equity, may not be necessary.
Recommended reading: Whartonite Seeks Code Monkey (a collection of recruitment ads from founders who aren’t ready to recruit a CTO yet)
The rise of the technical founder
If perhaps you don’t always need a technical cofounder at the beginning of your startup, why does most of the industry believe you do? I believe the answer lies in the history of our industry’s spiritual home, Silicon Valley.
The whole Silicon Valley startup economy grew up around the commercialisation of great ideas being created by hardware (and later software) engineers being churned out of great engineering schools in large numbers after World War II. The successful technical founders of one company would exit from their venture and then use their new wealth to invest in a new generation of engineering talent.
When one generation of engineers invests mainly in a next generation of engineers, the whole ecosystem believes it’s necessary to start with a great engineer as an equal cofounder and begins looking for great engineers to build a startup on, instead of building great startups, and then finding great engineers to take them to the next level.
So why great engineers, rather than just any-young-engineer? Well, my theory is: in an environment with an abundance of engineers, the competitive advantage goes to those who have the best. And in the early days of software and hardware, everything was bespoke, like a coach-built vintage car, and you needed considerable engineering skills in the founding team to build something as complex as a startup at all, much less an awesome startup.
The rise of off-the-shelf
When I joined my first few startups in the mid-1990s, internet software development was hard because there was almost nothing you could use that was free, almost nothing that would integrate with anything else, and almost nothing that anybody else could tell you about how to write your own. I was an early hire at Yahoo! and our developers benefited from running Apache and MySQL in the FreeBSD version of UNIX to save money and time, but almost everything else they had to code themselves. If you needed a content management system, you had to write your own. If you needed an ad-serving and reporting platform, you had to write your own. Ditto all the components of user registration and personalisation, ecommerce… it all had to be written from scratch, or we would have to acquire another startup that had just written one from scratch. And because nearly everybody coded for their own systems, almost nothing was interoperable.
And that was just the software. There was no elastic cloud hosting in those days! Not only did you need to monitor, patch and update your own server software, you also had to install and run it on server hardware that you had to install yourself in the premises of your hosting provider. If a drive failed and took part of your platform down with it, the pager by your nightstand went off in the middle of the night, and you got out of bed and went to the hosting provider with a replacement drive, saying hi to the guys from the other startups you’d pass on your way in or out of the building at 3am.
All of which is a long-winded way of saying: in the olden days you needed rocket scientists because if you were going to achieve orbit, you had to build everything yourself, right down to digging the foundations for the launchpad and pouring the concrete.
These days, your engineers should know which way to connect the refuelling hose connectors, how to spin up a new copy of the guidance systems, and which control operates the windscreen defrost setting, but having a guy who knows how to build an actual rocketship from scratch on the team is probably not always necessary unless your startup absolutely can’t launch without a revolutionary new hyperspace drive upon which the whole venture rests.
These days, things are very different. A developer will commonly straddle some back-end and front-end skills, maybe even dabble in some devops or security, because they don’t need to know how to write their own load-balancer or CMS anymore. There are still plenty of traps for the ignorant or overly-optimistic, but you can get 10x further with half the dev skills today. Many new startup ideas can be validated with simple off-the-shelf components that will serve a few thousand customers a day. Which might be enough to show investors how you can earn more from a customer than it cost you to acquire them from Facebook or AdWords.
But how far will I get with a prototype or MVP?
You’d be surprised how far you can get.
Yes it might get sketchy at times, and you might need to pull a few late nighters. Another story from my early days: for a long time after we launched Yahoo! Australia & NZ (I can’t remember exactly but my best guess would be at least a year, maybe two) our platform was such an MVP I had to hand-edit the HTML of the homepage of Yahoo! Australia & NZ every time it needed to be updated with a link to a big news story, a new service we’d launched, or to replace one advertisement with another. The ads needed to be manually changed over on the stroke of midnight, every Sunday night. Yeah, that was about as much fun as it sounds.
Sometimes, I broke important parts of Yahoo! by mistake. Sometimes before remembering to make a backup copy of what I was editing.
Yet we booked a couple of million dollars in advertising revenue each year. We grew our team from two to four to 150-something. We learned fast and I tried not to make the same mistake twice but that didn’t make very much difference actually; what really mattered was providing an awesome solution (measurable online advertising) to a very big problem (brands trying to reduce the cost of acquiring customers). Our clumsy, slow, slightly unreliable MVP was enough to get us going.
Your clumsy, unreliable, partly-manual MVP could be enough to get you going too, if what you’re doing is providing an awesome solution to a very big problem. And while a rocket scientist of a technical cofounder can definitely help you identify that very big problem and awesome solution, these people don’t grow on trees. And they don’t come cheap.
But what if a VC says we need a CTO/need to own our own tech IP?
That’s OK. When a VC gives you any advice, it’s not gospel; it doesn’t mean “this is the one true way for all startups to succeed”. It only means, “for me to invest in you, I would need your startup to fit our template”.
All venture capitalists try to practice what they call “pattern recognition” — trying to focus on investment deals that resemble previous investments which were successful. It’s an understandable reaction to the huge volume of potential investments a VC is asked to consider each year but there are lots of problems with investing that way, because it acts to blind the VC to potentially successful investments that don’t fit the pattern, such as startups founded by female, non-anglo, non-Stanford/MIT, and non-technical founders.
If a VC says you don’t fit their template and you believe you do, argue your case. But if you don’t fit their template, you won’t get a term sheet from them, so move along. There are always other investors, some with different templates, some with no template at all.
How to recruit a great tech cofounder, if now is the time
You’ve got enough traction from your MVP to raise some investment capital at a good valuation, or to use revenue for salaries, and now you think it’s time to recruit that great tech cofounders, so what do you do? Well, the best news is your startup is worth a lot more now, which means you should have to offer less equity to a tech cofounder to join, which means: you retain more yourself.
Chances are, through the process of building an MVP, you know a lot more than you did at the beginning about how to assess engineers, how to relate to them, how to scope work and what your tech platform needs to include. You might have met some potential tech cofounders as freelancers or team members in the team that have helped you build your MVP.
They are probably the most likely category of employee in the community to already be doing something rewarding, professionally and financially. So it’s usually no good just offering equity or cash. You need non-fiscal motivation.
One kind is a personal relationship — our community sometimes makes the mistake of thinking you have to be an asshole to be a great CEO. In fact, being great at friendships is probably the most important inherent trait in a potential CEO.
People focus on Steve Jobs the asshole but Woz created the products Apple needed because Steve was his best friend, not for the money. Steve was his friend because Steve helped him relate to the world, helped Woz create a work environment and a social circle that validated who Woz is, which supported his creativity and facilitated his productivity.
So become a great friend of a talented engineer who aspires to be a tech cofounder.
Engineers are wired differently to the rest of us, so it might take a bit of work on your part to learn about their interests, how they like to relate, what they pay respect to and who they aspire to be, but it’s worth the investment. Help them with the things they find hard to do well in their life. And then maybe you can persuade them to dump their job and join you.
In the short-term, you need something to hook the potential tech cofounders you meet at startup meetups, right? Well, they aren’t motivated by the usual “in 50 words or less” elevator pitch.
They are more often motivated by solving what they consider to be interesting problems, and yet most elevator pitches seem to imply that all the interesting problems are solved, and that only the execution remains.
That’s all bassackwards — if you want to motivate a potential tech cofounder you need to rephrase your elevator pitch to be about the interesting problems yet to be solved: “My hypothesis is that we could really change this industry if we could just find a way to solve [interesting problem] but nobody’s solved it before because the solutions are just too hard or expensive.”
Bad potential tech cofounders will tell you they’ve already solved the problem at Startup B. Or that they already solved it working solo but aren’t interested in bringing it to market as part of a team.
Good potential tech cofounders know about Startup B but can see that there’s probably a better way, and just can’t let that interesting problem go by without wanting to do just a little work on the answer, just to prove that maybe it’s not as big or as unsolvable as you think it is. That’s a great entree into working on the problem together, and into figuring out what it might take to get them out of their current job and working on the problem full-time.
Great potential tech cofounders will tell you they have a broad understanding of how to chunk the problem up into addressable bits, and that they would really get a kick out of bringing on some less experienced engineers and working with them on knocking them all over.
Originally written by @bigyahu at www.bluechilli.com/blog
