The exit call usually comes in week 4. An engineer tells their manager they're leaving the engagement. The client escalates. Blame lands on hiring: wrong cultural fit, insufficient vetting, skills mismatch. Both sides agree: we need better screening next time.

By year six of managing these outcomes, the pattern becomes visible. The screening was rarely the failure point.

The problem is information. Both the engineer and the client operate on an incomplete picture of what the other expects, what constraints actually exist, and which signals matter. When either party discovers the gap too late, the cost is already sunk. The engineer leaves. The project restarts. The client assumes hiring failed again.

But the exit was not the failure. The silence before it was.

Three Structural Points Where Information Fails

Onboarding Alignment

The engineer arrives. They read documentation. They attend standup. They ask three clarifying questions about architecture and get answers that conflict with the docs. In a co-located team, this friction resolves in a hallway conversation. In a distributed model, it sits.

By day seven, the engineer has built a mental model of the system that differs from what the client's core team actually maintains. They proceed. The client assumes they're following the documented pattern. The engineer assumes the docs are outdated guidance.

This is not a screening failure. This is a design failure in how the engagement surfaces real state.

The engineers who leave earliest are often the ones who catch the mismatch first. They have worked in five other codebases. They recognize when the actual architecture differs from the stated one. They escalate. The escalation gets treated as a challenge or slowness. The engineer interprets the response as a sign the client does not actually want the real problem solved. These are also the engineers most likely to be classified as Tier 3 in a structured capability assessment — the ones who recognize broken patterns faster and exit before sinking months into recovery work.

Both readings are accurate from each side's vantage point.

The intervention that prevents this exit is not a harder hiring bar. It's a structured onboarding that forces the client to surface the real system state, not the documented one. It's asking: "What's one thing in the docs that's not how we actually work?" in week one and treating the answer as operational intelligence, not a bug report.

First Deliverable Review

The engineer submits a PR. The review feedback is about code style. The engineer had expected feedback on approach. They revise. The next PR feedback is about test coverage. They revise again. By the fourth revision, the engineer concludes that the client doesn't have clear acceptance criteria — or worse, that acceptance criteria are implied and punitive.

The client, meanwhile, is seeing a contributor who needs heavy review cycles. They're wondering whether this person is strong enough for the work.

Both are observing real facts. Neither has the information the other is operating on.

The first deliverable review is the moment when two different definitions of "done" collide. If the client has not clearly articulated what done looks like (not just what it avoids), the engineer will build to their own standard. When that standard doesn't match, both parties interpret the mismatch as a capability problem.

The exits that happen at week three usually emerge from two or three failed first deliverables. The engineer realizes the client's acceptance criteria are not reviewable in advance — they're discovered through iteration. That's a different kind of engagement than they expected. Some engineers recalibrate. Some leave.

The intervention is not better hiring. It's a structured first deliverable process where acceptance criteria are written before code is written. Not as a contract. As a tool to surface how the client actually makes decisions about work.

Mid-Sprint Context Shift

Six weeks in. The engineer is shipping. The codebase makes sense now. Then a new constraint surfaces. Not in standup. In a chat message from someone three levels up who says, "Actually, we need to be thinking about regulatory compliance here too."

The engineer rebuilds their mental model of what the system needs to do. They reconsider three weeks of decisions. They surface that some of those decisions now conflict with the new constraint.

The client sees this as scope creep pushback. The engineer sees it as a constraint that should have been discussed in week one.

An engineer who has built a mental model once before in a similar industry catches this pattern early. They leave before sinking four weeks into code that will need rework. An engineer newer to the industry or to that domain might not catch it until the rework is done. By then, they're frustrated and looking for exit signals.

This is not a hiring problem. This is a governance problem. The client is not surfacing all the constraints that shape the work. The engineer is being asked to build to a moving target and then blamed for slow iteration. This dynamic is especially acute in nearshore engagements, where timezone gaps make real-time constraint surfacing structurally harder.

The intervention is a governance structure where constraints are documented and reviewed before execution starts. This is not about preventing change. It's about making change visible so it doesn't appear as surprise rework three weeks in.

Why Exits Happen Before Feedback

In co-located teams, all three of these gaps surface in real time. Someone notices the silence. Conversation happens. The model realigns.

In distributed teams, these gaps are invisible until they're costly. An engineer can spend two weeks building to an assumption they don't voice, only discovering the misalignment when the work is reviewed. By then, they've already decided they're not going to do that again. They start job hunting.

This is why the engineers who leave earliest are often the strongest ones. They've built systems in five other companies. They recognize a broken governance pattern faster. They leave before sinking three months into recovery work.

The ones who stay longer are often accepting the broken pattern — building in ways they know are suboptimal, because the engagement is time-boxed and they can absorb the overhead. That's not loyalty. That's calculation.

The worst exit pattern is the one that happens at month four or five. By then, the client has counted on the engineer to be there. The engineer has already determined the governance won't change. They leave at the point where replacement is most costly. And the client's diagnosis is still: we hired wrong.

The Real Diagnostic Question

When an engineer exits mid-project, the useful diagnostic is not: Did we hire the right person?

It's: Which information gap became irreversible before either party surfaced it?

Onboarding gaps are usually fixable in week two. Deliverable review gaps are usually fixable in week three. Context shift gaps are usually fixable in week five. Past week six, the engineer has already made the leave decision.

The next engagement will not succeed with a harder hiring filter. It will succeed with a different governance structure that surfaces information gaps before they calcify into resentment.

Most exits are not about talent. They're about asymmetry. Both sides have information the other needs. Neither has mechanisms to surface it quickly. One side — usually the person taking the delivery risk — decides the overhead is not worth staying.

The intervention is not better screening. It's better disclosure.

Based on delivery data across 30+ enterprise projects in Southeast Asia, 2019–2025.