How to Find a CTO

Ask yourself: Are you looking for a technical person or a partner to work on a project with? How is that going? Is it going well?

It’s a tough challenge to find someone to help you build your dream. That’s one of the things I discussed at a talk at Stanford’s Graduate School of Business a while back. I’ll touch on the highlights and weave in some iOS development information along the way.

The best way to find a CTO to build a kick-ass product and company is to stop wasting your time and energy trying to find a CTO.

Moving into the first step of how to find a CTO: There are only two broad categories to finding a CTO; you either hire one or become one.

We’ve already established that those looking for a CTO are not having a lot of luck, so that gives you another choice, which is either to keep doing what you’re doing, or try something else. The funny thing is that for most of you who are looking for a technical co-founder, or a CTO, you actually already have both of the skill sets that you need as a CTO.

A CTO only does two real things in terms of their responsibilities, they craft the technical vision and they build a great team. Certainly, it’s a huge bonus that a CTO is highly technical themselves and most great CTOs are. But they don’t actually do the bulk of the technical work. The reason it helps so much to be a great technical engineer as a CTO is because that helps you build a great team. You’re able to attract amazing talent if you’re respected, right? You’re seen as a visionary in the engineering world, but it is possible to build a great technical team without actually having technical chops.

So here’s my question to you guys: How many of you know someone who can:

  1. craft a strategic technical vision
  2. build a great technical team of talented engineers
  3. be deeply technical
  4. are available to work with you on your project right now?

To be honest, if you’re going to pursue option number one: hire a CTO, you’re kind of shit out of luck right now. It’s really competitive and it’s not going very well for most people trying to do it.

Step one: Stop trying to find a CTO for 30 days and find your inner CTO.

Congratulations, you’ve all just been promoted to CTO. You need to go run out and get new business cards. Seriously though, I think you’ll get a lot more respect if you attempt to be a CTO before you find one.

Step two: Employ the four D’s

Define, design, develop, and deploy. This is a methodology that I used in my first company.

The Define Step

The end goal is a one-sentence value proposition. This is the hypothesis that you’re testing as a developer. So you’re making an alarm for deep sleepers or snoozers, or a children’s’ read along book, or a stress relieving meditation app, or an app that makes shopping easier for men, right? This is some hypothesis you have that you want to test. The trap that most people fall into, even though they understand this methodology very well, is that we don’t actually fall in. We come up with a hypothesis and then we fall in love with it and we don’t iterate. We refuse to follow the process and this is one of the key lessons is that all you have to do is have faith in the process. It’s not about building your own technical skills, because you actually have the bulk of these skills already. If you can make decisions and execute them, and you can define and design – you may not be able to do the details of the development, but you’d be surprised at how much of this you can do as well, and then deploy.

The challenge is you’re all looking for CTOs, who you think can do all of these four steps. The problem is that’s not the case. You’re looking for someone who’s very deeply technical and the odds are they can only do this one step, right? So that’s why I recommend that you first become a CTO, because you actually have more of the skills you’re looking for than the person you’re looking for does. All they can do, generally, as an engineer, is the development. You need to have the technical vision. You need to build the team.

The Design Step

The deliverable at the end of the design step is a set of mock-ups and high-resolution diagrams. If you go to a talented engineer and give them high-resolution mock-ups and screenshots they can build your app in no time flat. I created an app in three hours the other day that connects people via LinkedIn. The hardest part was figuring out the LinkedIn API. That was a ton of work, but once I had the drawings and figured that piece out it was like three hours to design and develop the app, and then launch it to the App Store. The development piece is only difficult because you make it difficult, because you’re constantly redefining the app as you go along. Thus, if you use the process that we all know works you can build an app quickly with a small number of resources.

The Development Step

This step is what could use another post. How do you actually develop an app? Someone was joking with me before the talk that I should start to talk about all of the entitlements and the setup that it takes to build an iOS app. I definitely could do that. That would be incredibly boring and you probably wouldn’t walk away with anything useful.

What’s more relevant is to know that engineers can help you, but you have to be the technical visionary. Most not ready to be a CTO. What I’ve found is that if you go to a room filled with the world’s most talented young engineers and ask them how many are ready to stop what they’re doing and become a CTO, they don’t raise their hands, because a CTO is someone who generally has a ton of experience out in the real world, right? This is where your skill sets come in and compliment theirs.

So really, the challenge here is to break up the roles and responsibilities of this part of your startup, this part of your company, such that your engineers can execute on the product vision that you have.

The Deploy Step

Finally, the deploy step. This is generally the business person’s territory, right? Submitting the app to Apple, of course, that’s that engineer’s job, but pricing the app, determining whether you want to do a soft or hard launch, marketing the app, getting downloads and good reviews, appearing at the top of the App Store, designing your app in such a way that Apple will feature it, these are all things that are probably going to fall into a non-technical person’s bucket rather than the technical person’s.

Example: I wrote a post on the other day that’s been getting a lot of attention and one of the reasons is because there’s this photo of a piece of wood, which is the original palm pilot. The founder walked around for 30 days when he was thinking about the palm pilot with a piece of wood in his pocket. That’s the sort of level of market testing he was doing. He was literally walking about on street corners pulling out this block of wood and sort of fake punching in, his graffiti language that he eventually ended up creating walking around. Thus, this is the level of prototyping that you are extremely capable of doing. In fact, you’re far better at it than an engineer is, right? Because, generally, you have a bigger picture.

Of course, then there’s graphic design. There’s back-end development. There’s front-end development. There’s user testing. Monetization. Marketing. Launching. Really, this whole process is just applying design thinking to the process of making an app.

The Bottom Line:

Now that you are the CTO it’s time for you to prove something using the process that I have just laid out. After you find your inner CTO you realize that you are capable of doing 80 percent of the things I just outlined of this four D process. You then need to go prove something and this is going to allow you to bring in the technical talent you need.

Don’t get stuck. Why would an engineer, who has a million opportunities in front of him, want to join your team if you can’t move past the define stage? This is the point. Find your inner CTO. Enter this loop and start to prove something. Once you do that you’ll be able to fire yourself. You’ll be able to fire yourself, because you will have the respect and empathy of the engineers or the group that you start to build up.

You can’t get the respect and trust you need from a potential CTO without understanding their world. In conclusion, by becoming the CTO of your venture you finally have a chance at actually finding the person you’re looking for.

Do you have experience as a CTO? Tell me in the comments.