Most founders I speak to have already decided they need a CTO before they’ve asked what they actually need.
The title sounds right. The pain is real — engineering is moving too slowly, quality is inconsistent, the team lacks direction. But “fractional CTO” is not the answer to all of these things. Sometimes it is. Sometimes what the company needs is a hands-on engineering manager, or a tech lead with room to grow, or just a 90-day engagement to put the right foundations in place.
I was fifteen the first time I had cheesecake. Fell in love immediately — that dense, creamy texture, the graham cracker base, the way it somehow manages to be both rich and light at the same time. I ate three slices.
I was twenty the first time I wrote serious code. Fell in love with that too — the logic of it, the way a problem would resist you for hours and then suddenly give way. That dopamine hit when something finally works.
I’ve been thinking about the Swiss watch industry a lot lately.
Not because I collect watches — though I do find the mechanical ones disproportionately beautiful for something that a cheap quartz movement outperforms on every objective measure. But because what happened to that industry between 1969 and 1988 is the clearest historical analogue I’ve found for what’s happening to software right now.
I’ve spent the last fifteen years drawing on manufacturing principles to solve software problems — an angle I return to often, including in how AI creates overlooked opportunities in manufacturing operations. The inspiration started early: working with clients in industrial sectors where defect rates were measured in parts per million and process rigour was the culture, not the exception.
One framework that has served me consistently is the Ishikawa diagram — and I rarely see software engineering teams using it.
I’m going to skip the feature matrix. If you want a list of which tools support which file types or which IDE integrations are available, that information is readily available and changes frequently. What’s harder to find is a straight answer to the question that technology leaders actually need to make: which of these tools should we standardise on, and why?
The question I hear most often from founders and CEOs at growth-stage companies is some version of: “We need a CTO — should we hire one, or is fractional the right call?”
The honest answer is that the question usually gets framed wrong. The decision isn’t about finding a cheaper option. It’s about what the company actually needs from the role.
By week ten, the team lead was no longer reviewing code line by line. She was reviewing intent — reading AGENTS.md files, checking that the scaffolding was right, and validating that the output matched the specification. Her engineers had stopped thinking of themselves as code writers. They had become environment designers.
That shift — in role, in mindset, and in daily workflow — happened across a 20-person team in ten weeks. Not through a mandated tooling rollout, but through a structured methodology that changed what engineers were optimising for.
The engineering team was shipping good software. But each deployment cycle involved a CI pipeline that took between 45 and 70 minutes to complete. Add the time for human PR review — typically two to four hours in elapsed time, even when the actual review took 20 minutes — and the cycle from merged PR to deployed code was often half a day.
When manufacturing companies ask about AI, the conversation often goes in one of two directions. Either it’s about robotics — humanoid machines on the factory floor — or it’s about some future-state “smart factory” that requires a complete infrastructure overhaul before anything happens.
Both conversations miss where most manufacturers can actually create value in the near term.
The data problem that isn’t being framed as an opportunity
Most mid-size manufacturers are sitting on more operational data than they’re using. Equipment sensors log temperature, vibration, and pressure. Production systems record run times, output, and downtime. Quality inspection records accumulate for years. ERP systems contain procurement, inventory, and supplier data.
A pattern I see consistently in mid-size technology organisations: the leadership team is excited about AI tooling, the engineering team starts using AI coding assistants, velocity increases, and three to six months later a new layer of technical debt has formed — faster than the old one.
AI didn’t create the problem. It accelerated the existing tendency.
What actually changes with AI in the picture
The fundamental nature of technical debt doesn’t change. It’s still the cost of shortcuts taken today that create extra work tomorrow. What changes is the rate of accumulation and the categories most likely to grow.