The Trouble with CTOs
The number of startups we’ve come in contact with who have a great founder (maybe even two), but no CTO (Chief Technical Officer, or your head developer) is pretty telling of the startup market right now. Finding a CTO isn’t an easy task, they are a rare breed and highly sought after. Not just any developer makes a good CTO either; the other founders have to click with them, they have to be on the same page when it comes to the company, and, unfortunately, many expect a salary from day one. This leaves founders with three options: hire a CTO (which is often out of reach for early ventures), learn a coding language and become their own CTO (which takes a tremendous amount of time and may pull a founder away from other responsibilities), or exchange a third party’s work for equity.
Sidebench has hopped on plenty of very early stage (pre-VC) ventures and became, essentially, the CTO of the company. But in doing this, we have learned a lot of best-practice tips for founders who are looking to go this route. ?While a founder won’t necessarily need to know how to code, they will be required to have some working knowledge and hunger to learn when it comes to getting their product developed.
Many founders think that it is as simple as giving away equity and coming back in 6 months to a polished product ready for the market. Unfortunately, it should be understood that they absolutely need to be involved at every stage of development, just like they would be if they had a traditional CTO. There are gametime decisions, issues that may arise, and simple ideas that need to be agreed upon before action can be taken.
Here are a few tips for founders that are looking to go this route that will help maximize the value from a development/design partner without needing to hire a CTO:
Keep in contact, but don’t be overzealous. Showing interest and knowing what stage a project is in is always a good thing; it allows a founder to make quick decisions and ensure that the project is moving in the right direction. However, it should also be noted that running a company successfully very much relies on relationships with other people. While you may be technically paying, and therefore in charge, of the project and the people running it, it is often a bad idea to call or check in too often. It can make people feel like you are hawking over them, and this can make for a bad working environment.
Take an interest in the technologies used and understand the design process flow. This is important for more than the simple reason of knowing what your product is built with. If you understand the different types of logic behind your app or website, you can know what is easily changeable and what is absolutely impossible to change without completely recreating the foundation or adding on more cost. A good example of this is something as simple as line-break formatting in a sign up form for a website we recently worked on. While we didn’t add any cost, it did take an extra few hours of work with our development team to allow for WYSIWYG formatting, something that wasn’t originally in the plan but became clear was necessary once the project started moving. Understanding and taking an interest in your project is key to solving any issues of the ‘unknown unknown’ category once they become known. This is especially true if you are offshoring your project, as overseas teams that don’t ever make in-person contact with you may very well skip over issues that should be addressed.
MVP or Full Product? If you are giving away equity for the creation of your product, it is easy to think “why not just go and make the whole thing?” Well, this might not be the best thing to do. Firstly, an MVP takes a lot less time to make than a full product in almost every case. This means a full product takes longer to get to market and is more expensive to make (read: costs more equity). Secondly, you most likely have a great idea that people believe in if you are able to get a discount on development work in return for equity…but that doesn’t mean it’s a certainty that your product will do well. The MVP is for testing the market and gaining traction before going on to raise venture capital. In another article, we explain why it is best to fail early and often, so from that standpoint, waiting an extra 6+ months to get your full product developed prolongs the process unnecessarily. Finally, if you go for the whole product to be made immediately, you are essentially stuck with the first team you pick. This might work out well, or it might not. To mitigate your risk of choosing a bad team, having them just make the MVP means you’re only on the hook for a short period of time. If you like the team and they performed well, you can always hire them again for the full product after you raise funding.
All of the above are good things to keep in mind when looking for an external CTO or development partner. Sidebench sees a lot of founders make mistakes when picking their development partners because they haven’t thought through the process and the requirements. Once you hand off your development to a partner, don’t think you’re ready to move on without continuing to work with said partner. Be prepared to meet often, have tasks that need to be completed on schedule, and be in fairly constant contact with the dev team if you want your product to be made to your standards.