Why Your Startup Doesn't Need a CTO

Why Your Startup Doesn't Need a CTO

Yes, that’s what we’re saying. Your startup really doesn’t need a CTO. We think a dedicated Product Owner + team will do a much better job, and we’ll tell you why. But we’re also aware of your concerns, so let’s go through them one by one.

I’ve come up with such an unique idea that there’s no way I’ll let anyone outside of my company see it. I need a CTO close to me!

So, you hire a CTO and keep the devs sealed in a bunker. Two problems though: in the age of the Internet, there’s no guarantee even those sealed-in employees won’t leak anything. Also, not trusting anyone means wasting money. Even a metaphorical bunker generates unnecessary costs. Alternately, you can find a reliable company you can trust. They’ll understand your worries and prepare an NDA so you can sleep soundly knowing your ideas are safe. They’re even likely to take your ideas further if you let them understand the ins and outs of it and the motivation behind it. Seems like a better option for product development.

My product is very complicated and there’s niche technology involved.

Naturally, you want to have someone with strategic knowledge on board – and preferably in close contact. But it doesn’t have to be a CTO in the traditional sense. Having a domain expert combined with programming services found elsewhere might just be the right setup. For technical expertise, seek an architect on the vendor’s side who’ll know the developers very well and will be working with them rather than against them.

The CTO is a co-founder and a major shareholder in the company.

Good! That’s an option that can work. He or she’s someone you know and trust. Someone not worried about their position. S/he’ll even be happy with a hired programming team willing to question decisions and keep him on their toes.

I need a permanent CTO because I’m worried about locking in with a vendor.

Well, if you have a CTO they can just take another vendor on board. But wouldn’t it be a better solution to just have a trustworthy team in the first place?

The CTO would also do a programmer’s job – two birds with one stone!

Many entrepreneurs expect the CTO to also do a programmer’s job aside from being the supervisor of the hired team. If the CTO is a decent programmer, it’s likely they’ll want to show they can code and deliver features too. The CTO might want to prove they’re a better coder than the rest of the team.

By doing code reviews too extensively, the CTO might begin correcting the output of the team, and start interfering with the process. They could be right in doing so, if they’re a really good developer (though that’s not a given). But if they’re not, you might be throwing away decent code because you’ve given the CTO the last say in such matters. And coding approach arguments are one of the last things you’ll want to be having when you’re set on growth.

Alright, I get it. I still need a CTO to supervise the team.

That’s a common opinion. OK, so you delegate the task of supervising the team to the CTO. S/he’s probably got a subjective vision for the technological solution for your product. Doesn’t seem that bad yet. But again: they often feel they need to prove they’re adding value to the process. That means they might question the technologies proposed by the team just for the sake of proving they should stay on the payroll.
Worst case scenario, they can sabotage the work of a team, since they’re the link between you and the team. Also, a CTO is normally a high-cost employee. This means there’s less money to spend on developers and s/he’s competing for the same budget.

Consider this: you delegate your product development to a Product Owner instead of a CTO. What now?

  1. That person knows what you and the investors need, but the how is left to the technical pros on your team.
  2. The PO will lead the development of the product and will implement its strategic vision. It’s a person fully vested in the product – one that has time for the dev team, but isn’t likely to get in their way.
  3. There’s no CTO, and you don’t lead the dev team yourself. Instead, you get to focus on the business side of your startup, and stop worrying that you’re not a technical ace, because you don’t have to be one.
  4. We’re not even mentioning the financial aspect of this approach. This is a win-win scenario.

Does this work in practice? Yes, it’s a system that we’ve implemented with a number of startup CEOs in various verticals. Drop us a message if you’d like to know how.