Startup founders have this notion that having a technical co-founder will fill all the “tech” voids in their project, and they’re not wrong. Their mistake is how they think we do it. CEOs often believe that, when it comes to tech, a CTO has all the answers -Spoiler alert- we don’t. The trick is we have some answers and we know how to get the rest. In early-stage startups, you can also emulate this without a CTO, let’s see how.

This a sneak peek of my upcoming book, and the second in a four-article series on how to properly fulfill the roles of a startup CTO. In this series we break down what a CTO actually does, and we guide you through taking over and delegating those tasks to make it work when you don’t have one. If you’re learning how to build a startup without a CTO, you should also read part 1: Being a good product manager in your startup.

A CTO helps you start off with right foot

Or in this case the right technologies. Building a startup is not usually described as easy, and at the beginning there are many decisions to be made. Whatever you decide on this stage will affect the future of your project, and it’s up to you to minimize the negatives. That’s a tall order for someone without a technical background, right?

If you’re up to the challenge, I like you already, but we all need a bit of help from time to time. A CTO is a Chief Technology Officer, and their job is to understand the product’s technical side and provide advice on ways to improve and develop it. So in other words, a CTO’s role is to help founders make the right technical decisions for the company.

One of the most important decisions a Startup CEO has to make is choosing the best technologies for their startup, and yes I’ve already created an entire course on that topic in case you want to check it out. Making the wrong call at this stage might mean anything from getting stuck later on when developing more complex features, not being able to scale, having to invest way too much to compensate for the lack of compatibility between the tool and the task (like eating soup with a fork), to having to redevelop everything from scratch at a point where you should be focusing on growth.

So there’s a potential headache coming for you if you’re not seeking the right content, the right resources and the right advice to help you avoid the pain.

The importance of being – technically – audited

No, I’m not talking about taxes or plays, I’m talking about code, more specifically evaluating code infrastructure and documenting its existing architecture.

When we talk about Startup MVPs, we are usually referring to a product developed mostly from scratch by a somewhat inexperienced developer, or we are referring to bits and pieces of custom code interconnected with existing tools (my personal recommendation). Either way, chances are that what you have so far may need some improvement, so an audit is vital to move forwards and onto a specific action plan.

That’s one of the situations where a CTO is extremely useful. Technical audits are necessary checks along the way to ensure you are going in the right direction. Since early stage startups don’t have the budget or the round-the-clock need for a CTO, they usually don’t have the luxury of regular audits and guidance throughout development. This means that when they do actually get “the big audit”, they might end up having to redevelop some things from scratch.

That’s definitely not the best-case scenario, but startups rarely are. The idea of an audit is to determine if you can actually rely on what you’ve developed in the long run. My extensive experience as a startup CTO and tech consultant has taught me that doing this 2 years, or even a year into development it’s too late. So to replace the role of a CTO also means getting third party experts to regularly audit your code.

A CTO’s tech expertise

So what does a CTO actually do in this scenario? A general CTO is rarely an expert in a specific technology, although they may be the ones checking up on general development standard (more on that in the next article), they won’t usually be the one carrying out an audit on a specific technology.

We may not be punctual experts, but we are very experienced at combining multiple technologies in many different projects. A tech jack of all trades, if you will. We’re familiar with the realm of possibilities for each type of technology, and we can identify opportunities to combine them and improve your product. Not only that, but we know how to recognize the people who actually know the specifics of these programming options and how to implement them.

Surround yourself with expert advice

To properly fulfil the CTO’s Tech expert role, you need to surround yourself with all the right people. This means loads and loads of networking. Identify and recognize those key people, that not only are experts in their technical fields, but are also in line with your work ethic, people you can trust. The best way to get unbiased advice is to get people that have nothing to earn from your imminent success or failure.

I’ve personally made this a lot easier to access on my coaching program, where I have a pool of experts ready for startup founders to consult when they need to. This is of course much more convenient, but you can try to do this on your own. Incubators and accelerators are a great way to meet new people, do your research and identify not only those labeling themselves as experts but those whose testimonial and peers actually corroborate it.

You might not be able to afford a CTO, but I’m sure you can afford to invest in a course, a couple hours consulting with a VR expert, or a coaching program like the one My CTO Friend offers. The point is recognizing the resulting empty spaces from a lack of CTO, and taking the necessary steps to fill them properly. Not doing so hurts your chances of succeeding in the Startup world, but if you do the best with what you have you’ll learn so much along the way.

Next article in the series will cover how to properly fulfil the CTO role of the IT Manager.


Submit a Comment

Your email address will not be published.