What to Ask an Offshore Dev Partner About Team Composition

Published by CodeNicely, the product studio founded by Meghal Agrawal and Ujjwal Agrawal in 2017

For: A VP of Engineering or CIO at a 300-person US enterprise who is three weeks from signing a $400K–$800K offshore development contract and has board-level pressure to de-risk it — they have never directly managed an offshore team and are about to approve spend without knowing whose hands will actually touch the code

If you only ask one thing before signing an offshore development contract, make it this: does the SOW name the specific engineers who will do the work, or does it only commit to role titles like "senior engineer" and "tech lead"? If it is the latter, the vendor can legally rotate the entire delivery team the week after kickoff without triggering a change order. The pitch team you fell in love with is a sales asset. The delivery team is a separate roster. This post is the interview script to close that gap — 17 questions to ask about team composition before you countersign, with what a good answer sounds like and what should make you walk.

Context for why this matters more than it used to: Deloitte's 2024 Global Outsourcing Survey found that cost as the primary outsourcing driver fell from 70% in 2020 to just 34% in 2024 — talent access and agility now rank ahead of it. You are not buying hours anymore. You are buying specific humans. And CIO still puts IT outsourcing failure rates at 40–70%, with weak delivery structures a recurring root cause.

Before the questions: the frame

Group your questions into four buckets. Ask them in this order on your technical deep-dive call, and insist the answers end up in the SOW, not the sales deck.

1. Named individuals — who, specifically, is on your account
2. Allocation and attention — how much of their week you actually get
3. Continuity and attrition — what happens when someone leaves
4. Governance and escalation — who you call when it goes sideways

Bucket 1: Named individuals

1. "Can you give me the names, LinkedIn profiles, and GitHub handles of every engineer who will be assigned to this account at kickoff?"

Why it matters: This is the single question that separates a staffing agency from a delivery partner. If they cannot name people three weeks before start, those people have not been identified yet — which means they will be sourced after you sign, from whoever is on the bench or newly hired.

Good answer: "Here is the roster. Four engineers, one tech lead, one QA, one PM. LinkedIn and GitHub attached. Two of them are on another engagement wrapping up March 15 — the other four are available from day one. Happy to schedule 1:1s with any of them this week."

Red flag: "We'll finalize the team after contract signature," or "Our bench is deep, we'll assign the right people." Deep benches are a sales talking point, not a staffing plan.

2. "Which of the engineers in your pitch deck will actually be writing code on my project, and for what percentage of their week?"

Why it matters: The practitioner community openly describes the bait-and-switch — senior engineers used as sales tools during pitches, junior developers doing the delivery at the same billing rate — as "the industry standard at large outsourcing shops." You need a direct, numeric answer.

Good answer: "The CTO you met is not on your delivery team — he does architecture reviews two hours a month. The tech lead from the pitch is on your team at 50%. The three engineers you will meet next week are 100% dedicated."

Red flag: Any version of "the whole team you met will be involved" without percentages attached. Involvement without a utilization number means zero committed hours.

3. "Will the SOW name these individuals by name, and require written client approval to substitute any of them?"

Why it matters: This is the clause. Without it, every other answer in this interview is non-binding. A good vendor will push back a little — they need some flexibility for illness, promotions, and genuine attrition — but they will accept the principle.

Good answer: "Yes. We name the core team in Schedule A. Substitutions require 10 business days' notice, a comparable or better profile, a 2-week overlap for handover, and your written sign-off. The only exception is medical emergency, where we notify within 48 hours."

Red flag: "Our master services agreement covers staffing — we commit to role profiles, not individuals." Translation: we will rotate whoever we need to.

4. "What is the actual years-of-experience distribution on the proposed team, and can you show me three code samples or PRs from each engineer?"

Why it matters: "Senior" means seven years at one shop and two years at another. Code samples cut through the title inflation. If the vendor cannot produce any — even sanitized ones — ask why.

Good answer: A real distribution ("tech lead 11 years, two engineers 6–7 years, one engineer 3 years"), plus sample PRs, architecture docs, or at minimum a technical interview you run yourself.

Red flag: "All our engineers are senior." With India producing 500,000 new software engineers annually and genuine senior talent increasingly scarce, a team that is uniformly senior is either very expensive or very loosely defined.

Bucket 2: Allocation and attention

5. "How many other active client engagements is each named engineer currently on?"

Why it matters: "Dedicated" is the most abused word in offshore contracts. An engineer billed to you at 100% may be split across three accounts in practice.

Good answer: A specific number per person, and a written commitment that your named engineers are single-threaded on your account for the contracted percentage.

Red flag: Vague reassurances about focus. Ask to see their internal resource planning tool on screen if you want to pressure-test it.

6. "What are the actual working hours of overlap with my team's timezone, per engineer, per week?"

Why it matters: A team in Raipur or Bengaluru can give a US East Coast client 3–4 hours of real overlap daily if structured for it, or 45 minutes if not. The difference shows up in velocity.

Good answer: Specific hours per role. Tech leads and PMs skew later to overlap with the US morning; engineers may skew earlier. Written into the SOW as a service level.

Red flag: "We're flexible" without a number.

7. "What percentage of the proposed team is full-time employees versus contractors or subcontractors?"

Why it matters: Subcontracted engineers have different loyalty, different IP exposure, and different attrition dynamics. Not inherently bad — but you need to know, and your legal team needs to know for the IP assignment chain.

Good answer: A clear split, and if subcontractors are involved, the vendor can produce the back-to-back IP assignment agreements.

Red flag: Hesitation, or discovering mid-project that half your team works for a different company.

Bucket 3: Continuity and attrition

8. "What was your voluntary attrition rate for engineers at this seniority level over the last 12 months?"

Why it matters: Industry benchmarks put offshore team turnover above 20% annually, and when engineers rotate out, architecture decisions and edge-case knowledge walk out with them. A vendor who tracks and shares this number is a vendor who manages it.

Good answer: A real number, in the 8–18% range for a well-run shop, with context ("higher in 2023 after the hiring boom, back down to 11% in 2024").

Red flag: "We don't have that metric handy," or an implausibly low number like 3%. Both mean the same thing.

9. "If a named engineer resigns, what is your replacement SLA — and who pays for the ramp-up?"

Why it matters: Replacement is inevitable over a 12–24 month engagement. The question is who absorbs the velocity hit and the knowledge transfer cost.

Good answer: "Replacement within 15 business days with a comparable profile. We fund a 2-week shadow period at our cost. Knowledge transfer artifacts (ADRs, runbooks, onboarding docs) are maintained throughout — not written at exit."

Red flag: Ramp-up billed to you at full rate, or no documented handover process.

10. "Show me the knowledge management artifacts from a comparable past engagement."

Why it matters: Continuity is not a promise, it is a practice. Architecture Decision Records, runbooks, onboarding guides, and a current system diagram either exist or they do not. If they do not, every departure is a crisis.

Good answer: Sanitized samples, on screen, from a real past project. Ideally in a wiki or Notion workspace you can tell is actively maintained (recent edits, multiple contributors).

Red flag: "We can set that up for you" — meaning they do not do it by default.

11. "What is your bus factor for my project? If the tech lead disappears tomorrow, who takes over, and when did that person last touch our codebase?"

Why it matters: A tech lead who is the only person who understands your system is a single point of failure. Good partners engineer redundancy from week one — pair programming, rotating code review, shared on-call.

Good answer: A named backup, with a specific practice ("the tech lead and senior engineer pair on all architecture work; both are current on the full codebase").

Red flag: A long pause.

Bucket 4: Governance and escalation

12. "Who is my single point of accountability on your side, and what is their span of control?"

Why it matters: One throat to choke. If the account manager cannot reassign engineers, approve budget shifts, or escalate to leadership without a committee, you do not have an owner.

Good answer: A named delivery manager or engagement partner with hiring/firing authority over your team and a direct line to the CEO or COO.

Red flag: An "account manager" who is really a salesperson, with a separate "delivery manager" you've never met.

13. "What is your escalation path when I think a named engineer is underperforming, and what is the SLA on resolution?"

Why it matters: You will have this conversation. The question is whether it is awkward and effective, or awkward and theatrical.

Good answer: A documented process — a performance review within 5 business days, a 30-day improvement plan or replacement, no financial penalty on you for raising the concern.

Red flag: "We'll handle it internally" with no transparency into what "handle" means.

14. "Can my team interview and reject any proposed engineer or replacement, including mid-project substitutions?"

Why it matters: Without a veto, your approval rights are decorative.

Good answer: "Yes. 60-minute technical interview with your lead engineer, same bar as your in-house hiring process. You can reject up to two candidates per role before we discuss commercial impact."

Red flag: "You can review resumes."

15. "Will the engineers' employment contracts assign IP directly to my company, or does it flow through the vendor entity?"

Why it matters: IP chain-of-title matters at every future financing, acquisition, or litigation event. Have your lawyer confirm the structure — this is a legal question, not a technical one, and anything I say here is not a substitute for counsel reviewing the actual contracts.

Good answer: Vendor can show the IP assignment clause in their standard employment contract, plus the back-to-back assignment to the client. Full IP ownership transferred on payment, no residual license carved out for the vendor.

Red flag: "Our standard MSA covers IP" without being willing to show the employment-side chain.

16. "What percentage of your engineers' time is billable versus invested in internal R&D, training, and open source?"

Why it matters: A shop that bills engineers at 95% utilization is a shop whose engineers are not learning anything new. The AI tooling landscape alone — Copilot, Cursor, Claude Code, agentic workflows — moves monthly. Deloitte found 83% of outsourcing executives have embedded AI in at least one service line, but only one in four report improved cost or quality — a governance and skills gap, not a tooling gap.

Good answer: A specific carve-out — 10–20% of time for learning, internal projects, or applied AI experimentation.

Red flag: "Our engineers learn on the job."

17. "If I run a 90-day pilot with this exact team and decide not to proceed, what is the exit cost and what artifacts do I keep?"

Why it matters: A vendor confident in their team will structure the engagement so you can leave cleanly. One that cannot is one that expects to retain you through switching cost, not value.

Good answer: Clear exit terms, all code and documentation yours by default, reasonable transition support, no punitive termination clause past the pilot period.

Red flag: Minimum 12-month commitments to get sensible rates, or termination fees that approximate the remaining contract value.

How to run the actual call

Three practical notes.

Send the questions in advance. You are not trying to trap them. You are trying to see how well they answer when prepared. If they cannot answer well with a week's notice, that is the finding.

Insist that the delivery manager and the proposed tech lead are on the call — not just the sales team. If the vendor cannot produce them for a 60-minute pre-sign call, they will not produce them for a Monday standup either.

Capture answers in writing and reference them in the SOW. Verbal commitments made in the sales process have a well-documented habit of dissolving at kickoff. CIO's long-running coverage of the 40–70% outsourcing failure rate points repeatedly to the gap between what was sold and what was contracted.

For US buyers specifically evaluating India-based partners, the market dynamics around US–India engagements have shifted enough in the last two years that older vendor-selection playbooks miss the AI-tooling and talent-scarcity angles entirely. Update your checklist.

One honest caveat

No interview script eliminates risk. McKinsey and Oxford research found that large IT projects run 45% over budget and deliver 56% less value than predicted, and Standish CHAOS data puts large-project success below 10% versus around 90% for small projects. The best team-composition diligence in the world will not save a scope that was wrong on day one. Pair this interview with aggressive scope reduction — ship a narrow pilot first, then expand with the team that proved itself. You will learn more about a vendor from one 90-day delivery than from ten reference calls.

Frequently Asked Questions

Should I ask for named engineers in the SOW or is a role-based commitment fine?

Always push for named engineers in a Schedule A, with substitution requiring your written approval and a comparable-or-better profile. Role-based commitments ("one senior engineer, two mid-level") give the vendor unilateral authority to rotate your entire team. A reasonable vendor will accept naming the core team while retaining flexibility for emergencies — if yours will not, that is itself the answer.

What attrition rate should I accept from an offshore vendor?

Industry benchmarks for offshore engineering attrition sit around 20% annually and higher in hot markets. A well-run shop should be able to show you 8–15% voluntary attrition at the seniority level you're buying, with a replacement SLA of 10–15 business days and a funded shadow period. A vendor claiming sub-5% attrition is either not measuring it honestly or counts people differently than you do.

How much should I budget beyond the contract value for an offshore engagement?

The cost model has three layers: the contracted team rate, the hidden operational costs (your PM time, cloud and tooling, security review, legal), and the friction cost. McKinsey Global Institute analysis suggests budgeting roughly 15–25% of contract value for hidden costs, with communication and cultural friction adding another 2–5%. The two specifics that would turn this into a real quote are the scope boundary (is the vendor delivering a feature set or staffing a team?) and your internal readiness (do you have a product owner who can review work daily?). A conversation with the vendor to pressure-test both assumptions is the only way to narrow the range.

How long does it take an offshore team to reach full productivity?

The shape of the curve matters more than a single number: expect 30–45 days before a well-staffed team is operating at steady velocity on a new codebase, longer if your domain is complex (regulated industries, legacy integrations) or your documentation is thin. What moves it fastest is a tech lead who overlaps with your team for the first two weeks, pre-written onboarding docs, and a narrow starting scope. What slows it most is unclear ownership on your side.

Can I interview offshore engineers before they're assigned to my project?Yes, and you should insist on it in writing. A 60-minute technical interview with the same bar you'd apply to an in-house hire is standard, non-negotiable, and should include veto rights over replacements. Vendors who resist this are protecting themselves from the discovery that their bench is thinner than claimed.