Fractional CTO and remote team: who does what?

A fractional CTO sets the technical direction and makes the decisions that are expensive to undo. The tech lead turns that direction into daily work. Remote developers build, and decide on everything that falls inside their ticket. Write this split down and everyone knows where to go on the days the CTO is not around.

I work as a fractional CTO myself. This setup tends to get stuck in two places: someone makes a decision that belongs to someone else, or a decision waits until the CTO's next day in. A few agreements prevent both.

Who decides what

A fractional CTO works a fixed number of days a month, while the tech lead and the developers are there every working day. So split decisions by type, not by who has the most experience.

When you are not sure where a decision belongs, ask what it would cost to reverse it in six months. If that is an afternoon of work, the developer or the tech lead decides. If it means weeks of work or a data migration, it goes to the CTO.

What the fractional CTO does

The CTO writes down the boundaries the team works within: the stack, how services talk to each other, where data lives, which dependencies are allowed and how access to systems is managed. Every major choice gets a short note saying what was decided, why, and which alternative was dropped. Half a page per architecture decision record is enough.

The CTO also talks to the board or the founder about what has to ship this quarter and what it may cost. When the team grows, the CTO runs the technical interview with candidates or reviews the screening that has already been done.

My advice is to fix the CTO days in the calendar, for example every Tuesday. The team then knows when a big question will get an answer and can plan its work around that.

A fractional CTO does not need to review every pull request. If they do, work stops on every day they are away. Spot-check instead, and always look at changes to authentication, payments or the data model.

What the tech lead does

The tech lead is the developers' daily point of contact. They split work into tickets, review code, answer questions and remove blockers. They also keep the team to the CTO's agreements and know when a question is too big to decide alone.

That role can sit inside your company or in the remote team. Both work, as long as the tech lead is reachable during the hours the developers work. Our developers are in Serbia, in the same time zone as Amsterdam, Brussels and Berlin, so there is no shift to deal with.

With one or two developers, the fractional CTO can fill the tech lead role for a while, provided they have more hours for it. From three developers on, I would appoint a permanent tech lead. When to take which step is covered in growing a remote team from one to five.

What the remote developers do

A developer owns their ticket, from the first question to the merge. Questions go into the ticket or the pull request, early and in writing, so the tech lead and the CTO can find the context later. Developers write the tests, keep pull requests small and speak up when a ticket does not add up.

They also decide on the implementation themselves: naming, structure within a module, which tests to add. If the tech lead keeps having to step in on those, the standards are not written down clearly enough. What a workable ticket looks like is described in writing tickets a remote developer understands.

Where it goes wrong

When the split is off, you usually see one or more of these patterns:

• Only the CTO can merge, so everything stops on their days off.
• Developers wait for the CTO on a choice the tech lead could have made.
• The founder sends new requests straight to developers, bypassing the tech lead's priorities.
• Nobody feels responsible for accounts and access, so former team members keep their rights.
• Decisions are made on a call and never written down, so the team discusses them again a month later.

In each case it helps to record who owns the decision and to make sure that person is reachable.

The agreements on one page

Put the split on one page in the repository or the wiki, and walk through it with everyone who joins. At a minimum it covers:

1. Which decisions sit with the CTO, with a few examples.
2. How a question reaches the CTO. I prefer a short written proposal from the tech lead with the options and their preference.
3. How quickly the CTO responds, also outside their fixed days. Within one working day is a reasonable agreement.
4. A standing meeting between the CTO and the tech lead, for example thirty minutes a week.
5. Who creates accounts and who revokes them.

We provide developers and also a fractional CTO, but you do not have to take them together. If you already work with your own fractional CTO, our developers follow their agreements. At Zibber we reviewed the existing technology, designed the architecture and helped shape the team setup, so the team can take that direction forward itself. How we place developers in a team is explained under how we work.