Fractional CTO is a title with no agreed definition. It is used for a hands-on engineer working part time, for an advisor who joins a monthly call, and for genuine executive technical leadership purchased in slices. The three are often priced similarly and produce entirely different outcomes. This page sets out the work that actually requires a senior technical leader, the engagement shapes under which that work gets done, how to tell a real practitioner from a title, and the fairly common case where you should buy something else instead.
The work that genuinely requires a senior technical leader
The test is not seniority for its own sake. It is whether a decision is expensive to reverse, crosses the boundary between the business and its systems, and will be lived with for years by people who were not in the room when it was made. Six kinds of work meet that test.
Deciding build versus buy, and defending the decision
This is the decision that sets your cost structure for the next five years, and it is usually made by whoever is loudest in the meeting. Doing it properly means understanding where the operation genuinely differs from the market, what an off-the-shelf platform will refuse to do, and what the workarounds will cost in labor. A fractional leader should be willing to conclude that you should buy, and should say so in writing.
Setting an architecture direction the team can follow
Architecture leadership is not producing a diagram. It is making a small number of constraining choices (data ownership, service boundaries, where state lives, what the team is not allowed to add) and writing them down clearly enough that an engineer hired six months from now makes a consistent decision without asking. A direction that only exists in one person's head is not a direction.
Vendor selection and contract review
Someone has to read the statement of work and notice what is excluded, ask how data migration is priced, and check who owns the code and what happens on termination. Commercial and technical judgment have to be in the same head for this to work. A procurement process without technical review buys the best proposal writer.
Hiring and evaluating engineers
Non-technical founders and operators cannot reliably assess technical candidates, and the cost of a wrong senior hire is high. This work is designing the interview loop, running the technical assessment, calibrating what good looks like at each level, and giving an honest read on the engineers you already employ.
Establishing how work is estimated and released
Most teams that appear to have a delivery problem have an estimation and release problem. Setting up how work is broken down, how it is sized, how it gets to production, and what has to be true before it ships is unglamorous and changes more than any tooling decision. It is also the area where a leader can leave behind a working practice rather than a dependency.
Translating between the business and its technology
The recurring failure in operational software is not bad code. It is that the people who understand the work and the people building the system never share a vocabulary. Someone senior has to sit on both sides, turn an operating constraint into a technical requirement, and tell an owner plainly which of their requests is cheap and which one quietly costs six figures.
What it is not
Most disappointing engagements are the result of buying one of these three things while believing you bought technical leadership.
- Not a part-time engineer. A leader who spends their days in the codebase is doing individual contributor work at a leadership price, and the decisions you hired them for do not get made. If you need code written, hire or contract engineers.
- Not a project manager. Tracking status, chasing tasks, and running standups is real work, but it is cheaper work with a different skill set. A technical leader whose output is a status report is being used badly.
- Not a permanent arrangement. The role exists because you need executive-level judgment more often than you need an executive. If nothing has changed after a year (no decisions closed, no practice established, no internal capability increased), the arrangement has become a subscription.
Many companies do not need one
The honest version of this page has to include the cases where the answer is no. A fractional technical leader is useful when the problem is a decision, a practice, or an evaluation. When the problem is that a specific thing needs to get built and put into production, you are better served by a delivery partner who owns the outcome and has a senior technical lead attached to the work by default.
| Problem | Is a fractional technical leader the right answer? | Better alternative if not |
|---|---|---|
| Deciding whether to build or buy a system the business will run on | Yes, as a bounded decision rather than a standing role | Not applicable |
| A defined product or platform needs to be built and you have no engineers | No | A delivery partner who owns the outcome, with a named senior lead on the work |
| Releases are unpredictable and nobody owns estimation or quality | Yes | Not applicable |
| Two systems need to stay in sync and the data between them is a mess | No | An integration engagement with defined data contracts, monitoring, and failure handling |
| You are about to hire your first engineers and cannot evaluate candidates | Yes, as a bounded mandate with the hiring process as the deliverable | Not applicable |
| A vendor relationship has gone bad and the project is late | Sometimes, if the open question is whether to continue | A rescue engagement that takes ownership of delivery and states what it will finish |
| The board has asked for a technology strategy document | Rarely | A costed delivery sequence written by whoever will be accountable for delivering it |
The two are not mutually exclusive, and the sequence usually runs one way. A short leadership engagement decides what to do and how to buy it; a delivery engagement does it. Problems appear when the leadership engagement continues indefinitely alongside the delivery it was meant to set up.
The engagement shapes that work
Two structures hold up in practice. Both start from an output rather than an amount of time.
Fixed days per month against named deliverables
A set number of days each month, with the deliverables for the next quarter written down before it starts: the architecture decisions to be closed, the hiring loop to be running, the vendor review to be complete. Days are the budget, not the product. Suitable when there is ongoing technical decision-making and an internal team to work with, and it should be reviewed on a fixed cadence with an explicit option to stop.
A bounded mandate
A single objective with a defined end: get a technical hiring process in place, decide whether to replace the core platform, assess the existing team and system, or select and contract a delivery vendor. Cost and duration are agreed up front, the outcome is a thing you keep, and the engagement ends. This is the shape to start with if you have never bought technical leadership before, because it is easy to judge afterward.
- Name the deliverables for the period, not the hours
- State which decisions the leader can make alone and which need you
- Set the review point and the condition for stopping
- Agree that written artifacts, including decisions, standards, and interview loops, belong to you
- Identify who internally is being handed the practice at the end
How to tell a real one from a title
The market has no credential, so you are evaluating judgment directly. These questions surface it quickly.
- 1
Ask about a build-versus-buy decision where they recommended buying. If they have never talked a client out of building, they are selling something.
- 2
Ask what they will produce in the first 30 days. A serious answer names artifacts and decisions, not meetings.
- 3
Ask how the engagement ends and what has to be true for you to stop paying. Hesitation here is the answer.
- 4
Ask what they got wrong on a previous engagement and what it cost the client. Specific, unflattering answers are a good sign.
- 5
Ask them to review something real before you sign (a vendor proposal, an architecture, a job description) and see whether the feedback is concrete.
- 6
Ask how many other clients they hold at the same time, and how many days a month each one actually gets.
Any of the following should disqualify an engagement regardless of the person's résumé.
- An open-ended monthly retainer with no deliverable and no review date
- No willingness to write down the decisions they make, or to be held to them
- Recommendations that consistently point toward their own delivery arm, a partner they resell, or a technology they are certified in
- No opinion on how the work should be estimated and released
- Reluctance to be evaluated by anyone technical, including a reviewer you bring in
- A scope that has grown to include writing production code without anyone deciding it should
The exit criterion
A fractional technical leader is working toward not being needed. That is the distinguishing feature of the role, and it should be written into the engagement rather than assumed. Depending on the company, the end state is a permanent technical leader you were able to hire and evaluate, an internal engineer promoted into the responsibility, a delivery partner operating under decisions that are now documented, or a system that has become stable enough not to need continuous judgment.
The practical test is what remains if the person stops tomorrow. Decisions written down, an interview loop your team can run, a release process that does not depend on one person's attention, and a vendor agreement someone else can enforce all survive. A relationship survives nothing.
Common questions
- What is the difference between a fractional CTO and a technical advisor?
- An advisor gives opinions; a fractional technical leader makes decisions and is accountable for them. The practical difference shows up in the agreement: a leader has named deliverables, defined decision rights, and an end condition, while an advisory arrangement is usually availability for a monthly fee. Both can be useful, but they should not be priced or judged the same way.
- How do we know whether we need one or a delivery partner?
- If your open question is what to do, a fractional leader helps. If you already know what needs to exist and the problem is that nobody is going to build it, buy delivery from a partner who owns the outcome and puts a senior technical lead on the work. Buying leadership when you needed delivery produces good documents and no working software.
- How long should a fractional engagement last?
- A bounded mandate usually runs weeks to a few months and ends when the objective is met. An ongoing arrangement with fixed days per month should be reviewed at least quarterly against the deliverables agreed at the start. If it has run more than a year with no change in what your team can do without help, it is worth ending or restructuring.
- Can a fractional leader also write code for us?
- Occasionally, and it is usually a warning sign when it becomes routine. Spiking a risky technical assumption or reviewing a critical piece of code is reasonable use of the role. Sustained feature work means you are paying leadership rates for engineering capacity and the decisions you actually hired them for are not getting made.
- Will hiring one delay hiring a permanent technical leader?
- It should do the opposite. One of the most valuable outputs of the role is a hiring loop and a calibrated view of what good looks like, which makes a permanent hire faster and safer. If the incumbent is not actively building toward being replaced, including running the search and assessing candidates, that is a reason to end the engagement.