Startup CTO references: what founders should really ask

Why most reference calls miss the real work

Most founders use reference calls to confirm what they can already see. They ask whether the CTO shipped on time, handled pressure, or got a product out the door. Those answers sound useful, but they mostly describe visible work.

A startup can ship fast while the code gets harder to change, the team burns out, and small problems pile up until they turn into outages, missed hires, or constant rework. That is why a polished launch story can mislead you. Some CTOs move quickly by adding people, tools, and shortcuts that feel fine for three months and hurt for the next two years.

The less flashy work tells you more. Ask what the candidate stopped doing. Ask what they simplified. Ask what they repaired after things went off track. A strong answer might be about killing a half-built feature that kept dragging the team down, cutting cloud waste, fixing a broken deployment process, or reducing incidents so people could work normal hours again.

That is judgment. It shows the CTO could protect the company, not just push it forward at any cost.

This matters even more in an early team, where one technical leader can shape habits fast. When a founder says, "He cleaned up our release process and made production calm again," that gives you something real. So does, "She removed three tools nobody needed and our team moved faster a month later." Those details carry more weight than "great leader" or "strong strategist."

Reference calls work when you collect specific stories. Praise is easy. Examples are harder to fake. If a former founder can describe what the CTO fixed, what they chose not to build, and what changed after that, you are finally hearing about the real job.

Decide what you need to learn first

A reference call only helps if you know what could go wrong after the hire. Most founders skip that step. They jump on the call, ask if the CTO was good, and get the usual answer: smart, hard working, pleasant to work with. That tells you almost nothing.

Start with your own company. Write down the risks you carry right now. Maybe the product keeps slipping. Maybe the codebase is messy. Maybe the engineers need more direction. Maybe the team ships fast but breaks things every week. Your reference call should test those risks, not chase a general opinion.

Keep product judgment separate from people management. Some CTOs make sharp calls about scope, architecture, and tradeoffs, but struggle to hire, coach, or calm a tense team. Others build trust and structure, yet do not push product decisions well. If you roll those into one vague question, the reference will blur them together.

Be honest about the kind of CTO you need. Some startups need a builder who can get from idea to first release. Others need a stabilizer who can repair systems, tighten process, and reduce chaos. Some candidates can do both, but one strength is usually much stronger.

Early startups often say they want both, then discover they mainly need one. If your product is late, a calm operator may not save you. If your team is burning out, another fast builder may make it worse.

Before the call, pick two or three gaps you need to clear up. Keep them narrow. Can this person cut scope without drama? Can they turn a shaky team into a steady one? Can they spot technical debt early and fix it before it slows the company down?

That focus changes the whole call. Instead of asking for a full career review, you ask for proof around the few things that matter over your next 12 months.

How to run the call step by step

A good reference call takes 15 to 25 minutes. Keep it tight, and keep it tied to a period when the founder and the CTO worked closely enough to see each other under pressure.

Start by setting the frame: "What was the period when you worked with this person most directly?" That simple question pushes the call away from vague praise and toward memory. A founder who says, "We worked together every day for nine months during a rebuild," can usually tell you something useful.

Then ask for contrast. Get one project that worked and one that did not. A smooth launch shows how the CTO planned and executed. A bad project shows how they acted when deadlines slipped, systems broke, or the team lost confidence.

Once you hear about shipped work, move to the work they stopped, simplified, or repaired. Many founders only remember launches. That misses half the job. Good CTOs often help a company by cutting a bad roadmap, shrinking a messy stack, or fixing uptime and release problems.

Ask what changed in the first 90 days. Keep it concrete. Did they change team structure, deployment habits, vendor spend, hiring plans, or the way decisions got made?

If the founder uses labels like "strategic" or "technical," push for examples. Ask what they actually did that week or month. You are trying to get from identity to behavior.

End with the rehire question: "Would you hire this person again for your current stage, and why?" The pause before the answer often tells you as much as the answer itself.

One extra prompt is worth keeping in your back pocket: "What did this person fix that everyone else had learned to live with?" Former founders usually answer that with a story, and stories are much harder to fake than compliments.

Questions that get past polite answers

The best reference calls do not center on charisma, vision, or how much the person shipped. Those answers sound good, but they hide the work that matters most. A good CTO often creates progress by stopping work, cutting complexity, and cleaning up damage before it spreads.

Former founders usually give better answers when you ask about tradeoffs instead of achievements. Shipping is easy to praise. Saying no, removing pet projects, or admitting that something broke takes more honesty.

Ask questions like these in plain language: "What did this CTO stop doing after joining, and was that the right call?" "What did they simplify for the team or product?" "What broke under their watch, and how did they repair it?" "Where did they say no when other people wanted more features, more hires, or more tools?" "What looked good at first but caused trouble later?"

Those questions push the reference past polite approval. If the founder answers with real events, you can usually hear the difference fast. "They cut three half-built projects and focused the team on one release" tells you far more than "they were great technically."

Listen for timing, tradeoffs, and aftermath. Maybe the CTO removed a complicated microservice setup and the team shipped faster two weeks later. Maybe they blocked a flashy feature because uptime was shaky and customer support was drowning. That kind of answer shows judgment, not just enthusiasm.

The repair question matters most. Every CTO inherits a mess, and most create one at some point too. You want to know if they owned it, explained it clearly, and fixed it without blaming the team. If a reference claims nothing ever broke, the call is probably too polished to trust.

The last question often reveals the deeper problem. Some CTOs make a strong first impression with a rewrite, a new stack, or a big hiring plan. Later, the team slows down, costs rise, or nobody can maintain what they built. A founder who can name that pattern gives you a much clearer read than any glowing summary.

What strong answers sound like

A useful founder reference sounds specific, a little uneven, and easy to picture. The person on the call should name one thing the CTO changed, why they changed it, and what happened next. If all you hear is "great leader" or "shipped fast," you still do not know how they worked when things got messy.

The best answers often start with cleanup, not heroics. A founder might say the CTO cut the team from eight project boards to one, removed two approval steps before release, or killed a weekly meeting that wasted an hour for six people. That kind of answer tells you the person saw drag, acted on it, and made daily work simpler.

Strong answers also include tradeoffs. Real operators rarely pretend every choice was perfect. You want comments like, "She moved us to a much simpler stack. We lost a few nice-to-have features for a month, but deploys got stable again." Or, "He stopped three side projects and upset two people on the team, but we finally shipped the product customers were waiting for." Or, "She pushed for fewer tools and more written decisions. It felt slower for two weeks, then handoffs got much clearer."

Notice what makes those answers useful. They describe less noise: fewer tools, fewer meetings, fewer handoffs, fewer moving parts. They also point to a result you can test. Maybe incidents dropped. Maybe onboarding took three days instead of two weeks. Maybe the team spent less time arguing about process and more time fixing customer pain.

A good reference can usually point to one before and after change. "He repaired our release process, and support tickets fell by about 30% the next quarter" tells you much more than "everyone liked working with him."

The strongest references include one miss or blind spot without turning into a warning story. A founder might say, "He was right about the architecture, but he waited too long to replace an early manager," or, "She cut costs fast, but she did not explain the changes well enough at first." That kind of honesty makes the rest of the praise easier to trust.

A simple startup example

A B2B SaaS founder launched fast with a small team, a rough product, and a growing list of customer complaints. Revenue started to come in, but the product felt shaky. Deployments failed often, support tickets piled up, and the roadmap kept getting longer.

The founder hired a CTO because the team needed more than more code. They needed someone to make the product easier to run. On paper, the new CTO had shipped plenty before. What changed the company, though, was not the next feature release.

In the first month, the CTO looked at how the team worked and cut three tools that only part of the team still used. Each one had a cost, a login, and a bit of process attached to it. They also stopped a side project that sounded exciting but had no real user pull and kept stealing time from the main product.

That decision annoyed a few people at first. It also gave the team back its focus. Instead of adding more surface area, the CTO fixed the release process, cleaned up the deployment steps, and made sure the same build worked the same way every time.

Only after that did the team return to product work. Support volume dropped because they removed a couple of confusing flows that pushed users into dead ends. Customers did not praise those changes in fancy language. They just stopped opening as many tickets and finished tasks without asking for help.

That is the kind of detail a strong reference can reveal. A former founder might say, "They did ship features, but what helped most was what they refused to build." That answer tells you the CTO understood tradeoffs, team attention, and the cost of mess.

The founder in this example trusted the CTO more after seeing those calls. The CTO did not chase visible wins for the next board update. They made the product calmer, the team less scattered, and the business easier to run. That is often the difference between a technical lead who stays busy and a CTO who actually helps a startup grow.

Mistakes that waste the reference call

The fastest way to ruin a reference call is to ask for a character review. "Was she good?" gets you polite praise, not useful information. Almost every senior hire sounds smart and pleasant for 20 minutes.

Warm comments are not proof. If someone says, "great leader" or "strong technical person," ask what changed because of that. Did the CTO cut a bad project, fix a shaky release process, or stop a hiring plan the company could not afford?

Founders also make a common mistake when they speak only with former peers. Another engineer can tell you whether the candidate wrote clean code or earned respect. A former founder can tell you something harder: what the CTO did when cash got tight, deadlines slipped, or the team picked the wrong architecture.

That difference matters. A CTO can impress peers and still make poor calls on budget, hiring, and scope. Reference calls should focus on those decisions because they shape survival, not just product output.

Some topics make founders uncomfortable, so they skip them. That is a mistake. The most useful part of the call often starts when you ask about tension. What happened when the roadmap fell behind? How did the CTO respond when hiring took too long or cost too much? Did they push back on the founder, and were they right? What broke under their watch, and how did they repair it?

You also waste the call when you let the candidate script everything. Some candidates offer only their friendliest contacts. Some tell those contacts exactly what to say. Some frame the whole story in advance, so the reference repeats a polished version.

Do not treat that as enough. Ask for former founders, not just peers. Ask for one person from a rough period, not only a growth period. If you are reviewing a fractional CTO, ask who saw the candidate make tradeoffs with limited time and limited money.

A good call should leave you with specifics: what the person stopped, what they simplified, what they repaired, and what they got wrong. If you finish with only nice adjectives, you learned almost nothing.

Quick checks before you decide

Good references leave a pattern, not just a pleasant feeling. Before you choose, line up the calls and look for the same kind of judgment in more than one story.

Can two different people name something the CTO stopped because it wasted time or money? Can at least one person describe a repair that still held months later? Do the stories fit your stage, team size, and runway? Did anyone mention churn, redo work, or constant cleanup after big wins? Would you still trust this person if you had less budget and fewer engineers than planned?

The first question matters more than most founders think. Strong CTOs do not only ship. They kill bad rewrites, trim tools, cut scope, and say no before a team burns a month on the wrong thing.

Repairs matter for the same reason. A reference should be able to say what broke, what the CTO changed, and why the fix lasted. "They helped during a rough period" is too vague. "They rebuilt the release process, incidents dropped, and we stopped rolling back every Friday" is much better.

Stage fit can make a good candidate look wrong. Someone who did well with 80 engineers and a full product team may struggle in a six-person startup. Early teams need a CTO who can work with thin budgets, messy code, and incomplete plans.

Listen hard for side comments about people leaving, projects getting rebuilt, or teams cleaning up after rushed decisions. References often mention these as small footnotes. They are not footnotes.

A simple test helps when you feel torn. Picture your next six months going worse than planned. One engineer quits. Revenue slips. Hiring takes longer. If the reference stories still make you trust this CTO in that version of your company, you probably heard something real. If not, pause and keep checking.

What to do after the calls

Write your notes right away. Ten minutes later, people start smoothing over rough answers and filling gaps with their own guesses. If two founders joined the calls, compare notes the same day and mark where you heard the same signal twice.

Then match each answer to a real risk inside your company. Reference calls are only useful if they help you judge the problems you actually have, not the problems some other startup had two years ago.

A simple filter works well. Did the candidate cut waste, or just add more work? Did they repair messy systems, or only ship new features? Did they protect uptime, cost, and team focus when things got hard? Did they tell founders bad news early? Did they leave the company easier to run than they found it?

This step matters because glowing references can still hide a mismatch. A founder may love a CTO who built fast with a big budget. That does not help much if your problem is a thin team, fragile releases, and six months of technical debt.

Look for patterns, not one dramatic quote. If three people say the candidate brought calm during outages, cut scope cleanly, and fixed broken delivery habits, that means something. If the praise stays vague and nobody can name what the person stopped, simplified, or repaired, treat that as a warning.

If doubts remain, do not force a yes or no too early. Use a paid trial or a short advisory project. Give the candidate a real problem with a clear boundary, such as reviewing your roadmap, auditing delivery risks, or proposing a plan for a shaky product area. A short paid project shows more than another interview round, and it respects the candidate's time.

If you want an outside read before you decide, Oleg Sotnikov at oleg.is advises startups on CTO hiring, product architecture, and technical due diligence. A quick review of the role, your interview plan, and your reference notes can make a fuzzy decision much clearer.