5 things I’ve learned being a CTO in startups

In the past 5 years, I have been Chief Technical Officer of two startups — one, GoCar has been acquired and one, Solved, has been discontinued — and helped many others as a technical advisor. What characterizes startups is that they have to ship a lot of results with limited resources. As CTO, your daily job is to lead the technical team, set the goals and take the right technical decisions. You are in a constant tradeoff of immediate speed VS long-term productivity.

In this article, I want to share 5 rules I follow in order to make my choices. So far, they enabled me to keep shipping while avoiding to pile up “technical debt”.

1. Dedicate yourself to the business

The goal of any startup is to build a solution which will bring value to its customers. There are chances that your business co-founder will spend most of his/her time talking to them and understanding their needs. On this basis, your co-founder will set the priorities and report what customers’ problems are. Your role will be to find out and build an outstanding product that provides a solution to them.

As a technical person, it is easy to get excited by a new technological challenge or a new service that looks promising. When it occurs to me, I ask myself this simple question: “What is the business outcome of what I am doing”. This way, I always know if I am working on the right priority or not.

At Solved, we even dedicated a weekly meeting with my business co-founder, Thomas, where we were reviewing the features to ensure they match the business priorities. At any moment, I and any member of my dev team could say why we were working on any feature.

In order to ensure I did a good job, I was asking myself: how will it delight our users? how will it help our startup to make money? or help our operations team? If you can also answer these questions for your own project, there are chances you are on the right track.

2. Optimize for speed and flexibility

In its early days, your startup’s main challenge is to find the product-market fit. That means that your product embryo might evolve in many different directions and it has to evolve fast. As you don’t know how long it will take to get traction, you have to balance short-term benefits as well as productivity in the long run.

At the code level, I found out that the best way to do that is to organize my code in small, reusable modules that I can assemble like Lego bricks. It enables to quickly change the business logic and the flows of the app. In order to maintain a clean codebase, I never hesitate to throw away features that are not needed anymore.

As an illustration, here our Trello Board at Solved, my previous startup:

At the organization level, I put in place simple processes so that everybody knows what are the priorities and who is working on what. Most of the time a simple Trello board with the main tasks will be enough. I make sure not to go into too much detail in order to leave room for discussion. Often times, the best ideas and the tiny details that make the difference will come from these discussions.

3. Choose the right tool for the right job

There has never been so many tools in a developer’s toolbox. You can choose to externalize most of your dev stacks or to develop every single tool yourself.

At the beginning of your project, one of your main challenges will be to choose your stack. New tools and technologies have probably emerged since your last project. Should you choose a stack you already know or try a new one?

I never underestimate this phase since it will influence the whole life of my startup. I’ve seen too many CTOs struggling because they chose the most “trending” tools without realizing what are the technical implications. It is not because everybody is using a tool that this tool will fit to one’s particular case. For every tool I consider, I do my best to understand what are the pros and the cons. If I only see pros, it is often a sign that I have not dug enough.

For instance, I hear many developers thrilled by the power of MongoDB. So much that they use it in all their projects without realizing that it lacks of some SQL DB features they might need (think of the work required to maintain many-to-many relationships in Mongo). After a year spent coding, they are not taking advantages of Mongo and start struggling because they do not find the features required by their project. If they had taken the time to understand the pros and cons of each solution, they would have chosen the right DBMS from day one.

In order to make the right choices, I take time to understand what are the specificities of my project and what tool will answer the best to these ones. I especially like to discuss with other people who have tried these tools.

4. Hire people who are more skilled than you

When it comes to hiring, you might be tempted to start with interns or junior developers since they are easier to recruit and are more affordable than senior programmers. However, with inexperienced recruits, you will end up spending more time training them than actually shipping code. Never forget your goal: being fast and flexible.

I have experienced that hiring senior developers bring way more value to startups. Since I do not have to train them, I have more time for my own responsibilities. Moreover, they bring their own knowledge, their own tools and can help the team to take better decisions.

I even try to hire developers that are better than me in domains I consider key for the startup. Since I do not know everything on every subject, I am delighted to delegate responsibilities to members of my team. However, I ensure to understand what they are doing so that I still have the big picture and can coordinate the team.

At my previous startup, I had shortlisted two candidates who fitted to the team I wanted to create: one junior and a more senior (read 1 year vs 5 years experience). Choosing Sandro, the more experienced of the two, brought our startup much more than I could have expected. In addition to its experience, he brought his maturity and his culture of effectiveness that he had acquired during his career.

5. You are the example

Never forget that the whole team is looking at you. You set the standards and best practices. Whatever you do or don’t do, your teammates will follow you.

In order to ensure everybody speaks the same voice, I set up code policies and style guides at the very beginning of the project. I strongly believe in peer code reviews. It has been proven that they help communication in company, ensure a better code quality and reduce the number of bugs. At my previous startup, the policy was “two set of eyes on every line of code”. Every commit I wrote was reviewed by Sandro and vice-versa. Instead of committing directly to master, we were doing pull requests on Github that we merged once everything was ok.

Here is an example of a typical pull-request at Solved:

Finally, I’ve found very important to do things before delegating them. If I do not know what I am asking to my teammates, it is very difficult to discuss their choices and put the reflexion further. Even if I do not do the things as well as they would (that’s why I hired them), doing it by myself in the first place give me fine grasp of the challenges they are tackling.

This article is part of the publication Unexpected Token powered by eFounders — startup studio. All eFounders’ startups are built by extraordinary CTOs. If you feel like it could be you, apply here.