The engineers who pitched are not the engineers writing the code

You can settle this in an afternoon, and you should, because the version of the conversation that starts with an impression never ends anywhere. Pull the commit log for the last three weeks, list the authors by volume, and compare that list against the names in the proposal. The gap between those two lists is the whole diagnosis.

What you do next depends on which of four things produced the gap. Only one of them is the thing people mean by bait and switch, and the responses that fit the other three are much cheaper.

The three records that settle it

Take all three together. Any single one has an innocent explanation; all three pointing the same way does not.

Do this at the end of week 3, not week 12. Three weeks is long enough for real work to exist and short enough that a correction is still cheap. If you have no repository access at all, that is a finding in itself and a much larger one than staffing.

Four causes that produce the same symptom

1. A specialist rotation nobody explained

The most common cause, and mostly harmless. A data engineer appears for the migration, a mobile specialist for two sprints, an evaluation engineer to build the labelled set that a release gate depends on — the work described in turning production traffic into labelled cases. Signature: the new names appear alongside the annex names rather than instead of them, and their commits cluster in one part of the codebase. Response: ask for the rotation plan and have it added to the annex. This is a communication failure, not a staffing one.

2. The senior was pulled onto a sales cycle

Small firms pitch with their strongest engineers because that is who wins work, and those engineers are then needed for the next pitch. Signature: the named lead is still present at demos and client calls, with commit volume that has fallen steadily rather than stopped, and pull-request reviews that arrive later each week. Response: convert the expectation into a number. A lead at 20% who reviews everything is a defensible arrangement; a lead at 20% still described as leading delivery is not — the artefacts that make this checkable are set out in what a dedicated team does not promise.

3. An undisclosed subcontract

The one with consequences beyond delivery quality. Signature: author emails on an unfamiliar domain or personal addresses, a work pattern in a time zone nobody mentioned, no overlap with your working hours, and reviewers who never speak on calls. This matters for reasons that are not about skill — an undisclosed party has your repository access, possibly your data, and sits outside whatever the contract says about subprocessors and confidentiality. Response: stop treating it as a staffing conversation and ask for the subcontracting position in writing, along with the access review.

4. The bid was staffed with people who were never free

The genuine failure. Signature: the annex names have zero commits, zero reviews and no working-session attendance from day one, and the substitute names were not introduced at all. This is usually visible in the proposal before signature if you know what to read for — a team section with no allocation percentages and no start dates is a team section that was written to be flexible, which is one of the tells in reading a proposal as a diagnostic.

A rotation you were told about is a staffing decision. A rotation you discovered is a disclosure problem, and the disclosure problem is the one that predicts what else you have not been told.

The response that matches the cause

One pattern worth watching across all four: a substitution and a sudden increase in change requests often arrive together, because a team that did not scope the work does not recognise what the brief implied. If both are happening at once, read everything is now a change request alongside this page, because the underlying cause may be single.

Escalating without burning the work

In order, because each step costs more than the last and most engagements resolve at step 2.

1. Ask in writing, factually. "The annex names A and B. Weeks 1 to 3 show 4 commits from A, none from B, and 61 from C and D, who are not in the annex. Can you explain the staffing?" Numbers make the reply concrete; adjectives invite reassurance.
2. Require a reissued annex. Names, roles, allocation percentages, start dates. If the substitutes are genuinely good, this costs the supplier nothing and settles the matter.
3. Invoke the notice period if you have one, and if you do not, agree one now for the remainder. A supplier acting in good faith will accept a forward-looking notice term even where the contract lacked it.
4. Shrink the horizon. Move from an open-ended engagement to a bounded milestone with a defined output. This limits exposure while the substitutes prove themselves, and it is reversible in a way that termination is not.
5. Re-let, but only after the current milestone lands. Stopping mid-milestone leaves you owning half-finished work with no author available to explain it, which is a worse position than the one you are trying to leave.

When the substitution is not the real problem

Two situations are worth separating out before you spend goodwill on this. The first is where the substitutes are producing better work than the people who pitched, which happens more often than the industry admits — the strongest presenter is not reliably the strongest engineer. If velocity, review quality and defect rate are all fine, the complaint is about process rather than outcome, and the fix is disclosure discipline, not a personnel change.

The second is where the code has genuinely deteriorated and staffing is only the visible half. Rising defect counts, longer review cycles and a codebase drifting from the agreed architecture are worth measuring on their own terms, because they persist through any staffing change. If you are at that point, scoping a bounded piece of work with a clear definition of done — the shape we run as MVP and product builds — is a more useful next step than arguing about names.

The surrounding decisions, from vendor selection through to what a supplier can reach inside your systems, are mapped across deciding what to build and who builds it in the library.

• vendor management
• delivery
• procurement
• diligence