The misconception most founders walk in with
When founders first reach out about a fractional CTO, they almost always describe a technical problem. The platform is creaking. The team has grown but delivery has slowed. There's a security audit looming. The codebase is a mess. The architecture won't survive the next 10× of users. These are real problems and I take them seriously.
But the framing tells me what's about to happen. They're describing the symptom they can see, not the situation they're actually in. They've been trained (by job specs, by conferences, by every fractional CTO marketing page) to think of the role as a technical hire who comes in to fix technical things. So that's what they ask for.
Two weeks into the engagement, the conversation has almost always shifted. We're no longer just talking about the platform. We're talking about how the commercial model is evolving, what the next funding round needs to demonstrate, where the customer pain is concentrated, what the team actually feels capable of. The technical work is happening, but the more valuable conversation is the one about how the business is genuinely trying to grow, and what that means for the technology.
That shift, from technical-problem-fixer to business-partner, isn't an accident. It's the work.
What "starting with the business" actually looks like
The first thirty days of a fractional engagement are sometimes described as a tech audit. That's accurate but incomplete. The technical review is real, codebase, infrastructure, architecture, security posture, delivery pipeline, all the things you'd expect. But it sits inside a wider exercise that I think is more important: understanding how the business actually works.
That means a sequence of conversations that have very little to do with technology in their first hour. With the founders, about the commercial model, the unit economics, where they think growth comes from in the next twelve months. With sales or commercial leads, about which deals are easy to win and which ones get stuck and why. With the product team, about which features customers genuinely value and which ones look good in screenshots but rarely get used. With finance, about what the runway picture really looks like and what assumptions sit behind it. With investors where appropriate, about what the next round is going to need to demonstrate and what stories already exist in the market.
By the end of those conversations I have a picture that the founders themselves often don't have written down anywhere. Where the business is genuinely trying to go. Which constraints are real and which are just inherited assumptions. Where the leverage is concentrated. What the team thinks the strategy is, versus what the founders think the strategy is. Then (and only then) I look at the technology with that picture in mind.
The technical recommendations that come out the other side are different as a result. They're not "here's what good engineering looks like in the abstract." They're "here's the platform investment that supports the commercial model you're actually pursuing, and here's the architectural risk that matters because of where the business is going next." The technology serves the business, not the other way around.
Translating in both directions
The other thing the partnership role demands, which the technical-hire framing doesn't, is fluent translation in both directions.
Founders and boards often need to make decisions that have technical consequences they cannot fully evaluate. Should we rebuild the data layer now or in a year? Is this acquisition target's tech stack going to slow us down? Can we promise the enterprise customer SOC 2 by Q3? These questions don't have purely technical answers. They have answers that depend on commercial priorities, risk tolerance, capital constraints, and where the business is heading. My job is to give the founders the information they need to make those decisions in language they can act on, not buried in jargon, not hedged into uselessness, but clear, complete, and honest.
Equally important is the translation in the other direction. When the engineering team raises a concern that sounds technical, my job is often to translate what they're actually saying into commercial terms the rest of the leadership can engage with. "We have a brittle deployment pipeline" is technical language. "Every release is a coin-flip on whether we have an outage during a sales demo, and engineers are spending one day a week fighting fires that should not exist" is commercial language. Same problem. Two different rooms understand it.
The companies where this translation works well don't experience the technology team and the rest of the business as separate worlds. The engineers feel heard at a leadership level. The leadership feels confident in technical decisions because they understand the trade-offs. Decisions get made faster, with more conviction, with fewer surprises down the road.
A real example, slightly anonymised
A wellbeing platform I worked with had a clear commercial ambition: become the default mental health partner for large enterprise customers. They'd raised a meaningful round and the pressure to land marquee customers was real.
If I'd come in as a pure technical hire, the conversation would have been about platform scaling, multi-tenancy, audit logging, and the engineering hires needed to support the load. All real. All necessary. But the highest-leverage move wasn't any of those things.
The conversation that mattered was about positioning. The enterprise market was about to be defined by AI capability. Not the obvious AI hype, the genuine, embedded conversational and analytical capabilities that would let the platform have a different relationship with employees than the competitors who were just doing static content. That was a commercial insight as much as a technical one. And it pointed to a single hire that would change everything: a senior data scientist with the right background to lead the AI direction.
Making that hire wasn't a technical decision. It was a commercial bet about where the market was going, what customers would value in eighteen months, and what story the next round of investors would need to hear. The technology consequences flowed from there (and they were significant) but the conversation started in the business, not in the codebase. That hire opened a product direction the team hadn't been able to reach before, and the technical positioning became a thread in the investment narrative that followed.
That's what business-first technology leadership looks like in practice. It is not the absence of technical work. It is the presence of business context underneath every technical decision.
Why this changes the relationship
Founders who experience this approach for the first time often describe it the same way: they stop treating me as someone they bring in for the tech, and start treating me as someone they think with. The engagement shifts from contractor to partner. The conversations get harder, more honest, and more useful. The decisions get better.
This matters commercially as much as it matters relationally. A partner gets brought into the rooms where strategic decisions are being made. A contractor gets briefed afterwards. A partner gets to flag a misaligned commercial bet before the engineering plan is locked in. A contractor gets handed a roadmap and asked to deliver it. Both can do good work. Only one of them genuinely changes the trajectory of the business.
It also matters for what gets built. Engineering teams led by a CTO who genuinely understands the commercial picture build different things, sequence them differently, and make different trade-offs than teams led by someone optimising for technical purity. The output looks similar from a distance. The compounding effect over twelve months is enormous.
Where this becomes operational: AI Brain
The "business partner" framing is a way of working. But it has a productized counterpart, and it's the most concrete expression of the same philosophy.
AI Brain is an offering I built specifically for founders who want AI installed into how the business actually runs, rather than treated as a separate technical project. The work isn't generic AI consulting. It starts with the same conversations a fractional engagement starts with: what does your business actually do, where is leverage concentrated, what are the three to five jobs you do every week that consume disproportionate time. Then it installs the systems, skills, and connections that turn those workflows into something the business compounds on, rather than something the founder retypes every Monday.
If the partnership philosophy resonates and you want a smaller, sharper engagement than a full fractional retainer, AI Brain is often the right starting point. It's a four-week Sprint that produces a working system rather than a deck full of recommendations.
The job title says CTO. The work is about being a partner who happens to bring deep technical expertise into the room. If you're looking for someone who'll just take a roadmap and execute it, there are plenty of skilled engineers and engineering managers who'll do that well. If you want someone who'll sit with you, understand the business properly, and help you make decisions that move it forward, that's the engagement worth booking.