What does it take to be a CTO?

The cool things about startups is you have room to learn as you grow. You just have to remember to be intentional about learning as you grow.

I co-founded a company a few years back as the CTO with qualifications closer to you than some Big Tech rockstar. I read a lot of books (audiobooks) and learned as I went. The best thing about being at ground zero is that’s it’s likely just you, your co-founders, and maybe some contractors. You don’t have to worry about leadership, management, or any of the things that come with leading large teams.

If I could only give two pieces of advice:

* As CTO your job is both product and engineering. In fact, product is massively more important until you get to roughly Series A. While you will likely need to write code, your primary job is to find and talk with customers. Amazing code without a customer is worst than shit code with a customer. Customer. Customer, customer.

* Your job is to optimize for the success of the company, not you or your team. That means you need to be aware when something is better done by someone else (aka hire or contract out)

Books:

* the lean startup

* anything by Marty vegan

* a bunch of others, but read those two first.

In the context of this question... early startup... and to really hand waive and simplify things...

The CTO has assemble a team of developers who will build the product or make progress toward that product with reasonable time and cost.

The CEO has to get sufficient attention on that effort to raise the money to pay for continuing it further.

If either fail to deliver in a timely manner, it's over. The more each of you can help with the other's task, the better.

A CTO should be the bridge between technology and the business. They should understand both business and technology. You'll learn things as you grow. But the CTO mindset is important. Your job is NOT JUST to be a developer, an engineer, or an architect. The decisions you take can have a huge impact on your business, and the bottom line. Your experience at FAANG definitely helps. But think beyond that engineering experience. You're building a business. Can you foresee where your company is heading? Can you recruit, train, and grow a team of engineering leaders who will also steer the company in the same direction?

From day one, keep these in mind

1. Anyone can build anything, given they have the time and money, and resources. But only a few people can understand what their customers really want, and build that.

2. You are not an engineer. You are an entrepreneur.

3. You are not here for a solo game. Can you be a great leader?

4. You should understand how your decisions affect the company's finances.

>I am trying to figure out if I'm capable enough to be a CTO..... but my question is more about how much I should already know on day one.

It depends on the type of Start up, is it an SaaS, or ML / AI based company.

You will actually have to understand more about your business goals, than any other programmers below your organisation.

You should say "No" to 99.9999999% of suggestions using the latest and most hyped technology.

Your choice of Technology is likely only there to achieve your business goals, not for your inner child or colleagues to have a playground and mark another thing on their CV / resume.

You will also have to set reasonable schedules and timeline. And be able to deliver them on time.

And here is another unpopular opinion.

Your biggest fight may likely not be your subordinate but with your co-founder / CEO.

What it takes to be CTO is different at different stages:

Pre-product market fit: - Hands on building of prototypes/product to test PMF (doer) - Manage a small team (probably all know each other) coordination (think scrum master)

Product Market fit: - Prioritize quality over speed. (editor) - Recruit, ramp and retain random engineers.

Scale + Maintain: - Frameworks to help teams of teams delivering stuff (editor in chief) - Fight rebuilding/refactoring working software - Recruit, ramp and retain software leaders - Conflicts/politic resolutions

You likely have the skills to get a product out the door, especially if you find a way to step back or have someone ask you diligently "can we skip this", "can we not reinvent this", "is this overengineering?", "what's the one we should prioritise, and the one we should drop?'. Especially if you've been doing ML research and fiddling about - there is limited time for that.

The problems you might have are along the lines of when you get lots of customers. Scaling is horrible for tech, especially anything involving cloud quota requests or newer libraries. You will have the secondary issue of customer support, which at first you can deal with, but quickly can zap 50% of your productivity due to random requests. For CTOs, try and get a reliable dev on your team to take increasing support workload, or hire a dedicated support role.

The two problems you face as a succeeding CTO are quite different. So really do ask yourself how you would handle the customer support issues. The type of startup matters here. Is this urgent for every client, if it breaks? How would you feel if a ping came in at 10:40pm? If your great 5* rating drops to 4* because of bad support, who takes responsibility? Do you entrust your CEO to understand the importance of segmenting support duties from development to ensure your velocity can stay decent?

+ add on presentation and graph making skills if you are raising investment

I think the most important trait of any CTO is to be technical enough to understand what the best choice of tools to use is to accomplish the goals of the business you are running. You will be doing all of the coding at the beginning since your co-founder is not technical, but the important thing to remember is that the choices you make now while acting as the only developer at the company will greatly influence decisions you will make later once you are able to do more CTO level duties (how many devs to hire, how easy it is to find good talent to hire, etc…)

It’s easy to just keep being a developer and making choices on how the tech stack works based on things engineers care about, but you need to be able to say no to things that don’t make sense for the business. The new engineer wants to rewrite the API in a language that no one else is familiar with for performance reasons? No. The team wants to go to a micro service architecture before you have product market for? No. There will be some cases where the answer is yes of course but it should be justified why this is needed and you need to be able to understand technically what the impact will be of each decision.

Lately I was introduced to Gene Kim's Phoenix Project, Unicorn Project, and DevOps Handbook. They changed the way I've looked at a my role as a leader of technical people in the organization as well as challenging some pre-concieved notions about techs role in business. You should check them out

I was a cofounder and CTO of a seed stage company and in your shoes a few years ago. Hit me up if you want to chat sometime! And if you don’t have time, know that you have what it takes - you just have to learn rapidly and be okay with failing sometimes!

(As usual) there is no and could not possibly be a single or even limited number of answers on such a hi level and complex questions.

To be a cto of amazon - my guess it takes firstly a world class skill in playing political games and manuevering stakeholders expectations.

To be a cto of some startup - it may take just a luck to be in the right place in the right time.

I doubt there are many cases where it correlates with your knowledge per se.

it’s an IC mentality, while CTO in most cases is a management position.

In the early stages, the main skill is just figuring out how to get whatever is needed done. You'll probably be wearing many hats, since there are only two of you. If the expectation is you'll build the product, you should have confidence that you can build it.

If you intend to keep it simple & small, none of the following advice really matters. Two people can work together on anything. This is about what happens when you need to hire that 2nd, 3rd and 4th developer, sales team, etc. because you are starting to feel the burnout monster lurking in the shadows.

I'd say your job is to serve the board (CEO) + developers as a sort of communications bridge and secondary captain. You should try to steer the technology away from things that would add complexity/liability to the organization. You should always be asking: "How does this add value to the customer's experience?" followed immediately by "Don't we already have XYZ at home?".

Certainly, let your developers play with shiny things from time-to-time, but carefully pick & choose the technologies that you promote to "we use this in prod for paying customers". Consider that this may have implications for the technologies you select today. Everything in technology has inertia, even if it's just files in the computer. That fancy purely-functional web framework you really enjoy today might not be so compatible with the broader job market tomorrow.

> I am trying to figure out if I'm capable enough to be a CTO.

I think many CTOs are still trying to figure this out today. For me, the struggle never ends and I think that is sort of the hallmark of good leadership. If you become content & comfy in your seat of power, you are almost always headed down the path of cartoon villain boss and/or bankruptcy.

Humility is probably the most important thing. The ability to put your ego into a box, lock it, and throw away the key for 5+ days a week is critical. If you cannot do this, you need to consider if CTO is a good path for you. Especially if you intend to scale beyond just the CTO being the only developer in your organization. Growing other people is the hardest thing. They have egos too. You can get value out of almost anyone when they feel empowered.

You may find value in adopting an "extreme ownership" mindset, but others on HN have different opinions of this sort of thing. I've gone down this path and I enjoy it because the fire of "everything is my responsibility no matter what" has encouraged me to push my team away from things that would cause me to lose sleep at night. My fears happen to be highly-coincidental with our customers' fears, so this tends to work out well in practice. YMMV here and I am not responsible for any side effects that may result from reading certain "self-help" books...

don't call yourself CTO if there aren't at least 10 people (technical team) under you please. Call yourself technical co-founder.