What a mid-project exit actually is

When an engineer leaves mid-project, the standard response is to review the hire. The interview process gets scrutinised. References are questioned. The technical assessment is revisited. The conclusion, almost always, is that something was missed at the screening stage — and the fix is to screen more carefully next time.

This is the wrong diagnosis. It produces interventions that do not address the actual cause. And it means the same exit happens again on the next project with a different engineer.

A mid-project exit is the visible endpoint of a process that began weeks or months earlier. By the time the engineer hands in their notice, a sequence of decisions has already been made — by the engineer, and often by people on the client side — that made leaving the rational choice.

The decision to leave accumulates. The formal notice is not the event. It is the acknowledgment of an event that already happened.

What was the actual event? In most cases it is not a single moment. It is a pattern: the engineer encountered misalignment between what they understood they were joining and what the project actually required. That misalignment was visible — to the engineer, and often to others — from relatively early in the engagement. But there was no mechanism or expectation for it to be surfaced and addressed.

The information that was available and wasn't used

The insight from tracking 30+ projects over multiple years is that mid-project exits are rarely surprising in retrospect. When you go back through the engagement history, the signals were present. Someone on the delivery team knew something was wrong. Someone on the client side had concerns. The project was carrying a misalignment that both parties were aware of and neither had formally raised.

This is not because people were hiding information. It is because the engagement was not designed to surface it.

Most project engagements have mechanisms for reporting progress — status updates, sprint reviews, delivery milestones. They do not have mechanisms for surfacing the information that actually matters in the early stages: whether the engineer understands the real requirements, whether the working relationship between the engineer and the team is actually functioning, whether the scope as understood by the delivery side matches the scope as understood by the client.

This information exists. It is held by the people doing the work. It rarely reaches the people who could act on it, because there is no established channel and no expectation that it should move.

Why "screen better" doesn't fix this

The impulse to improve the hiring process after a mid-project exit is understandable. Hiring is a controllable variable. It is a discrete process with defined steps that can be improved. And it is true that better screening reduces the frequency of genuinely wrong hires.

But a genuinely wrong hire is a different problem from a right hire that exits mid-project because the engagement produced a deteriorating misalignment.

Screening addresses fit at a single point in time: the moment of hire. A well-screened engineer who joins a project where misalignment accumulates unchecked will exit mid-project at a similar rate to a poorly-screened one. The screening did not cause the problem, and improving it will not prevent it.

The intervention that addresses mid-project exits is one that operates continuously throughout the engagement — not one that happens once at the start.

What the structural fix looks like

The firms that have the lowest mid-project exit rates are not the ones that run the most rigorous hiring processes. They are the ones that have built a consistent mechanism for information to move between the delivery team and the client throughout the engagement.

This mechanism has three characteristics.

First, it is expected rather than exceptional. Surfacing misalignment is the default behaviour, not the exception. Both parties understand that raising concerns early is part of the engagement model, not a sign of failure.

Second, it is structured at the engagement level, not dependent on individual initiative. The mechanism does not rely on the engineer or the client manager deciding to raise something. It creates a regular, low-friction channel through which the information that matters most can surface.

Third, it operates below the threshold of formal escalation. Most misalignment is not serious enough to escalate formally — but it is serious enough, if left unaddressed, to compound into something that becomes a breaking point. The effective mechanism catches it before it crosses that threshold.

When those signals surface early, they are addressable at low cost. When they surface at month four of a six-month engagement, they are usually not.