The decisions your contractors keep leaving for you

Here is a shape that comes up a lot.

A company has a platform that works. It makes money. Over the last two or three years the team has been topped up with contract developers: one for the payments work, one for the mobile app, one who was very good at the reporting rebuild. Each of them shipped. Each of them left. And now the codebase has three different ways of talking to external services, two queue systems, a test suite that only runs green on one person's laptop, and a deployment process that one former contractor documented in a Notion page nobody can find.

Nothing is on fire. That is part of the problem. There is no incident to justify stopping, and no single person whose job it is to say "this is the shape we are going to settle on, and here is the order we fix it in".

So the decisions pile up on the desk of whoever is closest to technical: often a CEO who used to code, sometimes a product lead, sometimes a very capable senior developer who has never been asked to think three years out.

What the divergence actually looks like

This is not abstract. In a Laravel codebase with no architectural owner, you end up with something like this in the same application.

One contractor wrote a service class with the HTTP client injected:

class CourierClient
{
    public function __construct(private PendingRequest $http) {}

    public function book(Shipment $shipment): BookingResult
    {
        $response = $this->http->post('/bookings', $shipment->toPayload());

        return BookingResult::fromResponse($response->throw()->json());
    }
}

Another, six months later, did it inline in a controller with a facade and a retry loop copied from a blog post. A third built a job that calls a second job that calls a third-party SDK directly, with the API key read from env() at runtime so it breaks whenever config is cached.

Every one of those was a reasonable local decision. The contractor was paid to deliver a courier integration, not to harmonise the codebase. They looked at the surrounding code, found no clear convention, and picked something defensible.

The cost does not show up in their sprint. It shows up eighteen months later when you want to add rate limiting, or change how failures are reported, or onboard a new developer who now has to learn three conventions instead of one. It shows up when someone asks how much it would cost to swap couriers and the honest answer is "we would have to read all of it first".

Judgement is mostly about ordering and refusal

When people say they need senior engineering judgement rather than more hands, they usually mean they need someone to make a small number of decisions that are expensive to get wrong. In practice those decisions cluster into a few types.

What not to do. The most valuable thing a technical leader says in a given quarter is often "no, not yet". No to the rewrite. No to Kubernetes for four services and eleven users. No to the microservice extraction that would double your deployment surface to solve a problem you could solve with an index and a queue.

What order to fix things in. Given a list of twelve known problems, which three actually block the next twelve months of product work? Usually it is not the ones the team complains about loudest. A flaky test suite is annoying; a data model that cannot represent multi-currency is the thing that will stop the European launch.

Build, buy or leave alone. Authentication, billing, search, notifications, feature flags. Each of these is a decision with a ten-year cost attached. A contractor with a six-week scope has no reason to argue with you about it.

Who you hire next, and what for. The hiring plan is an architectural decision in disguise. If you commit to a stack that needs a specialist you cannot recruit in your area at your budget, you have made your own future harder.

What to measure. Most teams we meet have plenty of monitoring and almost no agreed answer to "is the system getting better or worse". Choosing three numbers and holding them steady for a year is judgement, not tooling.

None of these need forty hours a week. They need a few hours a week from someone who has seen the consequences of getting them wrong, and who will still be there in six months to own the consequences of the choice they made.

Why the twelve-month search is itself a decision

Hiring a permanent CTO or VP Engineering in the UK is slow. Three months to agree the brief and the comp, two to three months of search, a notice period of three months for anyone senior enough to be worth hiring, then a ramp of another quarter before they are making confident calls about your specific system. A year is not pessimistic.

That year is not neutral. During it, the team keeps shipping, and every ship without an owner adds to the divergence. The new CTO arrives to a bigger version of the problem that prompted the search, plus the political cost of being the person who reverses twelve months of decisions made in their absence.

We are not arguing against the permanent hire. For most companies past a certain size it is the right end state. The argument is about the gap. If you know you need a year, the question is who holds the architectural line while you search, and whether that person can also help you write the brief and sit on the interview panel.

The honest tradeoffs of fractional

A fractional CTO is a part-time senior engineer with decision-making authority. That sentence contains all of the problems.

Less context. Someone in the business two days a week will miss things. They will not overhear the sales call where a customer asked for something unreasonable, and they will not notice the developer who has quietly been unhappy for a month. You compensate with written decisions and a deliberate flow of information, but you do not fully compensate.

They cannot be your on-call. If your answer to a 3am outage is "the fractional CTO will handle it", you have bought the wrong thing. Part-time leadership works when the team can operate without the leader present. If it cannot, fixing that is the first piece of work.

It fails without a mandate. The most common way this goes wrong is the fractional lead being asked to advise rather than decide. Advice is cheap and gets ignored. If the person is going to set the architectural direction, someone has to say publicly that they set the architectural direction, including when a founder disagrees.

There is an exit to plan. Fractional is a bridge, not a destination. That means part of the job is making itself unnecessary: writing down the decisions and the reasoning, growing a senior engineer internally, running the search for the permanent hire. If nobody is talking about the handover in month three, the arrangement has quietly become a dependency.

Cost per day is higher. A day of experienced technical leadership costs more than a day of contract development. The value is in what does not get built, which is real but harder to put on an invoice.

What to check this week

If you recognise the situation at the top, three things are worth doing before you talk to anyone about it.

First, write down the last five significant technical decisions your company made, and who made them. If the answer is "whoever was on that ticket", that is your finding.

Second, pick one common operation, something like calling an external API or sending an email, and grep for how many ways your codebase does it. Count them. That number is a rough proxy for how much unowned drift you have accumulated.

Third, ask your most senior developer what they would fix first if you gave them a quarter and no feature work. Then ask them what they think you would say no to. The gap between those two answers tells you whether the judgement problem is a shortage of skill or a shortage of authority. Those need different fixes.

If it is authority, you may not need another contractor at all.