Fractional CTO or Contract Engineer

A post came across my feed last week arguing that the fractional CTO role has quietly shifted from advisory to operating, and that the question to ask before you sign one is what they personally pushed to production in the last year. Not what their old team shipped. What they shipped. If the answer is a roadmap deck, the argument goes, you’ve hired a consultant wearing a CTO title, and you should be paying consultant rates.

I agree with most of the diagnosis. The deck-only advisor is real, and paying executive rates for one is a bad trade. Where I part ways is the remedy, because “so they should be shipping features” fixes the problem by converting the role into a different role, and that role already has a name.

What I said in the comments at the time, more or less: a fractional CTO should be building and structuring your processes so that the organization can scale past them. Hiring one to own and write features is hiring a contract engineer with an inflated title and unclear boundaries.

That’s the whole disagreement, so the rest of this is me trying to say why.

The Deliverable Isn’t the Same Thing#

A contractor’s deliverable is the feature. Working software, against a spec, by a date. That’s a real and valuable thing to buy, and there’s nothing lesser about it.

A fractional CTO’s deliverable is your organization’s ability to keep making these calls after they’re gone. The architecture decision is an output, but it isn’t the product. The product is that the next three decisions of the same shape get made correctly by your team without a phone call.

Both roles produce artifacts, and from the outside during month one they can look nearly identical. The difference shows up in what each one is trying to become. Only one of them is actively working toward being unnecessary.

The clarifying test is six months after the engagement ends. If the contractor’s feature is still running and you hire them again for the next one, that’s a success — repeat business is the normal outcome of good delivery work. If your team is still calling the fractional CTO to make routine architectural calls, that engagement failed, no matter how good the advice was each time.

Yes, They Should Be Able to Open the Codebase#

The steel-man version of the other position is strong and worth conceding fully. An advisor who can’t read your code is guessing. Architecture advice that never touches the repository is a genre of fiction, and you can usually tell within one conversation. So a fractional CTO should absolutely be able to build, and in practice will write code during the engagement.

What matters is which code.

The pipeline that makes deploys boring. The first service that establishes the pattern the next ten will follow. The evaluation harness your team keeps running long after the decision it was built to settle. The two-day migration spike that answers a build-versus-buy question by trying it, rather than arguing about it for six weeks in a document.

All of that is code, and all of it is in service of a decision or a process. None of it is feature delivery. The distinction isn’t about seniority, or about how hard the code is — some of the scaffolding work is harder than the features. It’s about who owns the outcome once the engagement ends.

So “what did you personally push to prod” is close to the right question aimed at the wrong object. The version I’d actually ask is: what did you build at your last engagement that the team still uses, and are they still using it without you?

The Boundary Problem#

The reason I called this out as unclear boundaries rather than just a mislabel is that the two mandates actively interfere when you put them in one contract.

Availability collides with commitment. Eight hours a week can’t own a delivery date. When it tries, the person you hired to remove a bottleneck becomes one, and you tend to find that out during the week they’re on a plane.

Review collapses. They can’t objectively review the architecture they wrote last month. Most of what you’re buying from an outside technical leader is a read that isn’t compromised by authorship, and the moment they’re the author, that’s gone.

Priorities resolve silently, and always the same way. A feature with a date beats process work with no date, every single week, without anyone consciously deciding it should. The leadership half of the mandate is the half that quietly doesn’t happen, and nobody notices until the quarter is over.

None of these are caused by the fractional CTO writing code. They’re caused by one engagement carrying two mandates with different success conditions, where only one of them has a deadline attached.

The Mislabeling Runs Both Ways#

The concern in the original post was a consultant with a CTO title billing CTO rates for deck work. That happens, and it’s worth screening for.

The inverse is more common, and considerably more expensive: you are bringing on a contract engineer with misaligned expectations; a contract engineer with a CTO title, billing leadership rates for delivery work. You get features, which feels like progress. What you don’t get is the thing you were actually short of. The decisions stay unowned and the processes stay unbuilt. This becomes clear months (or years) later when you’re having the same architecture conversation with the same lack of resolution, except now there’s more code in the way. The true expense doesn’t come from “paying leadership rates” vs “contractor rates”, but from delaying the CTO-level leadership you thought you were getting.

Both cases are the same error approached from opposite directions. The title stopped describing the job, and the price stopped matching the value.

Hire Both. Just Not in One Contract.#

None of this is an argument that one person can’t do both. Plenty can, and there’s a real efficiency in having the person who set the direction also build the first piece of it.

It’s an argument against one engagement carrying both mandates with nothing separating them.

If you need both, write two scopes. Separate deliverables, separate definitions of done, separate rates, and preferably a stated order, because the leadership work usually has to come first — it’s what determines whether the delivery work is the right delivery work. If it’s the same person wearing both hats, say out loud which hat is on this week.

That sounds like bureaucracy for what might be a two-person arrangement, and it mostly is. It’s also a lot cheaper than untangling months of unclear expectations after the fact.

A contractor is finished when the thing is built. A fractional CTO is finished when you can build the next thing without them. If you can’t say which one you’re buying, you’ve bought the contractor.

Hopefully this works out for you, or was at least helpful. If you have any questions, don’t hesitate to shoot me an email, or follow me on twitter @nrmitchi.