Fractional CTO

We place experienced technologists inside growing companies as their CTO.

This suits a particular kind of person. You are drawn to the problem itself, and a system you have never seen before reads as interesting rather than daunting. You do your best thinking when something is going wrong and the room is looking for an answer. You have led at a senior level, and you still want your hands on the work.

If that is you, the rest of this page is the detail.

What the work actually is

Each engagement is a business with real engineering under way and nobody in the room whose job is the long view. Sometimes the founder is acting as their own CTO while also trying to run the company. Sometimes the team has outgrown the architecture that got it to launch and delivery has quietly slowed to a crawl. Sometimes the technical lead has left and nobody has replaced them yet.

Across those, you would be doing some mix of:

Setting technical direction. Where the platform goes over the next twelve to eighteen months, what it costs to get there, and which capabilities to build versus buy — written down, so it survives contact with a changing roadmap.

Reviewing architecture. A second set of experienced eyes on the choices that are expensive to reverse: data models, service boundaries, authentication, anything that becomes load-bearing once it ships.

Advising on team and hiring. What to build in-house and what to outsource, who to hire next, how to structure a team so it still works at twice the size. Sitting in interviews when a client is hiring senior engineers without a senior engineer in the room.

Making vendor and stack calls. The buy-versus-build decisions that compound. A wrong platform choice is cheap to make and expensive to live with.

Realigning the budget. Cloud spend that grew without anyone deciding it should, overlapping tools that three teams bought separately, licences still renewing for people who left two years ago. You review the vendor estate, renegotiate what earns its keep, cut what does not, and set a number the engineering plan can actually be held to. On more than a few engagements this is what pays for the engagement several times over.

Overseeing delivery. Whether commitments are realistic, whether the team is blocked on something nobody has escalated, and whether the thing being built is the thing that was asked for.

What we are looking for

Above all: you like the work itself, and the satisfaction of getting it right. Beyond that:

• You have held the responsibility, not just advised on it — CTO, VP Engineering, head of platform, principal engineer with real ownership. You have lived with your own decisions long enough to know which ones aged badly.
• You can explain a trade-off to a non-technical executive without flattening it into a slogan, and to a sceptical engineer without pulling rank.
• You are an expert in the nuances of cat-herding. Nobody in a client's company reports to you. You have no budget authority and no mandate beyond the one you earn in the first few weeks. Getting a room of people with competing incentives pointed the same way, without a title to lean on, is most of the job on some engagements.
• You are still close enough to the work to read a codebase, review a design and know when an estimate is fiction.
• You are comfortable with ambiguity and partial context. You will not always have full visibility, and you will still have to give a clear recommendation.
• You write well. Most of what you produce here is written, and it has to stand on its own after you leave the call.
• You are steady when it matters. Some engagements start mid-crisis — a failed launch, a departed team, a deadline that was never realistic. Being the calmest person on that call is a large part of the value.

Breadth matters more than depth in any single stack. Most of our engagements touch cloud infrastructure, data, and increasingly AI, and we would rather have someone who can hold all of that at a working level than a specialist in one of them. What we care about most is that you can tell a real constraint from a fashionable one — and that you know the edge of your own expertise well enough to call in help before it costs the client anything.

What the role is really like

Worth being direct, because fractional work is often described in ways that do not survive contact with the job.

You are there for the decisions. Your judgement is what the client is buying, and the engagement is shaped around the questions that need it — architecture, hiring, direction, delivery.

And you are close to the work. The role is part counsel and part sleeves rolled up. Some weeks it is a strategy document and a hard conversation with an executive or a founder. Others it is pairing on the migration, writing the proof of concept that settles an argument, or getting into the codebase yourself because reading it is the fastest way to know whether an estimate is real. The people who do this well are the ones who never stopped being able to build.

You will be expected to say the hard thing. That a project should stop, that a hire is wrong, that the answer is to do less. Clients come to us precisely for that candour, and it is the part of the job that needs the most nerve.

How engagements work

You are engaged as a contractor, per client, with the scope and cadence agreed up front. Most run monthly and continue because they remain useful, not because a contract obliges them to.

We handle finding the work, scoping it, and the commercial relationship. You handle the judgement and, where it helps, the doing.

Breadth is the point. The best people in this role are generalists with real range — and, crucially, they know exactly where their range ends. Recognising that a problem needs a database specialist for a week, or a proper security review before a customer audit, and saying so early, is a senior skill in its own right. You draw on our wider bench when that happens rather than stretching yourself across a gap.

Rates are set per engagement and reflect the seniority of the work. We will discuss numbers early rather than at the end.

How to apply

Email careers@visitingcto.com with something readable about your background — a CV is fine, so is a short note and a link.

More useful than either: tell us about a technical decision you got wrong, what it cost, and what you would do differently. We are more interested in that than in a list of technologies.

We read everything and we reply, including when the answer is no.