The most valuable output of my engagement at LERETA — a five-year embedded role supporting a $20M board investment in platform modernization — was not code. It was not architectural design, though that mattered. It was a wall-sized enterprise architecture diagram that made the full legacy-modernization picture visible for the first time.
That document became known as the Livermore Report. The CTO and the board had a name for it. What it did was take an extremely complex technical situation — two flagship software products, a mainframe migration critical path, years of accumulated decisions that no one had mapped end-to-end — and make it visible at a scale where decision-makers could see what they were being asked to invest in. Before that diagram existed, the modernization was a project. After it, the board understood the full shape of the investment and what the organization would have on the other side.
timeline
title Fractional CTO Engagement Phases
Phase 1 — Map : Current-state audit
: Architecture documentation
: Risk identification
Phase 2 — Align : Roadmap development
: Board presentation
: Investment case
Phase 3 — Execute : Operating rhythm
: Delivery oversight
: Vendor decisions
Phase 4 — Sustain : Ongoing governance
: AI integration oversight
: Succession planning
The Problem Most Companies Are Actually Hiring For
Companies hire fractional CTOs to solve what looks like an implementation problem. The development team is too slow. The architecture decisions are bad. The vendor selection process produces wrong answers. The AI initiative is not going anywhere. Fix the implementation and the company moves forward.
That framing is usually incomplete. The implementation problem exists, but it sits inside a larger alignment problem: leadership does not have a clear picture of what the technology stack actually is, what it can support, what it would cost to change it, or what the decision tradeoffs are. Without that picture, every implementation decision gets made in partial context.
The fractional CTO’s highest-leverage work is building that picture. Directing the implementation matters, but it is downstream of the alignment problem. Making the technology situation legible to the people who have to make decisions about it — that is the work that unlocks everything else.
Why Alignment Is the Bottleneck
Engineering teams are almost always capable of building what they are asked to build. The constraint is that they are often asked to build the wrong things, or asked to build the right things without the organizational support that would let them execute well. Both are alignment problems, not implementation problems.
The wrong things get built when leadership’s priorities and the engineering team’s priorities are not reconciled against the same technical picture. A roadmap the engineering team produced without executive input often does not match what the business actually needs. A roadmap that leadership created without technical input often underestimates what is difficult and overestimates what is possible in the available time. The reconciliation between those two views is the fractional CTO’s job, and it requires being trusted by both sides simultaneously.
The right things do not get built well when organizational support is missing: when the board has not committed to the investment the roadmap requires, when the executive team is not aligned on the priority, or when the engineering team does not understand why the work matters. Architecture diagrams that make the picture visible at the board level unlock that support. Without them, the roadmap is a plan that nobody outside engineering has actually signed off on.
What This Means for Evaluating an Engagement
If you are evaluating a fractional CTO engagement, the question to ask is not primarily “how much implementation experience does this person have.” The question is “how have they made technology decisions legible to non-technical leadership, and what happened as a result.”
Look for board-level communication examples: roadmaps, architecture documentation, investment cases built around technical decisions. Look for instances where the fractional CTO’s involvement changed the level of organizational confidence in a technical direction, not just improved the code quality. Implementation quality matters. The alignment work is what makes the implementation matter to the business.
The Pattern Repeats
This pattern shows up across engagement types. In M&A technical due diligence, the work that prevented a nine-figure mistake at First American Financial was not just the technical finding. It was the finding communicated in a way that gave decision-makers the confidence to act on it before the check cleared. In modernization work, the value is not the new architecture alone. It is the roadmap that aligns the organization around what the new architecture requires and what the investment will produce.
Implementation follows alignment. The fractional CTO’s job is to make the alignment possible — and then stay to ensure the implementation reflects it.
