The First American review led to recommending that a roughly $100M acquisition not close. The recommendation came from a code-level and data-level examination of the target — documentation that described a capable platform, production reality that didn’t match it. Making that call required being willing to stake the analysis against what the organization wanted to hear.
That is one type of fractional CTO decision. Understanding the full taxonomy of what a fractional CTO should and shouldn’t own changes the quality of the engagement.
stateDiagram-v2 direction TB state "Decision identified" as ID state "Technical analysis" as AN state "Business context established" as BC state "CTO owns — technical call" as OWN state "CEO/board owns — business call" as EXEC state "Collaborative — both frames needed" as COLLAB state "Deferred — needs more information" as DEFER [*] --> ID ID --> AN AN --> BC BC --> OWN: Architecture,<br/>vendor, security BC --> EXEC: Headcount, budget,<br/>org structure BC --> COLLAB: Roadmap sequencing,<br/>build vs. buy BC --> DEFER: Unresolved context OWN --> [*] EXEC --> [*] COLLAB --> [*] DEFER --> AN
What the Fractional CTO Has to Own
The decisions a fractional CTO must own are the ones that require technical authority and can’t be made by committee.
Architecture direction. Which system does the organization build on, and which one gets replaced? How is the data model structured? What’s the integration approach? These decisions have long time horizons and are expensive to reverse. They require someone with both technical depth and accountability for the outcome. A fractional CTO who defers architecture decisions to the engineering team without providing direction has abdicated the role.
At LERETA, one of the hardest calls was the recommendation to start from scratch rather than retrofit an acquired Texas company’s technology into the flagship product rebuild. The data structures differed. The processing logic was fundamentally different. Retrofitting looked faster and cheaper at the outset. The recommendation was to build clean — which required a longer investment case to the board and created friction with the teams who had already committed to the retrofit path. The right call is still the right call when it’s unpopular.
Vendor and technology evaluation. When the organization is deciding between two enterprise software platforms, two cloud providers, or two AI infrastructure approaches, the fractional CTO owns the technical half of that decision. The business side is shared. The technical reality — what the organization can actually integrate, maintain, and scale — is the fractional CTO’s call.
Technology risk. Security posture, architecture vulnerabilities, technical debt that creates operational risk — the fractional CTO is the person responsible for naming these clearly and holding the line on what level of risk is acceptable. Being the person who says “we cannot go to production with this” when the business wants to ship is uncomfortable. It’s the job.
What Isn’t the Fractional CTO’s Decision
Headcount decisions, compensation, organizational structure, and budget allocation belong to the CEO and the leadership team. A fractional CTO can and should provide input on the technical implications of those decisions. They should not make them.
The distinction matters because a fractional CTO who takes on decision authority in areas that belong to the permanent leadership team creates organizational conflict that undermines the technical work. The engineering team starts reading decisions as “the outside person running things” — which is rarely true and always corrosive to the trust the technical work depends on.
The test is simple: does this decision primarily require technical judgment, or does it primarily require organizational authority? Architecture is technical judgment. Headcount is organizational authority. When both are in play — roadmap sequencing, build vs. buy, which engineering initiatives to prioritize against product commitments — the decision is collaborative, with the fractional CTO providing the technical frame and the CEO providing the business frame.
The CloudVirga Forcing Function
At CloudVirga, the development team was working inside virtual machines that had a three-to-four-second response lag on every keystroke. The developers were frustrated. The team’s output was constrained by the environment.
I raised the issue to senior directors. The organizational default was to manage around it. I pushed harder — not as a suggestion, but as a position: replace the hardware or accept the velocity cost. The machines were replaced. Team morale improved immediately.
That was a decision the fractional CTO had to own. It wasn’t pure architecture, but it was the technology environment — the conditions that determine whether the engineering team can execute. The resistance was organizational inertia, not a legitimate business case against the change. Knowing which kind of resistance you’re dealing with — inertia vs. a competing priority with real merit — determines how hard to push.
The First American Call
The $120M acquisition walk-away at First American came from a straightforward analysis: what the platform was described as doing and what it actually did were different. The documentation described a service-oriented architecture. Production was monolithic applications with service-shaped wrappers, on a database schema that had drifted significantly from what was documented. Data quality at the row level didn’t match the aggregate-level claims that justified the valuation.
The fractional CTO’s job in that situation is to say what the evidence shows. Not to manage the conclusion toward what the organization wants to hear, not to hedge with qualifications that make the uncomfortable finding deniable, but to present the technical reality clearly and let the decision-makers decide what to do with it.
First American had acquired more than 80 companies in the prior decade and was carrying roughly 700 software applications across 15 subsidiaries — overlapping systems, redundant pipelines, integrations that had been promised post-close and never finished. That context shaped the recommendation. The cost of closing on a platform that didn’t match its description was knowable, and it wasn’t small.
That’s the category of decision the fractional CTO has to own: the technical assessment, presented clearly, regardless of what conclusion it points toward. The business decision of what to do with that assessment belongs to the CEO and the board. But the assessment itself is the fractional CTO’s responsibility, and softening it to avoid discomfort is a failure of the role.
