Why I say Fractional VP of Engineering

I describe what I do as fractional VP of Engineering rather than fractional CTO. It is a small distinction, and I doubt anyone has picked me or anyone else on the strength of it. I am sure that it means whatever the person using it wants it to mean. It is not about what I am able to do, it is about which of the two better describes an ordinary week.

The early-stage CTO job is mostly not a CTO job

Generally, companies want fractional leadership when they are smaller. They cannot afford a full-time leadership hire, and there is not enough of the work to justify one.

Let's think about what a CTO does at a company of two hundred people: you are managing managers, or even managers of managers, so most of what reaches you arrives second-hand and late; there is peer-level politics, in the ordinary sense of the word rather than the pejorative one - arguing for headcount with a CFO who has three other departments asking for the same budget increase; sometimes you own security for the whole company rather than just the product, and general IT along with it, down to which CRM the sales team should use. Very little of that has much to do with technology. A good deal of it is running a department, and rather more co-ordination than the title suggests - 'glue' work, as I've always thought of it.

Now let's think about what the person holding the CTO title does at a company of eleven. You write code. You interview. You fix the deployment pipeline. You sit with a founder who may not have a technical background and turn a roadmap into something that can be built in the order it needs building. You make very real decisions about what to build and, more often, what not to build. Every so often you do a bit of the two-hundred person job, perhaps in the week before a board meeting or at performance-review time.

Some of that first list is arguably VP of Engineering work too, and at two hundred people there is often somebody doing it full-time. But it arrives in a different form. At eleven people you build the team by interviewing on a Thursday afternoon. At two hundred you build it by owning an interview scoring framework that the HR team can understand, and you are unaware that the GitHub Actions pipeline is down.

The eleven-person version is a VP of Engineering job. It is a step down from CTO in scope and a step closer to the work, and describing it accurately is not a demotion. It is simply what the role entails.

The CTO you need now may not be the CTO you need later

There is a practical reason I tend to avoid the CTO title too.

C-suite titles at an early-stage company tend to mean something fairly specific. They usually belong to founders, they carry an implication about equity and permanence, and they are considerably easier to give out than to take back. For the reasons above, what makes somebody a good CTO at eleven people is often quite different from what makes somebody a good CTO at two hundred. Plenty of people can do both. But it is not a given, and at the point you are handing out the title you usually cannot tell.

This matters because the title tends to outlive the stage that produced it. Give someone CTO at eleven people and you have implicitly said they are the CTO at two hundred as well. If that turns out not to hold, you are not adjusting a job description - you are demoting somebody, visibly, in front of the team and probably the board. There is rarely a need to make that bet this early. The title is still there to give later, once you know.

What I am actually there to do

The short version is that I am there to support the founders. They may or may not include someone technical, and may or may not include anyone who has run an engineering team before.

In practice that means being hands-on, in whichever direction the hands are needed. Sometimes that is writing the software myself; sometimes that is taking a product vision/rough roadmap and working out what and how to actually make that a reality; sometimes it is building the team that will write it. Usually it is some of each, in proportions that shift month to month.

It also means taking the engineering or the day-to-day product build load off the founders more or less entirely. If your particular strength is networking, go and network. If it is raising money, go and raise money. Those are things nobody else at the company can do for you, and when they are going well they take all of your attention. What you do not need is to be spending cognitive load over here, on whether the hiring loop is calibrated or whether the migration is going to slip.

I would rather come in, get on with it, and take that off your list. I get both personal and professional satisfaction from being useful. I like to help people.

It is probably a smaller distinction than I have made it sound

Having written all of that down, I should say the difference probably matters more to me than it does to you.

I can do the CTO parts. If someone needs to sit in front of an enterprise customer and explain the architecture, or write the technical half of a fundraise deck, or turn up to a board meeting, that is fine, and I have done all of it. The distinction is not about what I am able to do. It is about which of those things fills a normal week, and at the stage I usually join, it is not those.

Where it does earn its keep is in setting expectations. If you engage a fractional CTO expecting somebody who will mostly be in front of the board and the enterprise customers, and what turns up is somebody who wants to spend Tuesday on your deployment pipeline, the mismatch does not show up on day one. It shows up a few months in, usually as a vague sense that the arrangement is not quite working. Getting the label roughly right at the start avoids a fair bit of that.

And the title itself

For what it is worth, I do not have strong feelings about what goes on the contract, in the Slack profile, in the investor deck, or is communicated to the team.

Call me CTO if it makes the org chart simpler or reads better to the team. Head of Engineering, fine. General dogsbody, fine. Titles at that size are mostly a communication device for people outside the company anyway.

None of it tells me much either way. If you are paying the rate, I take it we already agree on what the work is worth, and we can get on with that work.