At Cause of a Kind, we specialize in working with non-technical founders. People with great ideas and industry expertise around the problem they are solving, but without a way to implement them. Steve Jobs had Steve Wozniak, and in order for you to to manifest your dreams, you need to find your Woz. But where to begin?
The hard part about finding the CTO for your startup is that you aren't looking for someone that is a CTO today. A CTO at a large company not only gets paid far more than you would be able to afford right now, they also more than likely have not touched code in many years (outside of some personal projects they enjoy). Steve Wozniak was not a great engineering manager when he and Steve Jobs went to found Apple. You're looking for a person that may not even realize their own potential, no less be advertising it for job searches.
You're also in a different situation. You're not partnering with your childhood friend and neighbor. There's a difference between starting a company with someone you already know and trust vs. giving equity and your hard-earned cash to someone you barely know and are ill-equipped to evaluate. How good a programmer is this person really? Will they be able to grow into a senior role as we scale? Does their personality jive with mine?
Here's a few of the things I think are important when you're in the market for a technical co-founder.
Your early technical co-founder needs to be hands-on-keyboard. This means that they likely do not have the title of CTO, VP of Engineering, or Engineering Manager right now. They aren't coming into your startup to manage a large team, produce multi-year road maps, nor construct elaborate UML and architecture diagrams. Their first job, their core responsibility on day one, is going to be working on the first version of your product.
At a large company, most people in senior leadership positions are not coding and may not have coded in quite some time. This does not mean they are not capable of the task, but they are going to be a bit rusty. Compare that to someone that's been working as an individual contributor and pushing code in the latest and greatest technology as their day job.
You may find the best person for this job isn't all that into managing people as a core responsibility. They are likely more of a visionary and are often great at working with people but may not be as interested in forming company hierarchies and management structures. This is OK! Leave that stuff for your VP of Engineering when you need one, I tend to heir on the side of a product visionary over a process manager for your technical co-founder and CTO. The operational side of things isn't needed this early in the game.
One of the hardest parts of finding your technical co-founder is you are not looking for someone that is simply good at writing and deploying code. You're looking for someone that can play multiple positions on the field with competence. They are likely passable product managers and have an eye for reasonable design. What I mean by reasonable is, if you ask them to build something, it won't come back looking like a worse version of Craigslist.
This may be the hardest part of your search but it's critical that you find someone that's more iceberg shaped in their skills depth. An iceberg shaped person will have a broad knowledge set that extends deep across many areas of software product development (some call this an M-shaped person). They may not be the best at UI design or DevOps, but they can leverage tools, libraries and best practices effectively to perform sicker than the average. Contrast this to a T-shaped person who will have equally broad knowledge, but that knowledge extends deep into one specific area. A T-shaped person can collaborate across disciplines, an iceberg shaped person can actually perform across disciplines at a high level.
A solid iceberg shaped engineer will know how to build a good user experience, but may struggle to pair fonts. They know how to deploy their code to the cloud, but are not a Kubernetes expert. They understand how to solve product problems with the lightest touch possible and see how features tie into paying users of the product itself. They can get a product deployed an into the hands of users, and those users will feel that product is professional, trustworthy, easy to use, and valuable to the problem at hand. You can now begin to learn from those users without the worry that the design or function of the software is causing your feedback loop to suffer.
I would also like to make a note to be careful not to try to find someone whose breadth and depth covers every discipline you can conceive of. It would be nice to think there's a unicorn out there that can operate at a high level everywhere from hardware engineering to typography. However this is likely too big and unrealistic of an iceberg. Where you want to sit on the spectrum of skills and the exact makeup of the skillset required is going to vary depending upon your product.
You would also be wise to not think too far into the future. For example I've seen many founders put AI and machine learning at the top of their skills needed for their technical co-founder despite them not having any users, data, nor AI supported features planned in the near future.
They have the intention of adding these things when they raise money and their product takes off so they want to make sure their co-founder is ready. But these are exactly the types of features you're going to hire experts for when you are ready. If you're at the stage where you are building a serious large language model (LLM), then you'll be looking for a machine learning expert, not a generalist.
Remember, you're technical co-founder needs to be able aid you on the march to product-market fit. When it comes to deep specialities like crypto, machine learning, augmented reality, or AI it's far more important your CTO understand how to evaluate individuals for their expertise in these areas than they themselves be able to write the code for them. Just as you will be surrounding yourself with people to fill in your weaknesses as a CEO, your CTO will have to do the same.
Unless you found someone that's independently wealthy and has a beyond uncanny passion for your idea, DO NOT ask someone to do the job for equity only. I've seen this go the wrong more times than not. The story goes like this. A founder gets a programmer they met psyched on an idea, the programmer agrees over a few beers to build the product for equity only. They rapidly get a homepage up, create a quick mockup in Figma, and maybe build out a few account creation features. Then progress stalls. Weeks and months pass by with barely any progress on the product. The founder begins to wonder what happened?
When pressed, the programmer makes excuses that different components are taking longer than expected, or they rush to push out some barely functional frontend code so you can see some progress being made. Eventually you become frustrated that this person isn't "bought in" anymore and begin looking around for someone else to finish the project.
Why does this happen? I like to call it the infatuation phase of product development. When the world is full of possibilities and the realities of laying down thousands of lines of code over hundreds of hours for a project that may go nowhere sets in. You have to remember, this idea wasn't a burning desire or problem to solve for this programmer. If they never met you, they likely wouldn't care to build this thing, ever.
Not to mention if they are building for free, they have to somehow come up with the money for their food, rent, bills, and family. So they are likely keeping their day job just like you while they get the MVP out the door. So they code all day for work only to come home and want a few hours relaxation. The reality is if you want this done in a timely fashion, it's going to be hard to find a technical co-founder that can keep up their motivation.
So while you should plan to give up some equity to this individual, you should also plan to fork over some cash as well so they can actually focus on the project and maintain motivation when the lines of code start to mount and they need to put time in the saddle.
It's important to remember your technical co-founder or CTO is going to be your peer in this. You want someone that is going to tell you the truth, always. The last thing you will want long term is someone that just executes on your every whim and desire. That's an employee that works for you, you need someone that can work with you.
This means that they will be radically candid even when it's uncomfortable. Even when you vehemently disagree with their position. I very much appreciate that my co-founder at Cause of a Kind, Justin, is honest with me always. I could not do this job if I didn't have a second brain there to challenge my assumptions, ideas, and decisions.
This is not so easy to interview for, and it's usually why it's a good idea to have a few conversations and to even work with this individual for a period of time prior to making an official offer if possible. Throw out some horrible ideas and see if they challenge you and how they do so. The dynamic of criticism between two people is hard to gauge in an interview, but ultimately it's our disagreements that define our best working relationships. One question that you should be able to have a resounding hell yes to before making your decision is "will this person tell me if I'm wrong?"
When it comes to selecting a technical co-founder, you need to resist the urge to say yes to the first person that is excited by your idea. It's easy to be flattered by someone drinking the Kool-aid you're serving up. Don't fall for this. People tend to mirror our own energy in conversation. Therefore you may find yourself dazzled by your own enthusiasm staring back at you.
This is a big decision, and this person is going to hold a significant portion of equity in your company for many years to come (even with a vesting schedule). It's ok to pass on good people, but it's not ok to pick the wrong one. So how do you slow down the process when you needed your CTO yesterday?
Starting with a fractional CTO is a great way to bridge this gap. One of the best things a fractional CTO offers you is time. The cost per hour can be higher than a full time CTO, but you'll be able to work with smaller blocks of time and this affords you freedom and time to make the right selection. The equity in your company is precious and where the true value lies. If you can buy yourself time to make this decision with a fractional CTO to get you your MVP or even version one, this will prevent you from making a bad decision out of haste.
A strong fractional CTO can also help you pick the right tools, ensure a sound architecture, help you pitch VC's, as well as help interview your early team and evaluate your permanent technical co-founder when the time comes.
Choosing a technical co-founder to go with you on this journey is one of the biggest decisions you'll make as a founder. Not all of us can rely upon a childhood friend or someone we've worked with before to build out our product. Plenty of founders have had to figure out how to get their technology built first.
Just because you don't know a software engineer right now doesn't mean you should despair. I've helped many non-technical founders get their product built and later find their technical counterpart. The great part about doing it this way is you actually have a product to measure someone's expertise on as well as to gauge their true interest in sticking with you for the long haul.