Should You Hire a CTO?
Advice on whether to hire a CTO for an early stage hyper-growth company and the considerations involved.
One of my friends, running a hyper-growth company, just closed his seed round. He’s already got millions in revenue and a small team of very technical people, mostly PhD researchers. Now, he’s thinking about adding a CTO because they’re facing two main challenges:
Scaling hardware orchestration (it’s an AI company) to keep up with demand.
Creating a solid foundation for the product to make adding features easier.
Here is my advice:
Don’t Call the Role “CTO”
The person you want to hire will still spend most of their time coding. In rapidly growing companies, architectures change dramatically. Until you have over 100 engineers, you don’t need full standardization (I saw this firsthand at Ridgeline). You need someone who can:
move fast
not be tied to their decisions
and implement these architectures hands-on
Call the role “Staff/Principal Engineer” and add a significant equity component so they almost operate like a technical founder. This role should be a direct path to CTO if they choose.
Hire for Low Ego
A CTO title adds unnecessary ego to your startup. You need someone who prioritizes speed over perfection. Simple architectures are better for rapid growth.
Hiring someone with low ego is crucial because:
Decision Making: The decisions they make should prioritize rapid progress over perfect solutions. Startups thrive on quick iterations and learning from mistakes rather than spending weeks to make the perfect choice.
Team Dynamics: Low ego individuals tend to foster a collaborative environment. They are more likely to listen to other team members, welcome feedback, and make adjustments based on collective insights. This is essential in a small, fast-moving team where every member’s contribution is vital.
This is especially important because, like it or not, you'll project this person’s characteristics onto the next hires. Do you want five more engineers like them? They’ll likely lean towards hiring friends or past colleagues. This can be a good thing if you build a team of low-ego, high-output engineers.
How do they spend their time now?
Most of their time should be spent coding, prototyping, and unblocking other engineers. They are the first ones addressing customer feedback/ issues without being asked to. A very minor part of their job involves recurring meetings. Ideally they spend less than 4 hours a week in meetings.
Red Flags 🚩
These are some red flags I've seen with early stage technical leaders:
When you describe a complicated problem, they immediately offer a solution without seeking to understand.
They propose using something like AWS Amplify, unless it’s specifically for prototyping.
They want to rebuild fundamental technology to solve a problem (like an ORM, graph database, programming language, query language, etc.).
They don't ask about the customer or use the product to understand their pain points.
They aren't able to work fullstack/ refuse to do so.
They don't have experience writing documentation or explaining complex topics to non-technical people.
Be Prepared to Fire Early
The best companies make decisive hiring and firing decisions. If someone isn’t a culture fit, isn’t pulling their weight, or seems absent, consider letting them go. It’s not a reflection on the person—they might be incredible but not the right fit at this time.
Conclusion
I don't think CTOs build companies at early stages, engineers do. When are you hiring, be very choosy, but if the right person comes along, close immediately.