7 Things I Believe About Tech Leadership That Most Founders Don't Want to Hear

Fractional CTO marketplaces make money when you sign a retainer, so they sell you on needing one. AI vendors make money when you buy the seat, so they sell you on the tool being the answer. VCs make money when the company looks fundable on paper, so they push a hiring checklist that reads well in a board deck.

None of these groups are lying exactly. They’re telling you the version of the truth that serves them. I turn down more engagements than I take, and the seven opinions below have cost me work more than once. Here they are anyway.

1. There’s a real signal for when to hire a CTO, and it’s not a date on a calendar

The VC playbook says hire technical leadership on day one, for adult supervision on the cap table. The bootstrapper playbook says wait until something breaks, because paying for seniority you don’t need yet burns runway. Both are wrong, and both are popular because they’re easy to say in one sentence.

The signal I watch for isn’t revenue or headcount. It’s whether your most senior technical person has stopped writing code and started spending most of their week managing people and making architecture calls they’re not confident in. That’s the tell. It usually shows up somewhere around 15 to 20 engineers, but the number moves. What doesn’t move is the pattern: your best technical person is doing a CTO’s job badly, unpaid, on top of their actual job. That’s the week to start the conversation. Not before, not two years after.

2. AI adoption fails because of missing infrastructure, not the model

The AI-hype crowd tells founders that if they’re not “using AI” everywhere by now, they’re already behind. The AI-skeptic crowd says the whole thing is overhyped. Both camps assume the problem is the model.

MIT’s Project NANDA tracked enterprise AI pilots in 2025 and found 95% delivered no measurable P&L impact. The researchers were specific about why: “The core issue isn’t talent, infrastructure, or regulation, it’s the lack of learning, integration, and contextual adaptation.” Not the model. Not the budget. The same study found buying or partnering for AI capability succeeded roughly two-thirds of the time, versus about a third for internal builds. Most companies are trying to build the wiring themselves and getting it wrong.

I see this constantly. A founder pays for Claude, uses it for a handful of one-off tasks, and concludes it’s “fine, but not the step change I expected.” It never had context on the business, no persistent workflows, no voice. That’s not an AI problem. That’s a systems problem wearing an AI costume.

3. Founders hire for the wrong thing, and it’s usually pedigree

Ask a founder what kind of engineer they need and most describe seniority: ex-FAANG, ex-unicorn, big-name background. VCs reinforce this by introducing candidates selected the same way, because pedigree is legible in a board meeting. The competing view, common among technical founders, is to hire people who think like they do, on the theory that shared instincts mean less friction.

Both produce bad outcomes more often than people admit. A candidate with a polished big-company background often expects the structure that comes with one, none of which exists at a 12-person startup, and the mismatch shows up within a quarter. Hiring in your own image just means you’ve built a team that agrees with you. What actually moves an early-stage business is someone hired against a specific outcome you can state in one sentence, not a title. “Someone who can take our onboarding flow from a 40% drop-off to shippable in six weeks” is a hiring brief. “A senior engineer” is a job title looking for a problem to justify itself.

4. You can’t evaluate technical risk you can’t see, so stop pretending you can

Non-technical founders are told to run technical due diligence before a build-or-buy decision, an acquisition, or a major platform bet. The advice is sound. The execution usually isn’t, because the founder nods along to whichever vendor speaks with the most confidence, mistaking fluency for competence.

The industry-cited Standish CHAOS data (methodology has drawn real academic criticism, so treat it as directional) still points at something true: big technical projects fail at a far higher rate than small ones, and most of that failure is invisible until months in, past the point a due diligence call could have caught it. The fix isn’t a longer checklist. It’s someone in the room who can ask the question the vendor doesn’t want asked, and translate the answer into what actually breaks if this goes wrong.

Be careful with the build-vs-buy framing too. Vendor lock-in is real, but so is the lock-in you create yourself: a custom system with three years of undocumented decisions is just as hard to leave as any SaaS contract once the original developers move on. The question isn’t which one avoids lock-in. It’s which lock-in you can live with in three years.

5. A fractional CTO isn’t an interim manager who executes your roadmap

The fractional-exec marketplace industry sells the role as part-time ongoing leadership: hand over a roadmap, they execute it, you get senior output at a fraction of the cost. It’s a clean pitch, and it’s not quite what makes the job worth paying for.

The roadmap-execution framing treats the CTO as a resource you point at a plan. The actual value is upstream: deciding what the plan should be, given the business you’re actually running, not the one on the pitch deck. Most fractional engagements that go sideways don’t fail on delivery. They fail because nobody defined what “done” meant before the engagement started. The founder hands over a vague “fix everything” mandate, the CTO fills the vacuum with their own judgment, and eighteen months later nobody can agree whether it worked, because nobody wrote down what winning looked like. The job isn’t executing your roadmap. It’s helping you figure out whether you have the right one, then being specific enough about decision rights that both sides can tell whether it’s working.

6. Boards don’t need more detail. They need less jargon and more honesty

Most technical reporting to boards is written to demonstrate competence rather than inform a decision. Acronyms, architecture diagrams, false precision about timelines nobody believes. It reads well. It tells the board almost nothing they can act on.

NACD’s 2025 board practices survey found 72% of public-company board packs run over 200 pages, and only 13% of directors rate those packs as extremely effective. More content, less usable. NACD’s own guidance is blunt: assume zero technical fluency, report in business terms, revenue at risk, cost of downtime, regulatory exposure, skip the acronyms entirely. Boards don’t need to understand your database migration. They need to understand what happens to the business if it goes wrong. Reporting that reassures instead of informing isn’t reporting. It’s theatre.

7. Sometimes the right advice is: don’t hire a fractional CTO

This is the one that should cost me the most, and the one I mean the most. There are real situations where bringing in a fractional CTO, me or anyone else, is the wrong move, and a good advisor says so before the retainer gets signed.

If you’re pre-product-market-fit and you or a technical co-founder can still write the code yourselves, do that. Claude and tools like it have lowered the bar for a non-technical founder to ship a credible first version before bringing in any technical leadership. Paying for strategic leadership before you’ve found the thing worth building is expensive ceremony, not progress. If your real problem is sales, distribution, or product-market fit, and you’re reaching for a technical hire because it feels like doing something: no CTO fixes a demand problem. And if you can’t state the decision you need this person to own, you’re not ready to hire one. You’re ready for that conversation first, probably with someone who isn’t charging you a retainer for it.

If reading this list felt clarifying, that’s usually a good sign we’d work well together. If it felt like I was arguing against a version of tech leadership you believe in, we’re probably not a fit, and better to know that now than three months into a retainer. Book a call and we’ll work out honestly whether there’s a reason to work together.