I’ve always been passionate about technology, but I’ve never been a student of programming. I took a course here and there—middle school, high school, the required junk in college. I’m still shaky on the roots, the bits and bytes that make up the cred of any programmer with a degree. I’ve forgotten more about coding than I know today, and I’ve never been that concerned about keeping my skills sharp. 

 
But I’ve built a bunch of tech. 
 
Last week I had a meeting with a company who was looking to bring Automated Insights technology to one of its customers. After some discovery, we realized that what we wanted to do would essentially be enhancing the Nth generation of a system I built for that customer at the turn of the century. 
 
Crap, I’m old. 
 
I built that system singlehandedly, for the first startup I ever worked for. And I built it six months after realizing that computers could make me a lot more money than my degree could. I learned how to program in my spare time. 
 
I’m probably of the first generation to realize that technology will always evolve faster than those who program it. That was a while ago, and today there are two types of coders. 
The purists—those who make the tech that the rest of us call tech to use to make other useful technical stuff—and, well, the other group is the rest of us. 
 
I get the purists. I respect them to no end. At some point it’s like knowing everything there is to know about how an automobile engine works. That knowledge is necessary, but if you don’t have the computer that plugs in and tells you what’s wrong with the car, you’re kind of behind the curve. 
 
I can go online and figure out how to change a fan belt. 
 
The purists will always tell you that if you really want to make a technical product, you’ll need highly experienced, highly skilled, highly expensive programmers who not only know how a database call is sent from a mobile app to a highly secured cloud database, but how to do it without producing some kind of memory leak. 
 
Or oil leak. Like I said, I’ve forgotten a lot. 
 
My point is, I get it. The technical guts behind something like Facebook requires teams of genius coders breaking new ground and defying the laws of physics to keep your baby pictures showing up on Grandma’s 4S. Remember when Twitter never worked half the time? 
 
If you’re going to build the next Facebook (pro tip: Don’t try to build the next Facebook), you’ll eventually face the technology conundrum of spending a lot of money or doing a lot of work. And if you’re early, it’s always better to do a lot of work. 
 
Should you do that work yourself? That depends. 
 
For a long time, entrepreneurs and those close to entrepreneurs have beaten the drum of “Learn to Code”, myself included. Hell, I learned to code. It’s not that hard, and if you’re motivated, it’s no different than learning to change a fan belt, just over and over again with a lot of acronyms. 
 
The drum-beating has died down some, for a lot of reasons. 
 
Partly because it was just a convenient thing to say—hey you, go learn to code. I’ll now completely contradict myself and tell you how NOT EASY it is to ACTUALLY code. You’ve got to be committed to get past those specific things that are going to kill your product. You’ll be staying up nights, getting that weird staredown sickness when you focus on the same set of lines for hours, and your butt will fall asleep. Not sexy at all. 
 
Anyway, it became a faux-mentor easy answer. Cost of technical talent got you down? Learn to code! 
 
Another reason is because a lot of people sorta-kinda learned to code and a lot of crap hit the system. That phenomenon—and who didn’t see that coming—led me to conclude that you should only learn to code to work on something you’re totally and completely passionate about. This is not a new trend. In the history of computer science, there have been a ton of programmers (purists) who C-plussed their way to a degree, went to work to land a salary, and ultimately created nothing but technical debt. I’ve worked with them. See Office Space. 
 
The other reason you don’t hear “Learn to Code” as often as you used to, at least around here, is that the region has moved up a notch on the startup scale. We still have a huge top of funnel, and it’s growing at about the same clip, but now there are also a good number of startups at the next level. This makes sense, as we’ve had years and years of NC IDEA, TSF, HQ, Groundwork, American Underground and at least a dozen other programs dedicated to get startups from Minimum Viable Product to Totally Viable Product. 
 
And if the new reality is Totally Viable Product, that takes skills that only time on the job is going to be able to produce. 
 
You need vision. Someone else needs to turn that vision into bits and bytes. 
 
Take all this into account, and the Minimum Viable Coding Skills needed to create a Totally Viable Product are no longer the exit level of your basic coding academy. No knock on code schools, as those of us in funded startups are circling their graduating classes like hawks. Those skills are a start. A great start. 
 
So where does the early, non-technical, shallow-pocketed founder turn? Outsourcing is damn expensive, and your average friends-and-family founder is usually forced to go offshore. Again, not a bad idea per se, but it’s not a permanent solution. 
 
A lot of the startups I either work with or run into are at this point right now. They need a CTO, and not a butts-in-seats, code-review, Agile Scrum Master CTO, but a hands on, this needs to do something never done before and it needs to be cheap and bulletproof CTO (oh, and we have no infrastructure and a lot of technical debt, is that cool?). 
 
Purists, unless they’re insane, are not going to do this. Unless they’re completely sold into your idea. At which point
, you’re going to sacrifice a lot of equity. 
 
So you’ve got to turn the experience setting down a little. And that begs the question, what exactly are you looking for in a less-experienced coder? 
 
I’m going to answer with one simple word: Passion. 
 
Your CTO will have to have a minimum level of skills and experience, of course, but the differentiating factor between all those coders with their various certificates and projects and repositories and months of experience either on their own fledgling thing or someone else’s fledgling thing—all of that is going to blur. 
 
You want someone who cares about the firing of the rocket as much as you do. Someone who will stay up all night and not even think about the lack of sleep or his or her tingling butt. Someone who will pay as much attention to detail as you would, because that person cares about the problem you’re trying to solve, believes in your solution and sees parts of your vision that no one else sees. 
 
You want someone who will learn how to change the fan belt, rebuild the transmission, fine tune the acceleration, and hell, maybe even wash it and wax it on the weekends. 
 
That person is not looking to get rich, or be the Woz to your Jobs. They want to build the thing you want to build. And they want to build it bad. 
 
The good news is you can usually spot this person from a mile away, without any formal interview questions, deep dives into a LinkedIn profile or GitHub account, or reference checks from that one guy who hired them for 50% of their Uber for Tesla app. 
 
The bad news is, they need to have something to be fired up about, and this isn’t going to come from your website, your demo, your wireframes, or your pitch. You’re going to have to spend time outlining your vision in the most easily-graspable manner. Then you’re going to have to spend time getting them to grasp that first shred so they can walk away and start churning on it. 

If your idea is worthy, and if you’re lucky, that person might even call you back before you call them. 
 
Then you’ve got something more than a partner. You’ve got yourself a CTO.