The most common misconception about a Virtual Delivery Center is that it's "just a team of remote engineers, but managed." It isn't. A VDC pod is a deliberately composed unit with role-specific responsibilities, a delivery manager who's part of the pod (not external to it), and an embedded governance layer that distinguishes it from staff augmentation. The composition is what makes the model work.
This piece walks through the standard pod composition, what each role does, how the composition changes as the engagement matures, and the questions to ask when you're scoping a new pod against your specific outcomes.
The standard pod composition
A baseline VDC pod for a software-delivery engagement contains five roles. Different engagements emphasize different ones, but the structure is consistent:
- Delivery Manager — owns engagement-level delivery, governance, milestone reporting.
- Tech Lead / Senior Engineer — owns architectural decisions, code review SLAs, technical mentorship within the pod.
- Specialist Engineers (2–6) — backend, frontend, data, ML, infra — composed against the specific outcomes.
- QA / Test Engineer — owns test strategy, automation, acceptance gates.
- Designer (when product work is in scope) — UX/UI specialist embedded with the build team.
Below this baseline, individual pods may be smaller (2–3 specialists for a focused engagement) or larger (8–10+ for transformation programs). What stays constant is the delivery manager and tech lead — these aren't optional even for small pods. Removing them turns the engagement back into staff augmentation.
Role 1: Delivery Manager
The delivery manager is the role that distinguishes a VDC from any other external-delivery model. They aren't a project manager wearing a different title — the responsibilities are operationally different.
What the delivery manager owns:
- Sprint cadence and ceremonies (standups, planning, retrospectives, demos).
- Code-review SLAs — ensuring reviews happen within agreed turnaround.
- Milestone definition, milestone tracking, milestone-acceptance flow.
- Escalations — both technical (to the platform's engineering layer) and contractual (to the client).
- Pod-internal capacity decisions — when to add a specialist, when to rotate someone out.
- Reporting cadence with the client (typically weekly milestone summaries plus monthly engagement reviews).
What the delivery manager doesn't do: write production code, make individual technical-architecture decisions (that's the tech lead), negotiate contractual terms (that's the platform's engagement architect).
The delivery manager is the pod's accountable owner. When the pod misses a milestone, the delivery manager owns the remediation conversation — not the engineers.
Role 2: Tech Lead / Senior Engineer
The tech lead is the senior-most engineering voice in the pod. They're a producer too — typically writing 30–50% of the time — but their primary value is architectural and mentorship.
What the tech lead owns:
- Architectural decisions within the pod's scope (data model, service boundaries, library choices, integration patterns).
- Code review for the rest of the pod's specialists. The tech lead is the final reviewer on most non-trivial PRs.
- Technical risk surfacing — flagging "this approach won't scale past X" or "this library has a known security issue" early.
- Mentorship for mid-level pod members.
- Liaison with the client's senior engineers when architectural alignment is needed.
The tech lead is the role most analogous to a senior engineer on an in-house team — but with an explicit mandate to push architectural decisions back to the client when they affect downstream systems.
Role 3: Specialist Engineers
The variable part of the pod composition. Specialist engineers are matched to the specific outcomes the engagement requires. A few common compositions:
| Engagement type | Typical specialist mix |
|---|---|
| New product build (web) | 2 backend, 2 frontend, 1 infra/DevOps |
| Mobile app build | 2 mobile (iOS/Android), 1 backend, 1 designer |
| Data platform / pipelines | 2 data engineers, 1 backend, 1 platform engineer |
| ML feature delivery | 2 ML engineers, 1 data engineer, 1 backend |
| Modernization / replatforming | 2 backend, 1 frontend, 1 infra, 1 QA |
| Integration / API work | 2 backend, 1 platform engineer, 1 QA |
Specialist seniority distribution typically lands at one senior, two mid, and one junior — not a flat senior team. Mixed seniority is deliberate: cost-efficient, mentorship-rich, and matches how a healthy in-house team would be staffed for the same work.
The full role catalog spans more specialisms than this snapshot — see the role index for what specific specialism categories are available.
Role 4: QA / Test Engineer
QA is sometimes treated as optional in early-stage engagements. It usually shouldn't be. A dedicated test engineer in the pod owns:
- Test strategy across the engagement — what gets unit tested, what gets integration tested, what gets manual smoke-checked.
- Test automation — building and maintaining the test suite alongside the production code.
- Acceptance gate enforcement — milestone acceptance is contingent on passing the test bar, not just the engineer's "done" claim.
- Performance and load testing where engagement scope warrants.
The reason to keep QA in the pod (vs. relying on the client's QA team): tight feedback loops. A QA engineer embedded with the pod catches issues during the same sprint they're introduced. A separate QA team catches them after the sprint, when context has decayed.
Pods without a dedicated QA engineer push test responsibility onto the specialist engineers. That works for engagements with mature testing culture and clear scope, but it adds risk for new builds or when scope is shifting.
Role 5: Designer
Included when product work is in scope — anything that ships UX, UI, or customer-facing flows. The designer is responsible for:
- UX research and validation (where engagement scope includes it).
- UI design, design system contribution, component library work.
- Interaction patterns, accessibility, and visual quality.
- Liaison with the client's design team if one exists.
For pure backend or infrastructure engagements, the designer role isn't included. For anything customer-facing, the engagement quality drops noticeably without one — engineers can ship working UI, but they can't ship great UI.
How the composition changes as engagement matures
Pod composition isn't static. Healthy engagements rebalance over time:
- Months 0–3: Standard composition. Heavy emphasis on tech lead and senior specialists for setup, architectural decisions, foundational code.
- Months 3–6: Specialist mix may shift. The original composition was right for setup; the steady-state work might need different specialism ratios. Pod recomposes without contract amendments.
- Months 6–12: Possible specialist rotations. Some senior specialists rotate off as foundational work completes; mid-level specialists handle the steady-state delivery.
- Months 12+: Long-running pods often slim to a maintenance composition: one senior, 2–3 mid-level, one QA. Or expand if scope grows.
The platform handles recomposition. The client doesn't sign a new contract every time the pod size changes — that's a defining feature of the model vs. staff augmentation where every change is a new requisition.
Questions to ask when scoping pod composition
When the platform proposes a pod composition for your engagement, the questions worth running:
- Why this specialist mix? (Force the platform to articulate the reasoning, not just propose numbers.)
- What seniority distribution, and why? (Flat-senior pods are usually expensive overkill.)
- How does composition change at month 3, month 6? (Tests whether the platform thinks about evolution.)
- Who's the named delivery manager, and what's their experience? (The DM is the most important role; vague answers are a flag.)
- What happens if a specialist underperforms? (Replacement clause should be platform-default.)
The full version of these questions is in the adoption checklist. Pod composition is the first practical question after the contract; getting it right matters more than most other decisions.
Frequently asked questions
How big is a typical pod?
4–8 people is the sweet spot. Below 4, the role overhead (DM + tech lead) is a high percentage of the pod cost. Above 8, sub-pod coordination starts adding overhead. For very large engagements, multiple pods coordinated by an engagement architect is the pattern, not one large pod.
Can the delivery manager be part-time across multiple pods?
Sometimes for very small pods (2–3 specialists), the DM can split across two pods. Above that size, it's a full-time role. A part-time DM on a 6-person pod is the most common cause of delivery friction.
What if I want to add a specific role mid-engagement?
Standard. The platform handles the addition without contract amendment — pod composition is a configuration decision, not a contractual one. Time to onboard a new specialist into an existing pod is typically 5–10 days.
Do pod members work full-time on our engagement?
Specialists typically yes; the delivery manager and tech lead are full-time on the pod when the pod is active. The exception is some senior specialists (e.g. an architect) who may be at 50% allocation when their work is intermittent.
Where to start
If you're scoping a new VDC engagement, the first concrete question after agreeing on outcomes is "what does the pod look like?" Use this article as the input for that conversation. Push the platform to articulate composition, seniority, and evolution — not just propose a team size.
To talk through pod composition for your specific engagement, schedule a 30-minute call. We'll walk through the outcomes you're after and propose a pod composition with named seniority levels.
For broader context on how a VDC differs from other delivery models, see what is a Virtual Delivery Center and the VDC vs Staff Augmentation comparison.