When your only senior engineer hands in their notice

Four developers, a Laravel application that carries the whole business, and a roadmap you agreed with the board in January. Then your head of engineering gives four weeks' notice.

The immediate worry is usually delivery. Will the sprint slip, who picks up the half-finished payments work, does anyone else know how the deployment pipeline is wired. Those things are real, and they are also the easiest part. Four capable developers will muddle through a quarter. What degrades quietly, and what you notice six months later, is the quality of the decisions nobody is making.

The search takes longer than you think

You will probably start by trying to replace like for like. That is reasonable. It is also slow. A genuine engineering lead search in the UK runs three to six months from writing the spec to a signed contract, and then there is notice: three months is normal at that level, sometimes longer. Call it nine months before the new person has an opinion worth acting on.

There is a second problem, which is harder to say out loud. If your outgoing lead was the only person in the company who could assess technical seniority, you are now hiring for a role you cannot evaluate. You will interview well on communication and culture and badly on everything else. The Stack Overflow Developer Survey has shown the same pattern year after year: the people you want are not desperate, they have options, and compensation is only part of what moves them. You are competing for scarce attention with a job spec written by someone who left.

So the honest planning assumption is not "we'll have someone by summer". It is "we will be without senior technical judgement for most of a year, and we need a plan for that gap".

What actually breaks in the gap

Not velocity. Decisions.

Here are three that will land on someone's desk in the next few months whether you have a lead or not.

Runtime end of life. PHP 8.1 reached the end of its security support at the end of 2025. If your application is on 8.1, every month from here is a month running an unpatched interpreter, and that is now a fact you have to report rather than a preference. Moving is not one job. PHP 8.4 deprecated implicitly nullable parameter types, which sounds trivial until you count the occurrences:

// Fine for years. Deprecated in PHP 8.4.
function findUser(string $email = null): ?User

// What it needs to be
function findUser(?string $email = null): ?User

One-line fix, several hundred sites, plus whichever of your dependencies have not been touched since 2022. The engineering is easy. The decision is the sequencing: which packages get replaced rather than patched, whether you jump two minor versions or four, whether you do it before or after the release you promised the board. That is a judgement call with commercial consequences, and it is not fair to hand it to a mid-level developer and call it delegation.

Framework support windows. Laravel gives eighteen months of bug fixes and two years of security fixes per major release. Laravel 11's security window closes in March 2026. If you are on 11 and comfortable, comfortable has a date on it. Somebody needs to decide whether you upgrade annually as a matter of routine, which costs a predictable slice of every year, or let it drift and pay for a bigger jump later. Both are defensible. Drifting by accident is not.

Access control. Broken access control has sat at or near the top of the OWASP Top 10 across editions, and it is the risk class that grows fastest in a system being extended by people who did not design it. Every new endpoint is a chance for an authorisation check to be forgotten. Without someone reviewing for that specifically, the gaps accumulate in exactly the parts of the codebase that changed most recently. The NCSC guidance aimed at organisations rather than engineers makes the same point in board language: most incidents come from ordinary, known weaknesses left in place, not from anything exotic.

None of these are emergencies this week. All of them are worse in nine months.

The four interim options

Promote from within. Cheapest, fastest, and often right. The cost is that you have converted your best developer into an inexperienced manager and lost their output at the same time. It works when the person has been quietly making the decisions anyway and just needs the title and the authority. It fails when you promote on tenure rather than judgement and then have no way to undo it.

Hire a contract lead. Fast to arrange, expensive per day, and the incentives are honest but narrow: they are paid to deliver, not to reduce the number of decisions you need them for. A good contractor will run your build competently for six months. Very few will spend their time making your permanent hire easier, because that is not what you asked for.

Fractional CTO. Two days a month to two days a week of senior input: upgrade sequencing, architecture calls, code review standards, interviewing for the permanent role, translating technical risk into something the board can act on. The cost is real and worth stating. They are not in the room every day, so they will miss things that daily presence would catch. They need someone internal with the authority to act between sessions, or advice just piles up in a document. And they are the wrong answer if what you actually need is four more hands on a late project. Judgement is not capacity. If your problem is throughput, hire developers.

Do nothing and hope. Sometimes fine for a quarter. Rarely fine for three.

Making part-time senior input actually work

If you go the fractional route, the setup matters more than the person.

Give them decision rights, in writing, for a defined set of things. "Sign off on architecture changes and upgrade plans" is a scope. "Advise the team" is not, and it produces advice that gets politely ignored.

Name one internal counterpart. Someone whose job it is to turn a decision into work in the backlog. Without that, every session starts by relitigating the last one.

Set a cadence and hold it. Fortnightly is usually enough for steady state. Weekly during an upgrade or an incident.

Ask for a written technical risk register in the first month, ranked, with dates. Not a report on how bad things are. A list of what breaks, when, and what it costs to prevent. That document is also the best interview material you will have for the permanent hire.

What to check this week

Open your composer.json and find the PHP version constraint. Check that version against its end of support date. Then check your Laravel major against its security window. If either has passed, or passes within six months, you have a decision outstanding and no one currently assigned to make it.

Then ask a simpler question: in the last three months, which technical decisions were made by someone with the authority and experience to make them, and which were made by whoever happened to be in the ticket? If you cannot tell the difference, that gap is the thing to fix, not the headcount.