You asked a question in Slack. Not a hard one: does the new auth call go through the API gateway like everything else, or straight to the service? The engineer who wrote the code is in the channel and clearly online. He does not reply. Fourteen hours later a delivery manager you have met twice answers by email, with a paragraph that does not answer it, and adds that questions should come through him “for tracking purposes”.
Then in sprint review you ask that same engineer whether three days is really enough for the migration, and you watch his eyes move to his project manager before he says yes.
You are not imagining it, and these are not shy people. Almost everything that feels strange about working with an offshore consultancy team is the visible surface of a commercial structure: a contract that names one person as the communication channel, an appraisal written by managers you will never meet, and a utilisation target that turns every hour into an accounting entry. The engineer is not being evasive. He is making the only rational move available to someone whose rating, bonus and next assignment are decided at the other end of that reporting line, not by you.
Read the org chart, not the team
You think you are working with a team. You are working with a slice of a delivery organisation with at least four layers between the person writing code and the person who signs your invoice, each layer existing for reasons that have nothing to do with your sprint.
- The account or engagement manager. Owns the commercial relationship, the P&L and a revenue target on your account. Usually not technical, often in your country.
- The delivery manager. Owns milestones, margin and the escalation surface. This is the person who answered your Slack question by email.
- The offshore project manager or module lead. Runs the pod, assigns tickets, writes the appraisal input for each engineer, reports status upward daily.
- Resource management. A real, named function: TCS’s 2025 deployment policy was issued by its Global Head of the Resource Management Group. RMG decides who is on your account and where they go next. You will never meet them, and they will change your team.
- The engineers. Who you thought you hired.
The single-channel rule on top of that is deliberate, and three things drive it. Commercial protection: an engineer who says “sure, we can squeeze that in” has given away scope that was priced, and unpriced scope comes off margin. Change-request revenue: conversations about work outside the statement of work are potential invoice lines, so they belong where someone can price them. Escalation control: if a problem reaches your CTO before it reaches the account manager, that manager learns about their own account from an angry client, which is the worst day in the job.
None of that is about you being difficult; it would apply to any client. The cost is that the shortest path between two engineers now runs through two managers and a mailbox.
Why an offshore consultancy engineer cannot tell you the estimate is wrong
In-house engineers find this the hardest part to believe, because at your company telling the truth about an estimate is the job. So ask who writes his appraisal.
Not you. His project manager writes the input, the delivery manager moderates it, and both are measured on milestone dates and on whether the account is green. That rating drives his increment, his promotion, his chance of an onsite assignment. You feed into it only indirectly, through a satisfaction score his management collects and interprets.
Then add billability. Large IT services firms run on utilisation and they publish it. Infosys reported utilisation of 82.1% including trainees and 84.9% excluding trainees for the quarter ended 30 June 2026, across a headcount of 328,062. That is no abstraction to an individual. Indian business press reported an internal TCS policy effective 12 June 2025 requiring associates to be allocated for at least 225 business days in a rolling twelve months, capping bench time near 35 business days, with the memo warning that long unallocated periods would affect compensation, career growth, overseas deployment and continuity of employment. Infosys has framed its own approach differently, its CEO describing training and learning projects before deployment. Either way, a seat on a live client project is what stands between an engineer and a conversation with resource management.
Now sit in his chair in that sprint review. He thinks the migration is a week. Saying so contradicts his PM’s committed date in front of the client and makes him the person who turned the account amber. The upside is that you get a better date. The downside lands on him, six months later, in a rating conversation he cannot appeal. Silence is not cowardice. It is correct play.
Amy Edmondson’s research is the right frame here, and worth quoting accurately. Her 1999 study in Administrative Science Quarterly, covering 51 work teams and 427 people at an office furniture manufacturer, defined team psychological safety as “a shared belief that the team is safe for interpersonal risk taking”. Teams that had it engaged in more learning behaviour, and that behaviour, not the belief alone, is what improved performance. Her earlier 1996 work across eight patient care units in two hospitals produced the finding that should stay with you: units with better nurse manager coaching and better relationships reported more detected medication errors, not fewer. Quiet is not safety.
An offshore pod has close to zero psychological safety with respect to you, and that is structural, not personal. They may be entirely candid with each other at 9pm in their own language. Candour in a client-visible channel is simply priced differently for them.
Why people vanish mid-sprint
A developer who has been in your standup for four months stops appearing. Nobody mentions it. Three days later someone new asks for repo access, and you are told the first person was “moved to another project”. The mechanics are mundane and almost never malicious:
- Allocation, not resignation. A larger deal closes and needs credible CVs on day one. Your account is stable, so it is a safe place to pull from. Internally that is routine reallocation. To you it is the loss of the only person who understood your billing edge cases.
- Onsite and visa moves. An onsite assignment is a major pay and career event, timed by visa slots and client start dates, not your release calendar. Nobody declines one for your sprint.
- Bench pressure in reverse. Where policy punishes unallocated time, people take whatever role appears rather than wait for the right one, raising churn across every account.
- A resignation you were never told about. Notice periods of 60 to 90 days are common in Indian IT. The person may have resigned ten weeks ago. Disclosing it early looks like instability on the account.
None of this shows up in the attrition figure in your QBR deck. Infosys reported voluntary LTM attrition of 13.0% in IT services for the June 2026 quarter, and firms in that band really are in their calmer years. But attrition counts people leaving the company. What hurts you is people leaving your codebase, and that number is larger, unpublished, and not treated as a defect at all.
“Resource” is not an insult, and that is the problem
The first time you hear “we will allocate two more resources next sprint” it lands badly. Worth understanding what the word is doing rather than just resenting it. In a services P&L a person on a project is a unit of billable capacity with a cost rate, a bill rate and a utilisation percentage. “Resource” is the accounting category, travelling with “ramp up”, “fungible”, “FTE” and “backfill” because they all come from one model. Nobody picked the vocabulary to dehumanise anyone. It is what you get when the unit of planning is an hour instead of a person.
What it reveals is still real: a system that models people as interchangeable capacity will, under pressure, treat them that way. That is why the person who knew your system was replaced by someone with a matching skills matrix and no context. One cheap countermeasure: name individuals in writing, in front of their managers, when something goes well.
Badges, segregated networks and the screen share that never happens
You ask someone to share their screen and they cannot. A repo invite bounces because personal GitHub accounts are blocked. A quick call requires moving to a different room. That is usually an offshore development centre: a separated floor or cage, badge access limited to staff cleared on your account, USB disabled, phones sometimes left outside, filtered internet, and work done on a locked-down VDI that renders your IDE at about eleven frames per second. Client code cannot leave the network segment.
Here is the part that surprises people. Those controls were frequently specified by your company. They sit in the security schedule your procurement and infosec teams wrote, they get audited, and the vendor is contractually obliged to enforce them. So if the restrictions are making collaboration impossible, the conversation is not with the delivery manager. It is with your own security team, about giving named individuals access to your environment, on your identity provider, with your logging. That is usually both safer and more workable than a mirror environment nobody can see into.
Change requests are the profit centre, and the contract shape sets the behaviour
In a fixed-price contract the vendor is paid an agreed sum for an agreed scope, and margin is the gap between that sum and the hours burned. So the change request is not an administrative annoyance. It is the main way a fixed-price account grows revenue after signature, and account managers carry targets that assume it.
See that and a lot of baffling behaviour resolves. The PM interrupts when you describe what you actually need, because the description is drifting past the requirement document and someone has to catch it before it becomes an expectation. “Please raise a ticket” is routing that ties work to a priced line. The engineer builds the literal ticket rather than the obviously intended thing, because the intended thing is unbilled hours and an argument at acceptance.
| Model | What the vendor optimises | What you will observe |
|---|---|---|
| Fixed price, fixed scope | Hours burned below the agreed price; change requests for everything else | Hard ticket boundaries, gatekeeping, “that’s a CR”, defensive status reporting |
| Time and materials, dedicated capacity | Filled seats and renewal | Far more direct access, questions are cheap, no built-in pressure to be fast; you direct the work |
| Outcome or managed service | Hitting the measured outcome at the lowest staffing cost | Strong SLA reporting, little visibility into how, arguments over whether an incident counts, staffing thinned once green |
You probably cannot choose the model. Knowing which one you are in still tells you which fights are winnable. Asking for casual engineer-to-engineer access on a fixed-price milestone contract is asking someone to surrender their margin protection. Asking for it on a capacity deal is asking for something the vendor has no commercial reason to refuse, and a refusal there is information.
What actually works from your side of the table
You cannot rewrite a consultancy’s appraisal system. You can change local conditions enough that useful information starts reaching you.
Get a direct channel written down. A shared Slack Connect or Teams channel, named people in it, plus a line in the governance document saying technical clarification between engineers is not a scope change or a commitment. That clause is what makes the channel safe for the vendor to allow.
Ask for named individuals and rotation notice. Names in the schedule, minimum assignment terms, 30 days’ notice before anyone is moved, a paid overlap for handover. That is a renewal conversation, run through your own procurement.
Change the question so it is safe to answer. “Is three days enough?” forces a person to contradict their manager in public. These do not:
- “What would you need to be comfortable with three days?”
- “What’s the riskiest assumption in this estimate?”
- “If this slips, which part slips first?”
- “What do you know about this module that isn’t in the ticket?”
Each lets an engineer surface a real problem as technical information rather than dissent. Ask them in a working session, not on a status call with the account manager listening.
Build safety deliberately and visibly. When someone raises a problem, thank them by name in writing, in the channel their manager reads, and say the early warning saved the project time. Do that twice and you have changed the local payoff for candour more than any process document will. And never criticise an individual in a client-visible forum; it goes into their appraisal. Raise it as a process issue, then tell the delivery manager privately that you do not want it landing on a person.
Write the definition of done yourself. Tests at the level you specify, passing CI, documentation in the repo, deployed to your staging environment by the author, reviewed by one of your engineers. Unwritten, “done” quietly becomes “demonstrated on a screen share”, because that is the cheapest defensible reading and nobody is being paid for the rest.
Escalate up your side, not theirs. Go to the delivery manager angry about an engineer and the pressure lands on the engineer. Have your engineering manager raise the pattern with the account manager in writing, framed as delivery risk rather than individual failure. Keep dates and impacts. What moves a consultancy is something an account manager has to answer for in a governance meeting.
Give context relentlessly. Incident history, why one endpoint is special, who the user is, what broke last time. Free, and the highest-leverage item here, because an engineer who understands the why guesses better on the many occasions when asking you is not worth the risk.
Related reading
- When Outsourced DevOps Builds It and You Get the Pager
- How to Fix an Underperforming Offshore Dev Team in Six Weeks
Questions in-house engineers ask next
Should I just DM the developer anyway? Careful. Where a single-point-of-contact rule exists, a developer who answers you directly may be breaking an instruction, and you will not be the one who pays for it. Get the channel sanctioned openly instead, even informally with the delivery manager.
Is this specific to Indian consultancies? No. It tracks the delivery model, not the country. The same gatekeeping and change-request reflex appear in large European and North American systems integrators on fixed-price work, and mostly vanish in a captive centre or staff augmentation setup in the same cities, because the reporting lines and the money work differently.
Someone was “moved” and I need what they knew. What now? Email the delivery manager asking for a recorded handover session with both people before the leaver’s last day on the account. Vendors usually agree, because refusing a handover in writing looks bad in a governance review.
Are the offshore engineers actually less capable? Overwhelmingly no, and that is the argument of this whole piece. You are watching competent people respond correctly to a payoff structure that is not yours. Put the same engineers somewhere they own a service, talk to real stakeholders and have a manager who rewards raising problems, and the behaviour changes inside a month.
If your honest conclusion is that you need engineers inside your standups and your repo rather than behind an account manager, that is the model AB7 Solutions works in: named remote professionals and contract engineers you interview yourself, working to your delivery process, with rotation notice and handover overlap agreed up front instead of discovered mid-sprint. Happy to read your current governance model and say which parts are genuinely renegotiable. Call +1 321 341 7733, email ab@ab7solutions.com or director@ab7solutions.com, or start at www.ab7solutions.com. If your existing vendor is the right one and only the contract needs fixing, we will say that instead.
Sources: Infosys, Q1 FY2027 fact sheet (utilisation 82.1% including trainees, 84.9% excluding; voluntary LTM IT services attrition 13.0%; headcount 328,062); Outlook Business on TCS’s deployment policy effective 12 June 2025 (minimum 225 allocated business days, bench capped near 35 days), based on an internal memo first reported by the Times of India; Republic World on Infosys’s contrasting deployment approach; A. C. Edmondson, “Psychological Safety and Learning Behavior in Work Teams”, Administrative Science Quarterly 44(2), 1999 (51 teams, 427 members); A. C. Edmondson, “Learning from Mistakes is Easier Said than Done”, Journal of Applied Behavioral Science 32(1), 1996 (8 patient care units, 146 respondents).
Related AB7 service: remote IT and technology staffing.