What to look for in a CTO hire, especially your first
A founder asks us what to look for in their first CTO, and the honest answer often surprises them, because it starts by questioning an assumption they did not know they were making. They usually picture their strongest engineer, the person who releases the most work and knows the code best, and they assume that person is the CTO. Sometimes they are right. Often they are not, and the mistake is expensive, because a CTO who is really just a senior engineer with a title leaves the actual leadership work undone. Being a great engineer and being a great technical leader are different jobs in the same field. Here is how we help founders think about the difference, the fractional-versus-full-time question, and the traits that actually predict whether someone can do the role.
A great engineer is not the same as a technical leader
Start with the assumption itself, because everything else follows from it. The best individual engineer solves hard problems themselves. They study problems in detail, they build fast, they know the system completely. Those are real and valuable skills. But they are skills for doing the work, and a CTO's job is mostly not doing the work. It is deciding which work is worth doing, with incomplete information, and getting other people to do it well.
Those two jobs can require opposite habits. The instinct that makes someone a great builder, "I can just do this myself," is often the exact instinct that makes them a poor leader, because one person can only do so much work alone. A CTO who solves every hard problem personally becomes the step that slows down the whole team. The role needs a different set of skills: choosing where to spend limited engineering effort, saying no to good ideas that do not fit, building a team that is stronger than any one person, and staying calm when the next step is unclear. Some strong engineers have those skills. Many do not, and there is no shame in that, but promoting on coding skill alone and hoping the rest appears is how companies end up with a CTO title in the org chart and nobody actually doing the leadership work.
The traits that actually matter
When we help a founder evaluate a candidate, four traits matter most, and none of them is raw coding talent.
The first is judgment. A CTO's days are full of decisions with no clearly right answer: which technical risks to take, what to build now and what to leave for later, when to take on some debt on purpose and when to refuse. Good judgment is not picking the trendy option. It is weighing cost, risk, and business impact together and being willing to change your mind when the facts change. The best way to see it is to ask a candidate about real decisions they made, especially ones they got wrong, and listen to how they reason. Someone who cannot name a past mistake either has not made enough real decisions or cannot learn from them, and both are disqualifying.
The second is communication, and people value it less than they should because it is easy to miss. Most of a CTO's impact happens through other people. They have to explain technical trade-offs to founders and investors who are not technical, align the engineering team around a plan, and say no clearly without damaging trust. A brilliant technical mind that cannot make itself understood leaves the whole company guessing, which is worse than a less brilliant one who keeps everyone working toward the same goal. If a candidate cannot explain a hard technical choice to you in plain language, that is not a small gap. It is the job.
The third is hiring, because a CTO's real output is the team, not their own code. A leader who can attract, judge, and grow engineers stronger than a solo builder ever could is worth far more than the best individual contributor working alone. If a CTO cannot hire well, the entire engineering organization is limited to what that one person can personally do, and the team reaches that limit fast. It is one of the first things we look for. A candidate who shows no interest in hiring or mentoring, and only gets excited when talking about building things themselves, is telling you which job they actually want, and it may not be this one.
The fourth is calm under uncertainty. At a startup the answer is rarely clear, information is always incomplete, and something is usually going wrong. The team copies the mood of its leader. A technical leader who panics, or who freezes waiting for certainty that never comes, spreads that through the whole group. One who can make a sound decision with what they have, explain why, and adjust as they learn keeps the team calm enough to keep releasing work. We wrote about the value of that steadiness at the team level in move fast without breaking the product, and it starts with the person leading.
Fractional or full-time
Once you know what the role needs, the next question is how much of it you need, and how soon. This is where the fractional-versus-full-time choice comes in, and a lot of early companies default to full-time without asking whether they should.
A fractional CTO is an experienced technical leader who works with you part-time, often alongside a few other companies. You get senior judgment, architecture guidance, hiring help, and clear direction, without the cost or the commitment of a full-time executive. For an early company this can be exactly right. If your technical direction needs to be set well but does not yet need someone in the role every day, a fractional leader gives you the most valuable part, the judgment, without paying for a full-time position you do not yet have enough work for.
A full-time CTO is worth the cost when technical decisions are constant and central to the business, when the team is large enough to need daily leadership and steady growth, and when the role needs someone who fully knows your company and culture, instead of someone splitting attention across companies. The signal is not "we feel we should have a CTO." It is "the technical decisions and the team have grown past what a part-time leader can handle." Start from that honest view of what the company actually needs day to day, and the answer is usually clear. Getting this wrong in either direction is costly: a full-time hire with too little to lead gets frustrated and expensive, and a fractional one working part-time at a company that needs full attention leaves work undone.
Hiring for the job, not the title
Put it together and the answer gets clear. Do not start from your best engineer and assume they are the CTO. Start from what the role has to do: own technical direction, decide where to spend limited effort, build a strong team, and keep everyone steady under uncertainty. Then look for the traits that predict it, judgment, communication, hiring ability, and calm, and test them with real questions about real decisions, not credentials. Finally, be honest about how much of the role you need right now, and let that decide between a fractional leader and a full-time one.
The founders who get this right treat the CTO hire as a leadership decision that happens to be technical, not a technical decision with a leadership label added. Seeing it that way is most of the work. When companies come to us without the right leader in place, we often serve as that senior technical partner for a while, helping them decide what to build, how to build it, and how to grow the team, sometimes filling the role until they hire full-time and sometimes helping them see what to look for. Either way, the goal is the same: good technical judgment involved in the decisions that matter most, from a person suited to leading and not just to building.
Add one area to assess, because it has quickly become central to the job. Ask a candidate how they think about AI-written code in a production codebase, and listen for whether they have a real position.
You are not looking for enthusiasm or for caution specifically. You are looking for someone who has thought concretely about the mechanics: what the review process should be, who is accountable for generated output, how it changes what you measure, and what it does to a team's understanding of its own system. A candidate with no view here is not neutral on the biggest change to how engineering teams work in a decade. They have not been paying attention.
