C-Suite Leadership Strategy · The Next Chapter
The Fractional CTO: How to Build a Portfolio Practice That Scales
You have built platforms and engineering teams for years, and you want to do it for several companies at once — but a fractional technology practice is a business, and most CTOs try to code their way into one.
You have spent your career owning a company's technology and the team that builds it, and you now want that judgement to serve a portfolio rather than one product. Figuring out how to become a fractional CTO has little to do with your engineering depth — that is proven — and everything to do with pricing, positioning and a pipeline that outlasts the last founder who knew you. This engagement builds that plan.
Does this sound like you?
If several of these land, this engagement is built for you.
- You could set technology direction for several founders tomorrow, but you cannot say what a fractional CTO engagement should cost or how to scope one that does not turn into full-time coding.
- Every engagement drifts toward you writing the code, unblocking the sprint and firefighting production — the exact work that makes a portfolio impossible.
- Your clients are all founders you already know, and you can feel that source narrowing the further you get from your last operating role.
- Founders want a senior technologist but keep treating you as a very expensive contract developer, and pricing you like one.
- You worry that once you are not the CTO of a live product, your credibility quietly expires and juniors start to out-signal you on the latest stack.
- You suspect you are underpricing because you cannot explain why a part-time CTO is worth more than a strong senior engineer or a dev shop.
Why the maker's instinct destroys the practice
A fractional CTO practice is undone, more reliably than by any market factor, by the founder's own love of building. The very reflex that made you a great engineer — see a problem, solve it in code — is fatal to a portfolio, because code is time, and time cannot be spread across several companies. When you were the salaried CTO, being hands-on was a virtue; the company owned all of your hours and wanted them in the product. The moment you go fractional, every hour you spend building is an hour that binds you to one client and shrinks the number of firms your judgement can serve. The practice does not scale on how well you build. It scales on how little you have to.
This is why so many technically brilliant CTOs go fractional and quietly recreate a full-time job at a discount. Shown a struggling team or a broken deploy pipeline, they roll up their sleeves, because that is who they are and it feels like value. The founder, delighted to have a senior person actually shipping, prices them as a very expensive developer and treats the strategic judgement as a free bonus. The scarce thing — knowing what to build, what to buy, when to rewrite, who to hire, which technical risk will sink the company — gets given away as the wrapper around billable coding. Pricing the judgement rather than the build is the practice's founding decision.
The retained authority versus the fractional coder
Two practices wear the same title. In the first, you are a retained technology authority: several companies pay a standing fee for the judgement of a real CTO — architecture and build-versus-buy decisions, the technology roadmap, hiring and leading the engineering team, the technical risk the board needs owned, and readiness for the diligence that precedes a raise or a sale. In the second, you are a fractional coder: embedded in each firm's codebase, in the standups, on the on-call rota, rebuilding a full-time engineering job across three companies at contractor rates. The first compounds and commands a premium; the second is a treadmill.
The dividing line is what the engagement owns, not the client's size. A retained CTO owns the decisions and the team and deliberately does not own the keyboard — the actual building belongs to the client's engineers, a hire you help them make, or a development partner you help them select and govern. The hardest discipline in the whole practice is refusing to fill the gap yourself, because you can, and because founders will always prefer you shipping to you advising. But a CTO who ships is present, and presence is what turns four clients into one and a half. Owning the architecture while orchestrating the build is the entire economics of the thing.
- Architecture, build-versus-buy and roadmap decisions — the judgement that determines whether the product can scale at all.
- Hiring and leading the engineering team, and setting the standards, rather than being the senior engineer.
- Owning technical risk and diligence-readiness for the next raise or acquisition.
- A firm boundary where the code itself is written by the client's team or a partner you help select and manage, never you.
A pipeline that outlives your last product
Every fractional CTO's first clients arrive through the founder network — someone you built with, an angel who backed you, a peer whose company you advised for free. This warm flow feels like the practice working, and it is the moment of greatest fragility, because founder introductions are a depleting asset: each is spent once, they cluster in the world you just came from, and they say nothing about whether the wider market will retain a stranger to own its technology. Practices that never build a second engine plateau precisely when the founder network thins, which it always does.
The durable pipeline is built on being the known technology mind for a specific kind of company and problem. The buyers of fractional CTOs are not one market — a seed startup that cannot yet afford a full CTO but is being asked hard tech questions by investors, a non-technical founder who needs a translator between the business and the dev shop, a growth-stage company whose early architecture is buckling, a PE firm that needs a technical diligence partner, or a GCC standing up a new engineering charter each surface differently and buy for different reasons. A CTO famous for solving one of those markets themselves. One known generally as an experienced technologist waits for the network to ring.
The credibility-decay problem, and how to defeat it
The specific fear that haunts fractional CTOs is technical: unlike a CFO's or a CMO's, an engineering leader's currency is perceived to decay with the stack. The worry is that once you are not shipping on a live product, the juniors know the newer frameworks, the latest models, the current tooling, and your judgement starts to look like yesterday's architecture. Left unaddressed, this fear pushes CTOs back toward hands-on coding to prove they are still current — which, as the practice's core error, is the worst possible response to it.
The reframe is that a CTO is not paid to know the newest framework; a CTO is paid for the judgement that outlasts every framework — how to make build-versus-buy calls, how to hire and evaluate engineers, how to see the technical risk that will sink a company two years out, how to keep a system evolvable when the fashionable choice is not the durable one. That judgement compounds with experience rather than decaying with the stack, and it is precisely what a founder cannot get from the junior who knows the latest library. A fractional CTO who positions on durable judgement, and stays credibly current through advising rather than coding, is worth more each year, not less. This engagement is built to make that judgement your visible product rather than your hidden asset.
You are not paid to know the newest framework — the juniors will always win that race. You are paid for the judgement that outlasts every framework: what to build, what to buy, who to hire, which risk will sink the company. That compounds with age; it does not decay with the stack.
Being seen as the technology mind, not the hired hands
The final discipline is visibility, and CTOs are often the most reluctant of all executives to build it — many left corporate life partly to escape the performance of it. But a fractional practice run by an invisible technologist is a contradiction: the buyer who needs to trust someone with the company's entire technical future has no way to find or assess a CTO who never states what they think. The market cannot retain a judgement it cannot see, and so the invisible fractional CTO stays trapped in the referral loop, priced against dev shops because nothing distinguishes them from one.
Making your judgement visible does not mean becoming an influencer; it means having a clear, repeated point of view on the technology decisions your buyer actually faces — how to structure an early team, when to rewrite, how to think about AI in the product, how to survive technical diligence — stated where founders and investors can see it. That is what turns you from a name in a network into the obvious call for a specific technical problem, and it is what lets you charge for judgement rather than hours. This engagement treats your visibility as the strategic asset it is and builds the plan for it deliberately, so the practice is sought out rather than passed around.
How it plays out
The SaaS CTO who kept being hired to write code
Consider an engineering leader — call him Sameer — who had built and scaled the platform of a well-known B2B SaaS company through two funding rounds and a painful re-architecture, and left to go portfolio. Within a few months he had three founder clients, and every one had drifted into the same shape: he was in the codebase, unblocking sprints, sitting on-call, effectively acting as a very senior contract engineer across three products. He was working longer hours than in his salaried role, being paid at a blended contractor rate, and could feel his own anxiety that the twenty-somethings on those teams knew the current tooling better than he did — which only pushed him further into the code to prove he still had it.
The diagnosis named the loop. Sameer's maker's instinct had rebuilt three full-time engineering jobs at a discount, because he sold building and so was paid and treated as a builder. His scarce judgement — the architecture calls, the hiring, the risk he could see two years out — was being handed over free as the context around billable coding. His pipeline was three founder intros deep with no engine, and his credibility strategy was self-defeating: competing with juniors on stack-currency is a race the experienced always lose, and it was pulling him away from the very judgement that was his real product.
The roadmap re-founded the practice on that judgement. Sameer re-scoped every engagement to architecture, roadmap, build-versus-buy, hiring and technical-risk ownership, and pushed the code itself to client engineers and a development partner he helped them govern. He repositioned his value around durable judgement rather than current stack, and stayed credibly sharp by advising widely instead of coding narrowly. He aimed his practice at one clear buyer — non-technical founders being grilled on technology by their investors — and built a visible point of view that made him the obvious call and, in time, the go-to technical diligence partner for two early-stage funds. Within a year he held four retained clients at technology-authority fees, worked sane hours, and had a practice that grew from reputation rather than favours. He had stopped selling his hands and started selling his mind.
Illustrative composite — every engagement is calibrated to your specific situation.
What the two conversations cover
Session 1 · Diagnosis
- Separate the technology judgement only a CTO can sell from the hands-on building that is quietly repricing you as a contractor.
- Diagnose the credibility-decay fear and how it is pushing you back toward code — the worst response to it.
- Map which fractional-technology buyer you are genuinely best for, and how much of your pipeline is depleting founder intros versus a real engine.
Session 2 · The plan
- Design the retained-authority engagement — scope, cadence and the boundary that keeps you off the keyboard.
- Reframe your value around durable judgement rather than current stack, and build the way to stay credibly current without coding.
- Set the positioning and visibility that make you the obvious call for a specific technical problem, priced for judgement not hours.
The mistakes to avoid
- Filling the build gap yourself because you can, turning scarce judgement into billable code and a portfolio back into a job.
- Fighting juniors on stack-currency to prove you are still relevant, a race the experienced always lose and the wrong contest entirely.
- Living off founder introductions and mistaking a depleting network for a working pipeline.
- Owning the keyboard and the on-call rota, signing up for a presence that makes serving several clients impossible.
- Staying invisible about what you actually think, so the market cannot tell a fractional CTO from a dev shop and prices you like one.
One offering · one outcome
- Two 60-minute one-to-one conversations with a senior Gladwin partner
- A complete diagnostic of where you stand in the market today
- A personalised repositioning roadmap you keep — your gap analysis and 90-day plan
C-Suite Leadership Strategy — Assessment and Roadmap
2 × 60-minute conversations · one booking
- Two 60-minute one-to-one conversations with a senior Gladwin partner
- A complete diagnostic of where you stand in the market today
- A personalised repositioning roadmap you keep — your gap analysis and 90-day plan
Loading available slots…
Frequently Asked Questions
By scoping the engagement to judgement and refusing the keyboard. A retained CTO owns architecture, roadmap, build-versus-buy, hiring and technical risk, and pushes the actual building to the client's engineers or a partner they help select. The maker's instinct — see a problem, fix it in code — is exactly what reprices you as a contractor and binds you to one client, because code is time and time cannot be spread. Drawing that line before you sign is the whole difference, and it is where the first session begins.
It follows what you own, not the hours you give. Owning architecture, the team and technical risk commands a technology-authority fee; writing code commands contractor rates, even at the same client. The real work is justifying, to a founder who may see technology as a cost to minimise, why a part-time CTO's judgement — on what to build, what to buy, who to hire and which risk will sink them — is worth more than another senior engineer or a dev shop. Once that framing lands, the fee follows the value.
Only if you let it push you back into coding to prove otherwise, which is the wrong contest. A CTO is not paid to know the newest framework — the juniors will always win that race — but for the judgement that outlasts every framework: build-versus-buy calls, hiring, seeing the risk that sinks a company two years out. That compounds with experience rather than decaying with the stack, and it is exactly what a founder cannot get from the junior who knows the latest library. Position on the judgement and you are worth more each year.
It feels like one and is not. Founder introductions are a depleting asset — spent once, clustered in the world you just left, and silent on whether strangers will retain you to own their technology. Practices that never build a second engine stall the moment that network thins, which it always does. The durable pipeline comes from being the known technology mind for one specific kind of company and problem, delivered where that buyer already looks. Building that engine is the focus of the second session.
A senior engineer builds what they are told to; a dev shop delivers to a spec. Neither decides whether the architecture can scale, whether to build or buy, who to hire, or which technical risk threatens the company — that is CTO judgement, and it is what determines whether all the building is even pointed the right way. When you sell hands, you compete with engineers and shops on price. When you sell the judgement that directs them, you sit above them and often govern the very shop the client uses. Blurring the two is why many CTOs undercharge.
They are one of the strongest buyers, precisely because they most need judgement they cannot supply themselves — a translator between the business and the engineers, and someone to own the technology decisions and the investor conversation. The risk is that, unable to assess technical work, they default to valuing visible output and treat you as a builder. So they are excellent clients when you scope to judgement and make that judgement legible to them, and a trap when you slip into coding. The roadmap is built to make that buyer work in your favour.
It fits well and is often underused. PE firms and VCs need someone to assess a target's architecture, team and technical risk before they invest — pure judgement, no building, and priced for it. It also compounds the practice: diligence work builds relationships with funds that then refer their portfolio companies to you for ongoing fractional engagements. Positioning yourself as a credible diligence partner for a specific kind of deal is one of the sharper pipeline engines available, and we can design for it in the second session.
Two 60-minute conversations with a partner, a written diagnostic of where your practice is leaking value — scope, pricing, the credibility-decay trap, pipeline and visibility — and a personalised roadmap document with the specific moves for your situation: the retained engagement model, the buyer to own, the judgement-based positioning, and the visibility plan that makes you the obvious call. One price, incl. GST, or $250 internationally. No tiers and nothing further to buy.