Hiring a CTO When You've Never Done It Before
By AXG TechInvent · 10 min read
Hiring a Chief Technology Officer is one of the most consequential decisions a founder or CEO will make. It is also one where inexperience is most costly — because the person doing the hiring often lacks the technical background to evaluate the candidates, and the stakes of getting it wrong are exceptionally high. A bad CTO hire does not just underperform. It affects every other person in the engineering organisation, every technical decision made during their tenure, and often the company's ability to raise its next round.
This guide is written for founders and non-technical CEOs who are approaching this hire for the first time. It will not make you a technical expert. It will give you a structured way to think about what you need, how to evaluate candidates you cannot fully assess yourself, and the signals — positive and negative — that matter most.
First: What Kind of CTO Do You Actually Need?
CTO is not a single job. The role looks fundamentally different at different stages of company development, and the most common mistake in this hire is looking for the wrong archetype.
The early-stage CTO is primarily a builder. They write code, make fast architectural decisions with incomplete information, and care deeply about shipping. They are comfortable with ambiguity and energised by zero-to-one problems. They are probably not yet thinking about org design, engineering career ladders, or board presentations.
The scaling CTO is primarily a multiplier. They may write less code but they make the engineers around them significantly more effective. They design processes, build hiring pipelines, establish engineering culture, and translate between technical and business strategy. They are often the person who takes a team from 10 to 50 engineers without it falling apart.
The enterprise CTO is primarily a strategist and communicator. They spend significant time with customers, investors, and the board. Their technical depth is real but their primary leverage is judgment and communication, not execution.
Most founders in the early-to-mid stage need the second archetype. They almost universally search for the third. This mismatch is the source of a significant proportion of failed CTO hires.
The Competency Model
Before you begin speaking to candidates, write down — specifically — what you need this person to own in the first 90 days, the first year, and the second year. Then map those outcomes to competencies. The competencies that matter most for a scaling-stage CTO, in rough order of importance:
- Technical judgment. The ability to make sound architectural decisions under uncertainty, evaluate build vs buy vs integrate tradeoffs, and understand the long-term cost of short-term technical choices. This is different from technical knowledge — it is the application of knowledge to real business constraints.
- Engineering leadership. The ability to attract, develop, and retain strong engineers. A CTO who cannot build a team cannot scale. Ask for specific examples of engineers they have hired, developed, and promoted. Ask for examples of underperformers they managed constructively.
- Cross-functional communication. The ability to translate between engineering and the rest of the business. This means making technical concepts accessible to non-technical stakeholders without oversimplifying, and translating business priorities into technical direction without losing nuance.
- Delivery track record. Evidence that they have shipped things — not just designed them. A candidate with an impressive technical vocabulary but a thin delivery record is a significant risk.
- Self-awareness about their own gaps. The best CTOs know what they are not good at and build around it. Candidates who cannot clearly articulate their weaknesses are either not self-aware or not being honest with you.
How to Evaluate Candidates You Cannot Fully Assess
If you are a non-technical founder, you have a real problem: you cannot directly evaluate the technical judgment of the people you are interviewing. Here is how to address this without pretending the problem does not exist.
Bring in a technical advisor for one interview. This should be someone with no stake in the outcome — not a current investor, not a potential future employee. An experienced CTO or VP of Engineering from your network, or a specialist recruiter with genuine technical depth, can conduct a 60-minute technical conversation and give you a signal you cannot generate yourself. This is not optional. Do not skip it.
Ask about decisions, not knowledge. Instead of asking technical questions you cannot evaluate, ask about decisions the candidate has made. "Walk me through the most consequential architectural decision you made in your last role. What were the options, what did you choose, and what would you do differently?" You are not assessing the technical content of the answer — you are assessing the quality of their reasoning, the clarity of their communication, and whether they take genuine ownership of outcomes.
Ask about people, specifically. "Tell me about the best engineer you have ever hired. How did you find them, how did you assess them, and what happened to their career?" "Tell me about someone you let go. How did you know it was the right decision and how did you handle it?" The specificity and humanity of the answers to these questions is extremely revealing.
Check references before you make an offer. Call the references yourself — do not delegate this. Ask the previous CEO or founder they worked with directly: "On a scale of one to ten, how likely would you be to hire this person again as your CTO? What would have to be true for that number to be a ten?" The gap between the number they give and ten is where the real information lives.
Red Flags That Are Not Obvious Until It Is Too Late
Some warning signs are easy to miss when you are impressed by a candidate's presence or credentials. These are the ones we see most frequently in retrospective conversations with founders who made the wrong hire:
- They speak about engineers as a resource, not as people. Phrases like "we just need more bandwidth" or "I'll bring in some resources to handle that" in the context of discussing a team problem are a warning sign. CTOs who do not see engineers as whole people do not build strong engineering cultures.
- They cannot explain their last company's technology simply. If a candidate cannot explain what their last product did and how it worked to a non-technical person in under two minutes, they either did not fully understand it or cannot communicate across contexts. Neither is acceptable at this level.
- They have strong opinions about tools and weak opinions about outcomes. Candidates who have very specific views on which databases, frameworks, or cloud providers are correct — but struggle to connect those views to business outcomes — are optimising for technical elegance rather than company success. These are different things.
- Their references are all peers, not direct reports or managers. If every reference is a former colleague rather than someone who managed them or was managed by them, ask why. References from people who have seen someone perform in a hierarchical relationship are significantly more informative than lateral references.
- They are in a rush. A CTO who is pushing to close quickly, discouraging reference checks, or applying pressure at the offer stage is giving you information. The best candidates understand that this is a significant commitment for both parties and welcome a thorough process.
The Onboarding Problem
Most CTO hires are given 90 days to "make an impression" and then evaluated on output. This is the wrong frame. A CTO who makes sweeping changes in their first 90 days — rewriting the tech stack, reorganising the team, deprecating systems built by people who are still in the room — is not demonstrating confidence. They are demonstrating poor judgment.
The first 90 days should be structured around listening, understanding, and building trust. The CTO who comes in, spends six weeks understanding why every decision was made the way it was, earns the respect of the existing team, and then begins making changes from a position of genuine understanding — that is the CTO who will still be effective in year two.
If you are about to make this hire, or if you have recently made it and things are not going the way you hoped, we are glad to share what we have learned across this specific engagement type. Reach out directly.