The H&R Block engagement started with a question nobody on the technology team had thought to ask: what happens to TaxCut on April 14th at 11 p.m. if the activation web service drops? The product was the flagship retail consumer tax software, the calendar was non-negotiable, and the answer was that nobody knew. That gap, between “we built this” and “we know what it does under load on the day it matters,” is the part of the role most people miss. Day one is not the roadmap. Day one is finding the question whose answer the leadership team thought they had and didn’t.
When I started at LERETA, the second-largest property tax processor in the United States and a four-year engagement that grew into a $20M modernization program with more than 30 developers, I did not open the architecture documents in the first week. I spent it asking what happens to a homeowner when a tax payment is missed. The answer (penalties, escrow shortfalls, legal exposure for the lender) is what made every later technical decision legible. A fractional CTO does not start with a roadmap. The roadmap is an output of month two, not an input on day one.
Here is what a structured fractional CTO engagement actually looks like, from the first day through month six.
journey title The CEO's Clarity Through the Engagement section Orientation Access and listening: 2: CEO Leadership contradictions surface: 3: CEO section Assessment Risk register and findings: 3: CEO Approved roadmap: 4: CEO section Delivery Operating rhythm installed: 4: CEO Vendor savings and hiring calls: 5: CEO section Steady state Board reporting cadence: 5: CEO Knowledge transfer: 5: CEO
Days 1–14: How fast access arrives is itself the first finding
The first two weeks are current-state capture. The point is not to form opinions fast. It is to gather enough raw material to form accurate ones.
Access speed is its own diagnostic
Nothing useful happens before access does. That means the codebase repositories, the cloud consoles, the monitoring and alerting stack, the CI/CD configuration, and whatever documentation exists, plus calendar access and a round of introductions to leadership, the engineering leads, and the vendors who actually run the company’s critical systems. I treat the speed of getting access as its own diagnostic. At one PE-backed company, it took eleven days to get read access to production AWS, and three different people each believed someone else owned the account. That delay was the finding. A team that cannot grant access in a day usually cannot deploy a fix in a day either.
The map operates two altitudes above the code
The opening inventory is a structural map, not a code review: the application portfolio, how the systems integrate, the infrastructure footprint, where the data lives and flows, and which vendor dependencies the business cannot survive without. At LERETA, that map was the difference between “the batch job is slow” and “the nightly tax-file reconciliation has a single point of failure that, if it slips past the 6 a.m. window, cascades into missed client SLAs.” Same fact, two altitudes. The map gets you to the second one. At H&R Block, the same exercise produced a different version of the same insight: the activation web service was treated as one component when in production it was four, with a custom XML provisioning format that only two engineers fully understood. That is not visible from the code. It is visible from the integration map.
The most valuable sentence in any listening session
One-on-one conversations with engineering leads and senior individual contributors in the first two weeks tell you more than any wiki. These sessions surface the thing the team already knows is broken but has never had the authority to fix, the spot where technical debt piled up and the actual reason it did, and the team’s real capacity versus what leadership assumes it is. The most valuable sentence I hear in these sessions is some version of “we flagged that two years ago and nobody listened.” That is rarely a technology problem. It is a decision-rights problem, and naming it is half the work.
Two leaders, two coherent priorities, no shared statement
In parallel, I sit with the CEO and the functional leaders (sales, operations, product) to establish the business priorities technology has to serve. At a health-plan engagement years ago, the CTO and the head of operations each had a coherent technology priority and they directly contradicted each other; neither had said so out loud. Surfacing that contradiction in week two saved a quarter of building toward two incompatible targets. Technology strategy without business context produces elegant systems that solve the wrong problem on time and under budget.
Weeks 2–4: The register opens with three items, not thirty
By the midpoint of the first month the listening turns into structured analysis. This is where two decades of seeing the same failure modes in different costumes pays off directly.
The five risks that matter, and the forty-five that don’t
The technical assessment names specific risks in the current architecture (scalability bottlenecks, single points of failure, security exposure, compliance gaps, vendor lock-in) and scores each on two axes: how likely it is to actually happen, and what it costs the business if it does. The output is a prioritized risk register, not an exhaustive list of every imperfection. That distinction matters. A junior engineer can generate fifty defects. The executive judgment is in declaring which five would take the company down and which forty-five are someone’s aesthetic preference. At LERETA the register opened with three items, not thirty, and all three traced to that 6 a.m. reconciliation window. At H&R Block, the register opened with two: the activation web service had no failover sized for Tax Day, and the custom XML provisioning format had no published spec, so the engineers who could debug it on April 14th were the same two who built it.
Strong engineers, miswired
Separately from the architecture, I assess the team: skill coverage, org structure, process maturity, and who is actually allowed to decide what. The most common finding is not a skills gap. It is strong engineers trapped in a structure that wastes them. No clear ownership, no architecture review, deployment standards that change depending on who is on call. The talent is there. The wiring around it is not. Fixing the wiring is faster and cheaper than the hiring spree most CEOs assume they need, and I will tell them so directly.
A contract clause can veto an otherwise sound design
Plenty of companies signed serious vendor commitments with no technical review in the room. SaaS contracts, cloud spend commitments, and platform licensing routinely carry terms that quietly constrain architecture or detonate financially at renewal. I pull these early because a contract clause can veto an otherwise sound design. On one engagement, a data-platform agreement with an auto-renew and a punitive volume tier had to be unwound before any migration could even be sequenced. The contract, not the code, was the binding constraint.
Month 2: Observation converts into direction the CEO can defend
The output of the assessment phase is a written findings document and a draft technology roadmap. This is the first major deliverable, and the first time the CEO sees the engagement convert observation into direction.
The difference between a fact and a finding
The findings document states the current state in plain language: what works, what is at risk, what is functionally broken. It is not a technical specification. It is a document a CEO, a board member, or an investor can read and act on, with every technical observation tied to a business consequence. “The authentication service has no failover” is not a finding. “A single auth-service outage locks every customer out of the platform with no recovery path under an hour, and we have no runbook for it” is a finding. The first is a fact. The second forces a decision.
Roadmaps that survive the first budget cycle
The technology roadmap sequences the work from current state to target state across three horizons: immediate priorities for the next 90 days, near-term investments across months 4 through 12, and strategic direction on the 12-to-24-month view. Every item ties to a business objective: cost, reliability, scalability, compliance, or new revenue capability. I am deliberate about this because roadmaps that float free of business objectives stall in the first budget cycle. Engineers can execute a roadmap. What they usually cannot do is defend it in front of a CFO, and an undefended roadmap loses its funding the first quarter money gets tight.
Yes or no, not options and drift
I present the findings and roadmap to the CEO and leadership in a session built to produce decisions, not discussion. The top risks, the proposed sequence, the resource implications, and the tradeoffs of choosing one path over another, stated out loud. This is where the advisory part of the role gets real. I am not there to lay out options and let the room drift. I am there to say which path I would take and why, name what we are giving up by taking it, and get a yes or a no. By the end of month two the company should have an approved direction, not an open question.
What sits under the methodology and decides whether anything survives it
Before months three through six, it’s worth naming what sits underneath the structure, because the assessment-to-roadmap-to-execution progression is the visible surface. What determines whether the outputs survive after the engagement ends is something harder to see in the phase descriptions above.
At LERETA, the platform decisions made in year one are still holding the architecture four years later. At First American, the risk register that informed the acquisition decision the fund didn’t proceed with identified issues that no amount of remediation would have fixed before close, and the $120M that stayed in the fund is the outcome. At H&R Block, the SOA re-architecture I shipped on a short, focused contract was still the production stack the following Tax Day, run by the in-house team without me in the room. None of those results came from the methodology. They came from decisions being made for the company in front of me, not for the engagement template, and from the people executing the work understanding the reasoning behind every significant call.
The test for any six-month engagement is whether the work is running without you by the time you leave. The roadmap has to be defensible to the CFO who wasn’t in the room when it was written. The engineering team has to be able to explain the architecture to the next external reviewer. The hiring decisions have to outlast the context that produced them. Designing for your own departure from the first week, not as a final phase but as an orientation, is what separates an engagement that compounds from one that deflates when the invoice stops.
Months 3–4: The phase that separates a fractional CTO from an expensive auditor
With the assessment done and the roadmap approved, the engagement shifts from orientation to execution leadership. This is the phase that separates a fractional CTO from an expensive auditor.
Thirty good engineers, one coherent system
I establish or repair the engineering operating rhythm: the weekly sync, sprint planning and review, an actual architecture review process, and deployment standards that do not depend on who is awake. The aim is not process for its own sake. It is the predictability and communication structure that lets a team move faster without quietly taking on new debt. At LERETA, a program with 30-plus developers, the rhythm was the load-bearing wall. Without a standing architecture review, thirty good engineers will generate thirty locally reasonable decisions that do not add up to one coherent system.
Fifteen minutes of writing now, a year of relearning later
For every consequential technical call made during the engagement, I get the team documenting architecture decision records: short notes capturing what was decided, why, what alternatives were weighed, and what the tradeoffs were. This is unglamorous and it is the institutional memory that pays off when the team doubles, when a vendor asks a question nobody remembers the answer to, or when the next assessment lands. The cost is fifteen minutes per decision. The cost of not having it is relearning your own architecture from scratch a year later.
The asymmetry at the vendor table
I take an active role in vendor relationships, negotiating contracts, evaluating new platforms, managing providers who are underperforming. Having sat on the enterprise side of large vendor relationships at companies like First American and across health-plan environments, I know how much leverage buyers leave unused. On one engagement, repricing and consolidating two overlapping infrastructure contracts cut six figures of annual spend without touching a line of production code, money that went straight back into hiring. Vendors negotiate these deals every day. The company across the table does it once every few years, and the asymmetry shows up in the terms.
Recommending against the hire the CEO is excited about
If the assessment found team gaps, and it almost always does, months three and four are when hiring gets scoped and executed. I write the role requirements, screen candidates at the technical level, and give a recommendation. For leadership roles like an engineering manager or VP of Engineering, I sit in the final round and put a written evaluation on the table. I am also willing to recommend against a hire the CEO is excited about. Talking a founder out of a premature, expensive VP of Engineering hire, when the real gap was a senior engineer and a clearer org structure, has saved more than one company a six-figure mistake and a painful unwind.
Months 5–6: A board can spot the missing translation in ninety seconds
By month five the engagement should be in productive steady state: the critical risks addressed, the team pointed in one direction, and a working technology leadership function in place.
Translating engineering into the language a board decides in
For companies with investor boards, the quarterly technology presentation is a standard deliverable, and I prepare and deliver it. Current state against the roadmap, an updated risk register, the consequential decisions and their rationale, and the forward investment plan. Translating engineering reality into the language a board actually makes decisions in is its own skill, and it is one a board can spot the absence of in about ninety seconds. At Marshall & Swift, the real-estate cost-data company, the executives had been making investment decisions off summary reports that hid the operational detail underneath. The reporting hierarchy itself was the obstacle. Rebuilding it so executives could see the forensic-level detail that had not previously existed changed which decisions they could make in the room, not just the data they were looking at. Board-grade reporting is the same exercise: not more data, the right altitude. For a company raising capital, this extends to building the technology section of the investor data room and sitting across from the acquirer’s or investor’s technical diligence team, a role I have played from both the operator’s chair and as the diligence reviewer, which is exactly why I know what that room is hunting for.
The fork at month six, and the answer that shortens my own engagement
By month six, most companies hit a deliberate fork: hire a full-time CTO, extend the fractional engagement, or promote someone internally into the role. I should be the person helping the CEO reason through that clearly, including, honestly, whether my own engagement should continue, wind down, or transition out. A fractional CTO who pushes a company to extend regardless of whether it serves the company has stopped working for the company. For an early-stage startup with a stabilized stack and a strong internal lead, the right answer is frequently to promote and let me step back to a lighter advisory cadence, and I will say so even though it shortens my own engagement.
The single obligation an engagement cannot fail
If the engagement is transitioning, to a new full-time hire or to a lighter advisory structure, the final phase is structured knowledge transfer: system documentation, the rationale behind the decisions, the context on vendor relationships, the team assessments, and the roadmap status at the moment of handoff. The test is simple. The company should hold more institutional knowledge the day I leave than the day I arrived, not less. An engagement where the knowledge walks out the door with the consultant has failed its single most important obligation, however good the intervening quarters looked.
What an accountable engagement actually produces at each stage
Written deliverables at each phase are what separate an accountable engagement from a relationship that produces meetings and no outcomes. By the end of month one there is a written, business-readable current-state assessment. By the end of month two, an approved roadmap with sequenced priorities. By the end of month three, an engineering operating rhythm in place and the top risks in active remediation. By the end of month four, the team structure updated where it needed to be and the key vendors re-evaluated. By the end of month six, the board presentation delivered, the leadership-hiring decision made, and the direction of the engagement itself confirmed.
Companies that hold the fractional CTO to these outputs, and hold themselves to the leadership alignment those outputs require, consistently get more out of the engagement. The accountability runs both directions.
To see this engagement model in practice across fintech, healthcare, and real estate sectors, the case studies page covers specific client work. To discuss how a structured engagement would apply to your situation, contact me directly.
