# Fractional CTO or full-time CTO for AI transformation > Compare a fractional CTO or full-time CTO for AI transformation by authority, monthly cost, hiring lead time, and four permanent-hire tests. A capable delivery lead changes the CTO decision. You no longer need an executive to run standups, chase tickets, or translate a roadmap into weekly work. You need someone to decide which technical bets the company will make, set the limits around AI-assisted delivery, and hold product, engineering, security, and finance to the same operating model. For most companies in that position, a fractional CTO is the better first move. The role can carry real authority without adding a permanent executive before the company knows what the transformation demands. Hire a permanent CTO when the work creates a continuing executive job, not because the words "AI transformation" sound too serious for a part-time appointment. That answer depends on four things: what decisions the CTO owns, the economic cost of each option, how long the company can wait, and whether the new operating model needs a resident executive after the change. Get those right and the employment label becomes almost boring. Get them wrong and either choice will fail. ## The delivery lead changes the hiring question A strong delivery lead already owns the flow of work. That person turns priorities into a delivery plan, removes day-to-day blockers, keeps releases moving, and tells the truth when scope and capacity do not match. Adding a permanent CTO above that role can help, but only if there is a separate executive job to do. Founders often mix four jobs into one CTO title. They expect technical strategy, people management, delivery management, and senior architecture from the same person. AI adoption makes the mix worse because every stalled pilot gets called a strategy problem. In practice, many stalls come from weak acceptance criteria, unsafe access, missing evaluation data, or nobody changing the review process. A capable delivery lead can own several of those corrections once an executive sets policy and resolves companywide tradeoffs. The useful distinction is between decision flow and work flow. The delivery lead owns work flow: what enters the team, who takes it, what blocks it, and when it ships. The CTO owns decision flow: which constraints apply, who may accept which risks, when a local tool becomes a company standard, and which technical investment outranks a near-term feature. Both roles need authority, but they need different authority. Use that split to inspect the actual gap. If the founder still spends hours arbitrating tools, architecture, security exceptions, hiring profiles, and product tradeoffs, there is an executive gap. If those decisions occur in a concentrated transformation program and then settle into a repeatable policy, fractional leadership fits. If they arrive every day because technology is the business and the choices keep changing company direction, the job may be permanent. Do not promote the delivery lead into a shadow CTO without changing the mandate. That creates accountability without power. The lead gets blamed for cloud cost, AI risk, and technical debt while product and finance can override every preventive action. Keep delivery ownership where it works, then give the CTO a written set of decisions that no other manager can casually reverse. ## Authority comes from a mandate, not an employment contract A fractional CTO can have more usable authority than a permanent executive whose scope stays vague. Authority comes from a founder or board mandate, access to the relevant information, a defined decision path, and visible support when a decision costs another function time or money. Payroll status supplies none of those by itself. Write the mandate before interviewing either kind of CTO. It should name decisions, limits, consultation duties, and escalation rules. A practical version can fit in a small configuration block: ```yaml technology_authority: owner: cto decisions: - ai_tool_approval - production_architecture - engineering_org_design - security_exception_acceptance delivery_lead_owns: - sprint_commitment - release_sequence - blocker_resolution - delivery_metrics consult: - founder - product_lead - security_owner - finance_owner escalation: trigger: decision_exceeds_approved_budget_or_risk_limit final_owner: ceo review_after_days: 90 ``` This is not ceremony. It prevents the common failure in which a CTO recommends one AI coding environment, a product manager buys another, engineers use personal accounts, and the delivery lead must support all three. The mandate makes tool approval an owned decision. It also prevents the CTO from meddling with every sprint simply because the title is senior. The limits matter as much as the decisions. A CTO should not accept legal risk that belongs to the CEO, sign off on privacy questions without counsel, or quietly change a product promise. The mandate should state where the executive recommends, where the executive decides, and where the founder decides after receiving written options. NIST's AI Risk Management Framework treats Govern as a function that runs across Map, Measure, and Manage. That is a useful correction to the idea that governance means a final approval meeting. In an engineering transformation, governance lives in tool access, data rules, model evaluation, review thresholds, incident ownership, and the evidence retained after a release. The CTO designs that system; the delivery lead makes it operate during ordinary work. Test authority during interviews. Give the candidate a disagreement: product wants AI-generated migrations shipped this week, engineering wants another test cycle, and a customer contract restricts how production data can be used. Ask what the candidate decides, what evidence they request, and what they escalate. A candidate who answers only with stakeholder alignment has not shown executive judgment. A candidate who dictates a technical answer without checking the contract has not shown it either. ## Compare economic cost, not invoices and salary The clean comparison is monthly economic cost for the result you need. A fractional invoice and a permanent salary are different units, so placing them side by side hides recruiting cost, benefits, bonus, equity, management time, unused capacity, and the cost of waiting for the permanent hire. For the fractional option, calculate the retainer, any separate project fees, internal time required from the founder and delivery lead, and implementation work outside the retainer. The AI transformation leadership described on oleg.is starts at $5,000 to $10,000 per month. Treat that as the leadership line, not the whole transformation budget. Engineers still need time to change tests, permissions, pipelines, and working agreements. For a permanent CTO, use your actual offer assumptions. This small model stops salary from becoming a misleading shorthand: ```text monthly permanent CTO cost = annual base / 12 + target annual bonus / 12 + employer taxes and benefits / 12 + annualized recruiting cost / 12 + expected equity cost / 12 + executive support and travel ``` Suppose a founder enters an annual base of $300,000, a $60,000 target bonus, $45,000 in employer costs, and $60,000 in recruiting cost allocated across the first year. Before equity or support, the model returns $38,750 per month. That is an example calculation, not a market rate. Replace every input with a quote or policy from your own company. Now price vacancy. If delayed AI controls expose customer data, if architecture decisions block enterprise sales, or if engineering payroll remains oversized while the search runs, waiting has a monthly cost. Conversely, if the delivery lead can execute the current roadmap safely and the founder can make the few remaining decisions, urgency may be manufactured. A search does not become wise because the board approved a large budget. Also price role mismatch. A permanent CTO who spends most of the week checking tickets is expensive delivery management. A fractional CTO who attends a monthly call while teams invent policy is expensive advice. Compare the cost of a properly designed role, not the cheapest contract for each label. Equity deserves direct treatment. Founders sometimes regard equity as free because it does not leave the bank account this month. It buys long-term commitment and shares long-term upside, which can make sense for a permanent executive building company value over years. It is poor payment for a bounded transformation that should produce an operating model within months. Include equity in the decision even if your accounting treatment differs. The right unit is cost per resolved executive constraint. List the decisions currently trapped with the founder, the risks nobody owns, and the organizational changes the delivery lead cannot authorize. Then ask what each option costs until those constraints disappear. A smaller retainer is not cheap if the mandate excludes the hard decisions. A larger permanent package is wasteful if the executive job largely ends after the transformation. ## Hiring lead time is part of the technical plan A fractional CTO usually has a shorter path to useful work because the company checks availability, agrees scope, completes diligence, and signs a services contract. A permanent search adds role design, sourcing, several interview rounds, references, offer negotiation, notice time, and a longer organizational onboarding. Plan with those components rather than repeating a generic estimate about how many months executives take to hire. Lead time starts when the company recognizes the decision gap and ends when the CTO can make a consequential decision with enough context. A signed contract is not the finish. If customer obligations, system diagrams, cost data, team history, and current incidents remain scattered, either type of CTO will spend the opening weeks reconstructing the company. Make the comparison on one page. For each option, put an owner and expected date beside these events: mandate approved, candidate available, diligence complete, access granted, team interviews complete, first decision issued, first operating change live. Use recruiter evidence and named candidate availability for dates. Do not put invented market averages into a board plan. The cost of delay should influence the sequence, not force a rushed permanent hire. A sound pattern is to appoint a fractional CTO for the transformation and decide separately whether to open a permanent search. The fractional executive can clarify the role, expose the real decision load, and leave evidence for the search. The arrangement becomes dangerous only when the temporary leader has an incentive to make the permanent job look unnecessary or to shape it for themselves. Address that conflict in the contract and ask the founder or board to own the final hiring decision. Beware the opposite delay as well. Some founders keep renewing a fractional arrangement because a permanent search feels disruptive. Set a review date when the mandate begins. At that review, examine decision frequency, response requirements, team dependency, and the next two quarters of company strategy. If the role has become continuous and internal, start the search even if the fractional relationship works well. A capable delivery lead reduces onboarding time for both options. The lead can supply delivery history, current commitments, failure patterns, and a map of informal authority. That advantage disappears if the lead feels inspected or replaced. Tell the lead what stays in their role, what moves to the CTO, and how performance will be judged before the first executive interview. ## A fractional CTO should leave an operating system The fractional engagement should produce decisions and a company that can keep making them. If progress depends on the CTO joining every meeting forever, the engagement created dependency instead of a management system. The first output is a decision inventory. Record recurring choices about AI tools, data exposure, model selection, human review, architecture, vendors, hiring, and release risk. For each one, name the owner, required evidence, response time, and escalation point. The delivery lead should be able to route an issue without guessing which executive happens to be online. The second output is a small set of working controls. These might include approved account types, prohibited data classes, evaluation requirements for generated changes, review rules by risk, and incident steps when an AI tool exposes or corrupts information. The exact controls depend on the company. A policy copied from a large bank will fail in a small software business if nobody can execute it. The third output is changed economics. Track the baseline before reducing headcount or promising faster delivery: payroll by function, work completed, escaped defects, incident load, review time, cloud and model spend, and founder hours spent on technical arbitration. Choose measures that reveal both speed and damage. Counting generated code or tool seats rewards activity, not company output. The fourth output is a leadership handoff. The delivery lead needs a clear operating cadence, access to decisions, and permission to reject work that violates an approved control. The founder needs a short report on cost, risk, disputed choices, and decisions that still require executive judgment. Future hires need an explanation of why the model works, not a folder of unexplained templates. Make knowledge transfer observable. Ask the delivery lead to run the decision meeting while the CTO watches. Ask an engineer to follow the incident path without private coaching. Give the founder a new vendor proposal and see whether the approval rules produce a clear answer. A document nobody can use without its author is unfinished. A fractional CTO can also recommend a permanent successor. That recommendation carries more weight when the engagement has measured the actual job: how many executive decisions occur, how quickly they need answers, which relationships require continuity, and what expertise is missing internally. It carries less weight when it rests on a standard job description with fashionable AI terms added. ## Four conditions justify a permanent CTO A permanent CTO makes sense when the company needs continuing executive presence after the initial operating model exists. Four conditions justify that commitment. One condition can be enough if it is strong; several weak signals do not become a case merely by accumulation. ### Technology choices change company strategy every week Hire permanently when technical choices repeatedly change the product, market, financing plan, or risk accepted by the company. Examples include a company whose core product depends on proprietary model behavior, a platform deciding which capabilities become public contracts, or a business where infrastructure economics determine gross margin. These are not periodic architecture reviews. They are company decisions with technical content. The delivery lead should not absorb this work. Asking that person to ship the roadmap and continuously redefine the company's technical position creates a conflict between predictable delivery and strategic change. A fractional CTO can cover a concentrated period, but the calendar will expose the mismatch if founders need executive judgment across most working days. Use decision records as evidence. Over six to eight weeks, log decisions that required founder or board involvement, changed a commercial commitment, moved material budget, or accepted company risk. Remove routine architecture and delivery choices. If the remaining list is frequent, time sensitive, and central to company direction, there is a resident role. ### A named executive must carry continuous external accountability Hire permanently when customers, regulators, insurers, investors, or partners require a technology executive who knows the systems deeply and can answer continuously for controls and incidents. The important word is continuous. A fractional executive can prepare an audit, repair governance, and join major reviews. That may not satisfy a business where executive accountability forms part of every large sale or regulated operation. Do not infer this condition from anxiety. Read the contract, regulation, insurance requirement, or diligence request. Identify what must be attested, who may attest it, how quickly that person must respond, and whether an external or fractional officer qualifies. Counsel should resolve legal interpretation. The CTO should design the technical evidence and ensure the company can produce it. A title alone does not meet the condition. Hiring a permanent CTO without control over security budget, architecture, incident response, or vendor commitments gives customers a spokesperson instead of an accountable executive. Expand the mandate or keep the responsibility with the executive who already has the power. ### The leadership bench needs daily executive development Hire permanently when several engineering and technical product leaders need sustained coaching, performance decisions, succession planning, and organizational design. A fractional CTO can assess the structure and coach leaders, but some teams need daily observation to distinguish a temporary delivery miss from a management pattern. This condition often appears after growth, a merger, a major product expansion, or repeated changes in senior staff. The evidence is not headcount by itself. Look for decisions that cross teams, managers optimizing against one another, unclear promotion standards, unresolved ownership between product and engineering, and technical leaders who cannot get founder attention when tradeoffs turn political. Do not turn the permanent CTO into the manager of every engineer. The executive should build a leadership bench that carries local management. If all decisions still climb to the CTO after a year, the design has centralized authority without developing the organization. ### The company is hiring a long-term technical counterpart to the CEO Hire permanently when the CEO needs a peer who will shape the company for several years, share responsibility with the board, recruit senior leaders, represent technology in financing or major sales, and live with the consequences of earlier decisions. This is a relationship and time-horizon condition, not a workload calculation. Equity fits this case because the executive helps create value beyond the transformation. Deep company knowledge also compounds: the CTO learns why customers buy, which technical compromises are survivable, where the team has scar tissue, and when an apparently rational rewrite would destroy momentum. Founders sometimes claim to want this counterpart while writing a mandate limited to engineering delivery. That job will attract an operations leader or a senior engineering manager with a grander title. If the CEO will keep product strategy, architecture vetoes, senior hiring, and board communication, the company is not offering a CTO role. Fix the authority before paying for permanence. ## The CTO and delivery lead need a hard boundary The most expensive failure is overlapping authority. It starts politely: the CTO joins planning to learn, suggests a different sequence, and asks engineers for estimates. The delivery lead adjusts. Product then takes ideas directly to the CTO because the answer arrives faster. Within weeks, the team has two queues and every missed commitment can be blamed on the other leader. I have seen the same pattern around AI tools. The CTO asks one engineer to test an agent on a real repository. The delivery lead does not know the experiment changed review load. Generated changes enter a release, reviewers fall behind, and planned work slips. The tool may be useful; the failure came from running a technical experiment outside delivery capacity and release ownership. Set the boundary around decisions, not meetings. The CTO may define which repositories an agent can access, what evidence a generated change needs, and what risk level requires extra review. The delivery lead decides when the experiment enters the plan, who has capacity, and which release can absorb it. If product wants to accelerate the date, the delivery lead owns the new delivery forecast while the CTO protects the risk limit. Use one shared decision log. Each entry should contain the decision, owner, date, evidence, affected work, review date, and reversal condition. Keep architecture essays elsewhere. The log exists so a manager can answer, "Why are we doing this, and who can change it?" without replaying six meetings. The founder must enforce the boundary. If the founder bypasses the delivery lead for a favorite feature or asks the CTO to approve routine sprint changes, both roles will copy that behavior. Correct the route in public and discuss performance in private. People believe the operating model they see under pressure. Conflict is healthy when the escalation path is clear. A delivery lead should challenge a control that makes releases impractical. A CTO should challenge a plan that hides risk to preserve a date. They should bring the founder a written choice only when the decision exceeds their mandates, not whenever they disagree. ## Use a 90-day test before making the role permanent A 90-day fractional mandate gives the company enough time to expose recurring decisions, install basic controls, and see whether the delivery lead can run the resulting model. It is not a trial employment arrangement unless both parties explicitly want that. It is a reversible way to learn what executive role the company actually has. 1. In the first two weeks, inventory decisions and establish baselines. Interview the founder, delivery lead, product owner, engineers, security owner, and finance owner. Record where work waits for a decision, which AI tools and accounts are in use, what data they can reach, how generated work gets reviewed, and what the current delivery and incident measures say. 2. During the next month, issue the mandate and change the work system. Approve or reject tools, define data and review limits, assign incident ownership, and move decision rights out of founder conversations into the shared log. Let the delivery lead schedule implementation and report when controls consume more capacity than planned. 3. In the following month, run the model under pressure. Use a real release, vendor choice, production incident, or customer request. Observe response time, evidence quality, escalation volume, and whether people follow the route without private reminders. Repair the system where ordinary work defeats the written design. 4. In the final weeks, transfer operation and make the role decision. The delivery lead runs the cadence. The founder handles escalations from the mandate. The CTO records unresolved strategic work, continuing external duties, leadership gaps, and decisions expected during the next two quarters. Agree on exit criteria at the start. A good fractional exit means recurring decisions have owners, controls operate without the CTO in every meeting, the delivery lead can protect both flow and policy, and the founder receives a compact exception report. A good permanent-hire recommendation means the evidence matches at least one of the four conditions above and the proposed mandate contains real executive authority. Do not judge the test by a pile of AI-generated output. Judge it by business work shipped, defects and incidents, cycle and review time, total engineering and model cost, customer constraints met, and founder decision load. Some metrics will move slowly. The important evidence is whether the company can explain changes without selecting only the flattering numbers. A Team & AI Audit can cover the diagnostic opening: five business days at a fixed $5,000, with at least $50,000 per year in identified savings or the audit is free. That offer is useful when the company wants evidence before committing to the 90-day mandate, but the founder still has to grant access to the uncomfortable cost and workflow data. At day 90, choose among three honest outcomes. End the engagement because the operating model works. Extend a bounded fractional mandate because specific transformation work remains. Open a permanent search because the company now has a continuous executive job. An automatic retainer renewal is not a decision. ## Choose the role by reversibility A fractional CTO is the default when a capable delivery lead can operate the work system and the missing executive decisions can be defined as a transformation mandate. It costs less to test, starts through a shorter contracting path, and preserves the option to design a permanent role from evidence. Those advantages disappear if the fractional leader lacks authority or availability when decisions matter. A permanent CTO is justified when technical strategy changes company direction continuously, external accountability needs a resident officer, the leadership bench needs daily executive development, or the CEO is hiring a long-term technical counterpart. Permanence buys continuity and accumulated context. It should not buy an impressive title for work the delivery lead already does. Write the authority matrix now, before choosing a person. Price both roles with the same economic model. Put each lead-time event on a calendar and name its owner. Then collect 90 days of decisions. The pattern in that log will tell you whether the company needs a transformation executive for a defined period or a CTO who will still have a full executive job after the new system becomes ordinary.