Image source: www.ethz.ch05:18 | Sep 19 , 2016 | Natalia Brzozowska -Outsource
Wait, what? Yes, that’s what we’re saying. Your startup really doesn’t need a CTO. We think a dedicated Product Owner and a remote team will do a much better job, and we’ll let you know why. But we’re also aware of your concerns. 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.
Naturally, you want to have someone with strategic knowledge on board – and preferably close to you. But it doesn’t have to be a CTO in the traditional sense. Having a domain expert combined with offshore programming services might just be the setup for you. For technical expertise seek an architect on the vendor’s side who’ll know developers very well and be working with them rather than against them.
Good! That’s an option we can see. He’s someone you know and trust. He’s also not worried about his position. He’ll even be happy with a hired programming team willing to question his decisions and keep him on his toes.
Well, if you have a CTO he 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?
Many entrepreneurs expect the CTO to also do a programmer’s job aside from being the supervisor of the hired team. If the CTOs a decent programmer himself, it’s likely he’ll want to show he can code and deliver features too. He might want to prove he’s a better coder than the rest of the team. By doing code reviews too extensively, he might begin correcting the output of the team, and start interfering with the process. He could be right in doing so, if he’s a really good developer (that’s not a given). But if he’s not, you’d 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’d want to be having when you’re set on growth.
That’s a common opinion. OK, so you delegate the task of supervising the team to the CTO. He’s probably got his subjective vision for the technological solution for your product. Doesn’t seem that bad yet. But again: he realizes he needs to prove he’s adding value to the process. That means he might question the technologies proposed by the team just for the sake of proving he should stay on the payroll. Worst case, he can sabotage the work of a team, since he’s 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 he’s competing for the same budget.
Consider this: you delegate your product development to a Product Owner instead of a CTO. That person knows what you and the investors need, but the how is left to the technical pros on your team. 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. 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. 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 an email if you’d like to discuss how this approach could work with your startup’s product development.