How do you know if your team is being quietly rotated?
Some rotation is legitimate and expecting none is unrealistic. People resign, take parental leave, get promoted, and a supplier who never changes anyone is either unusually lucky or not telling you. What matters is whether changes are disclosed and handed over, or absorbed silently in the hope you will not notice. The second is common, and the evidence is in your repository rather than in your invoices.
Why does silent rotation happen at all?
Because a supplier's business is a utilisation problem. Engineers are a fixed cost and engagements are variable, so every supplier is continuously matching people to accounts. When a larger or newer client needs a specific skill, the pressure to move someone off a stable long-running account is structural rather than malicious.
It stays hidden because the client-facing surface does not change. The invoice is identical, the standup has the same number of participants, and the team lead still attends every meeting. Unless you look at who is writing the code, there is nothing to notice.
It also happens in a milder and more defensible form: an engineer stays nominally on your account while working substantially on another. Half a person for the price of one is harder to detect than an outright substitution and is the more common version by some distance.
What are the signals?
Changes in the commit history are the clearest and the least deniable. New author names, or a familiar name whose commit pattern changes shape, or contributions from someone you have never met. You have access to this and it takes five minutes a month.
Then the behavioural signals. Questions being asked that were settled a year ago, particularly about domain rules. A drop in the confidence with which the team discusses areas they used to know. Estimates becoming vaguer or larger for work in familiar parts of the system. Any of these individually means little; two together in the same month is worth a direct question.
The meeting signals are softer but real. Cameras going off, a lead answering questions that used to be answered by the engineer who did the work, and new voices introduced as helping out or covering. Covering is the word that most often precedes a permanent substitution.
| Signal | Where you see it | Benign explanation | Worrying if |
|---|---|---|---|
| New commit authors | Repository history | Disclosed joiner, planned rotation | Nobody told you and the name is unfamiliar |
| Settled questions reappearing | Chat, tickets, planning | Genuinely ambiguous rule | Repeats across several domain areas in one month |
| Estimates growing on familiar work | Planning sessions | Newly discovered complexity | The area has not changed and the estimate has |
| Lead answering for engineers | Standups and demos | Engineer on leave | It becomes the normal pattern |
| Slower responses in overlap | Chat timestamps | Incident elsewhere, one-off | Sustained, with vague explanations |
| Rework rising on recent features | Ticket history | A hard piece of work | It concentrates in areas one person used to own |
How do you check without accusing anyone?
Ask for the same information routinely rather than suspiciously. A monthly staffing line in the report, listing who is on the account, at what allocation, and any changes since last month, is a normal thing to request and a normal thing for a well-run supplier to provide. Requested from the start it is administration; requested in month nine it is an accusation.
Look at the repository yourself. Contributor lists by month are available in every hosting platform and require no engineering skill to read. You are not auditing productivity, only continuity, and a stable set of names is exactly what you want to see.
When you do ask, ask about the arrangement rather than about the person. Has anything changed in the staffing this month is a question with an easy honest answer. Why is Marcin not committing any more puts a lead in a defensive position and often produces a technically true answer that tells you nothing.
What is reasonable turnover and what is not?
People leaving their employer is normal and no supplier can prevent it. What distinguishes a good supplier is what happens around a departure: advance notice where they have it, an overlap period where the leaver hands over to their replacement, and no expectation that you pay twice for the same knowledge.
Unreasonable is a substitution you learn about from the commit log, a replacement with no overlap, a replacement at a lower seniority than the person who left, and a pattern of departures concentrated on your account while the supplier's other work appears stable. That last pattern usually means your account is the one being drained to staff others.
The seniority question is worth watching specifically. Replacing a senior engineer with a mid-level one at the same rate is a margin decision dressed as continuity, and it is visible in the work within about two months, usually as a rise in review comments and rework.
What should the contract say about staffing?
Name the team, with roles and seniority levels, in the contract rather than in the proposal. Then require written notice of any change, a minimum overlap between a leaver and a replacement, and a right of approval or at least of interview for replacements at senior level.
Add an exclusivity statement: named team members work only on your account during the agreed allocation. This is the clause that addresses the half-a-person problem, and it is more useful in practice than any turnover cap because it describes something checkable.
State who pays for ramp on a replacement. The reasonable position is the supplier, since you already paid to build that knowledge and did not choose the departure. Suppliers push back on this less than expected when it is raised before signature, and almost always when it is raised afterwards.
What do you do when you find it?
Raise it once, directly, with the account manager rather than the team lead, and ask for the staffing history in writing. The lead is often not the decision maker here and putting them in the middle of it damages the working relationship you depend on daily.
Judge the response rather than the incident. A supplier who acknowledges it, explains the pressure that caused it, and proposes something concrete is worth continuing with. One who disputes what you can see in the commit history has told you what the rest of the engagement will be like.
If it persists, the practical lever is not a penalty clause but the exit terms and your own knowledge position. This is the moment people discover whether accounts are in their name and whether anyone internal can deploy the system, which is why those things are worth arranging long before you have a reason to care.
Common questions
- How can I tell if my outsourced developers have been swapped?
- Check the repository contributor list by month, which every hosting platform provides and which requires no engineering skill to read. New author names you were not told about, or a familiar name whose contributions stop, are the least deniable evidence. Supporting signals include settled domain questions being asked again, estimates growing on familiar areas, and a team lead beginning to answer for engineers who used to speak for their own work.
- Is developer turnover on an outsourced team normal?
- Yes. People resign, take leave and change roles, and no supplier can prevent it. What distinguishes a good one is the handling: advance notice where available, an overlap between the leaver and the replacement, a replacement at equivalent seniority, and no expectation that the client pays twice for the same knowledge. Substitutions discovered from the commit log rather than from the supplier are the problem, not turnover itself.
- Why do suppliers move engineers off an account quietly?
- Because engineers are a fixed cost and engagements are variable, so suppliers continuously match people to accounts. When a larger or newer client needs a particular skill, the pressure to move someone from a stable long-running account is structural. It stays hidden because nothing client-facing changes: the invoice is identical and the standup has the same number of participants.
- What contract terms prevent silent team rotation?
- Name the team with roles and seniority in the contract rather than the proposal. Require written notice of changes, a minimum overlap between leaver and replacement, and approval or interview rights for senior replacements. Add an exclusivity statement that named members work only on your account during the agreed allocation, which addresses partial reassignment. State that the supplier funds a replacement's ramp.
- What should I do if I discover my team was changed without notice?
- Raise it once with the account manager rather than the team lead, and ask for the staffing history in writing, since the lead is usually not the decision maker and putting them in the middle damages a relationship you rely on daily. Judge the response rather than the incident: acknowledgement with a concrete proposal is workable, while disputing what is visible in the commit history indicates how the rest of the engagement will go.
- What is partial reassignment and why is it hard to spot?
- It is when a named engineer remains on your account but spends much of their time on another, so you pay for a full allocation and receive part of one. It is harder to detect than outright substitution because the same person still attends meetings and still commits code. The visible symptoms are slower responses during the overlap window and delivery that stretches without any change in the work.
