CTO != Coder

I have to straighten this out. I see it again and again (and again). I see it on Angel List job postings. I hear it at networking events. I see it on twitter and startup web sites, conferences, everywhere non-technical founders can be, well, found. This attitude is pervasive in early startups: “I need a CTO to build my MVP/Prototype/Product.” Not to plan it, not to manage it, not to oversee it, but to actually code it. I will say this once and then I will explain:

No. You. Don’t.

What you need is a software engineer to build it. And guess what: you also need a CTO to plan it, oversee it and manage it.

What you need to understand is not so much that these are different skill sets (though I would argue and awesome coder is a completely different animal than an awesome CTO) — but these are different mind sets. And therein lies the rub.


Let’s rewind and look at what, exactly, an early stage startup needs as a CTO — basically a Product Manager:

  • Someone, most importantly, to disseminate the idea into a product.
  • Someone who can make a product roadmap and technical strategy and plan that everyone can rely on from the CEO to investors to sales to coders.
  • Someone who can wireframe or even mock up potential interfaces, or map out a user experience path for critical application flows like signups.
  • Someone who can come up with innovative solutions to solve problems — business and user and other — and determine how technology and UI/UX can overcome them.
  • Someone who can defend the technical team so they aren’t hijacked by marketing and sales (trust me, this happens a lot)…but also someone who recognizes when to make sales/marketing objectives important.
  • Someone who is emotionally intelligent.
  • Someone who can hire and inspire a team of developer and designers.
  • Someone who can communicate technical concepts to non-technical people — and communicate business objectives to technical people.
  • Someone who can see the app from the user perspective more than from the coding perspective.
  • Someone who is always looking down the road to the next release, the next investment round, the next growth curve.
  • Someone who is thinking about Key Performance Indicators (KPIs), gathering analytics and utilizing analytics to make a better product.
  • Someone who can think about managing DevOps (if necessary), performance, risk, backups.

You can see that almost all of these involve seeing the company and application from the user and business perspective. The others generally involve foreseeing technical issues. This is a forward-looking position. The person doing this should be smart, technical, innovative, emotionally intelligent, multi-tasking, and managerial. Is this the same as the Lead Developer? Let’s have a look.

The Lead Developer

This is your gal (or guy) who is going to build your MVP/Prototype/Product. Let’s see what we want from them:

  • Someone who can write code. Lots and lots of code. KLOCs. MLOCs. GLOCs. And write it fast.
  • Someone who can stick with one aspect of the application and build it until it is rock solid, and then move onto the next.
  • Someone who is up-to-date with the latest changes in the programming language(s) and platform(s) being used by the app so they aren’t taken by surprise.
  • Someone who has a rich resource of libraries that they have used or contributed to that they can draw from to shorten dev time.
  • Someone who can sit in front of a computer for hours on end and loves it.
  • Someone who is detail-oriented and can take a user story and dissect it into a series of programming tasks.
  • Someone who doesn’t mind testing and re-doing the same task over and over again with slightly different variables to ensure the app is bullet proof.
  • Someone whose head is completely immersed in the app and it’s functioning.
  • Someone who is focused on making the piece of software they are currently working on totally awesome.

Does this sound like the same person? No way.

The Upshot

I’m not saying that anyone who writes code can’t be a CTO. What I am saying is that whoever is writing the app has a single objective: what they are currently working on. The CTO has a lot of objectives, and most of them don’t involve the account page — or whatever feature is currently being built.

Having been a coding CTO, I can tell you there is nothing you want to discuss less when you are on the verge of a release (read: working your ass off and stressing because there are so many things still to be done, so many bugs, and you still haven’t figured out how to get XXX to work…etc.) than what should be included in version 2.0. But that is probably EXACTLY when you need to be discussing what will be in 2.0. Programmers focus on getting THIS built, CTOs focus on making the business work through technology.

And then there is the matter of wireframes, product roadmaps, emotional intelligence, management, etc. Simply put these are just different skills from programming, or more importantly, a different mind set from getting the app built, getting the code done. The long view vs. the short view.

So What Should You Do?

I understand a startup can’t necessarily afford to hire (or give founder’s equity) to these two people. But there are a lot of options. The main thing is to plan first. Get the roadmap and tech strategy down using an advisor or consultant (it’s worth the cost), then get your coder. Or hire a part-time CTO — this is not a bad option. Or get the CTO and outsource the coding. I have had great luck working with developers in South America — you can find great ones for less than $5k/mo. — and if you have a good CTO, they can manage them.

Whatever you do, good luck!

Originally published on LinkedIn Pulse.