Back To Blog
Hiring Technical When You’re Non-Technical
05.27.11

This is going to be a work in progress posting because I myself am trying to figure out the best way to do this -- but this issue has come up a number of times in recent weeks so I wanted to write more on it.

Very simplistically, there is a division in terms of the startups I know. Especially because I'm based out of L.A. and not in Silicon Valley, most of the startups I know are ones where the founders are business people and not engineers/developers themselves. Thus, they need to hire technical talent. The other group are obviously the founder/co-founders who as a core are technical enough to pretty much launch a product on their own. Here's one more plea for undergrads trying to figure out what to major in. Major in Computer Science. If I could go back in time, I would major in CS (I was an Econ major.) I'm confounded when I meet CS folks who worry about how valued their talents might be in the future. I think this will be the most lucrative degree in the future and, especially for startups, if you're good -- it allows the, "If I can think it, I can build it." How many other industries is that really feasible in?

So what do you do if you're non-technical and have an idea for a startup? Here are the broad areas I'll cover off:

1. Job Descriptions
This is the best set of job descriptions I've seen [link]. It's Asana's -- they're co-founded by Dustin Moskovitz (one of the co-founders of Facebook) and backed by Benchmark. Here are some of the big keys about this job description that I like:
a) Look at the general tenor and tone of the job descriptions. It's one of respect and ambition. It's respect for another person in terms of the value they bring to a company and ambition that you'll be working on something great. Asana, by the way (as far as I can tell) -- does work around group collaboration. I think it's cool but I suspect a lot of people might think that's boring. But they make it sound awesome. If you're going to be working 40-80 hours/week somewhere -- wouldn't you rather be at a place that wants to go places than just cashing a paycheck?

I'm not saying that other job descriptions are disrespectful -- but a lot of times they almost have a "here it is" type of mentality. The best people are going to need to be wooed. So woo them -- and start with your job description.

b) Recruit not filter. Most job descriptions try to filter people up front (e.g. you need X years of experience.) Is that really the best way to filter people? Self-selection? Besides, if you have a great coder who didn't go to college -- does a degree matter? Focus on the type of person you want working for your company, recruit simultaneously in the words you write, and let you and your team screen for technical ability. Don't depend on a job description to do it because it won't work.

c) Look at the perks. "Small company with respectful, rational, chill peers." -- that's the first bullet point. It's all about culture. Doesn't it seem like you know exactly what type of company you at least expect it would be if you go work there? The perks itself show a high degree of thought in terms of what benefits people care about too. This is all about thinking, "What type of company would a great employee want to work at?"

2. Recruiting
"Do you know someone that might be a good CTO / tech lead / engineer for my startup?" This is the #2 question I get asked -- right after, "What do you think of my idea / demo / product?" Here's how recruiting works. It's work. That's it. It's hard hiring people and especially hard hiring technical talent because the demand is so high. So what do you do? Nothing compares to doing everything and getting out there. Are there CS universities nearby? Drop by there. Put up fliers. Meet students. Meet professors. Put the word out. Are there companies you particularly respect? Find their engineers on LinkedIn and see if they'll have coffee with you. Even if they're not interested, they'll know people of similar caliber. Do you know of good technical recruiters? Engage them. Do you have alumni networks (either from school or work) that you can tap? Try that. Are there local tech meetups you can go to? Meeting someone in person is so much more effective than just sending off emails. There really isn't one way -- but the biggest thing about this, I think, is that the people who know engineers are... other engineers. Makes sense right? This is true in every industry. Steve Nash knows Dirk Nowitzki. Lloyd Blankfein knows Dave Einhorn. Nancy Pelosi knows Harry Reid. Engineers know other engineers -- especially those angling to make a change. Making inroads in an industry where you don't know people sucks -- so get started and get started by going to things in person.

3. I need a CTO! ... Right?
I'm not a fan of this approach -- and this is a heavily favored approach of the startups I meet with whose core is business people. My (strong) preference is to hire more junior folks. Ideally a tech lead and then one or two junior engineers (even right out of college is fine.) Let the tech lead grow into the role. As my friend said earlier today, "If you're over 30, you're probably not going to be willing to work the 60+ hours a week that a startup demands." Get a CTO when you're really big and that person is managing a big team (not coding). Not when you're starting out. This way is also much cheaper and easier. The less experienced folks will be hungry to grow into the more senior roles and that's what you want.

4. Interviewing
I get asked to interview CTO candidates. I'm not super comfortable with this. Why? I don't have a CS degree! I can interview them as a product screen -- but to tell whether or not they have the goods technically? I'll admit, I'm not a terrible option, but I'd rather have a rock solid engineer do this. If I did one of these interviews, I feel like the way I do interviews -- I would certainly gleam quite a bit of information about their approach to building products which would be valuable. But not as valuable as if I was interviewing pretty much any other function within a company.

Here's how I've approached this with one startup. I found a friend of mine (ex-Google engineer) who I think is just a great engineer -- the best engineer I've ever worked with. He's looking for some new challenges so he's going to help out on this front and vet some candidates that have made it this far. He's the technical screen. Find the equivalent. How do you find someone to help do this? Same as #2 - go out there and make some friends :) Startups are fun and exciting and there are a lot of great engineers who I'm sure want to get more involved with startups even if they're not ready to jump to one.

Here's the last thing I would throw out -- engineers are regular people. They do extraordinary things but they're just like the rest of us when it comes to work -- they want to work on cool stuff and be respected. I've had startups that literally have said to me, "We just need a couple of code monkeys." Really? Good luck hiring engineers with that attitude. I've seen (tech) startups that plan to outsource everything to India or have close to $0 allocated to product development for future years. The rest of the money they're planning on raising? To sales and marketing. Does that sound like a company that's going to be able to attract great technical talent?

I come from a world where product and engineering dominate. Why? That's the core of what you're creating in a tech startup. Delivering value to a customer via the product. These are the people who create the product. All the other functions are important -- really important. But the core part of what your customers interact with is **what they interact with** -- and that's built by the engineering team. So when I say they want to work on cool stuff and respect -- it's coming from that place. A place where the core part of your company is going to be built by these people because you can't build it yourself -- you need them and they're valuable. So valuable that they're difficult to find and recruit. So recruit with that mindset and you'll be just fine.

Comments