The delivery manager is the role that distinguishes a Virtual Delivery Center from any other external delivery model. Remove the delivery manager and you have staff augmentation. Replace them with a "project coordinator" or "engagement lead" wearing a different title, and you have staff augmentation with marketing copy.
This piece walks through what the delivery manager actually does, why the role is structurally different from a project manager, the daily/weekly/monthly cadence they run, and how to evaluate whether your pod's DM is doing the job well.
The DM owns operational delivery
A traditional project manager coordinates. A VDC delivery manager owns. The difference shows up in five places:
- Sprint cadence is theirs. Standups, planning, retrospectives, demos — they run them. Not "facilitate," run.
- Code-review SLAs are theirs. If reviews are slow, the DM intervenes — reassigning reviewers, escalating blockers, surfacing patterns.
- Milestone delivery is theirs. Missed milestones are the DM's accountability, not the engineers' or the platform's at large.
- Pod-level decisions are theirs. When to add a specialist, when to rotate, when to push back on scope — the DM has authority to act.
- Customer relationship is theirs. Weekly check-ins, monthly engagement reviews, escalations — single point of contact.
The DM isn't above the engineers organizationally; they're a peer with operational ownership. The engineers report functionally to the platform's engineering layer; the DM reports to the platform's engagement architect for the engagement itself.
What a good DM does on a daily basis
A typical day for a VDC delivery manager during steady-state engagement:
- Async standup review. Reads the pod's daily updates (typically posted in Slack or Teams). Notes blockers, dependencies, schedule risks.
- Customer touchpoint. 1-2 brief async messages with the customer's primary contact — milestone status, surfaced questions, decision needs.
- PR review oversight. Confirms code reviews are flowing within SLA. Intervenes when they're not.
- Escalation triage. Anything blocking the pod gets owned by the DM until resolved.
- Forward planning. Looks 2–3 sprints ahead. Notices when current trajectory won't hit a future milestone and proposes corrections early.
None of this is glamorous. All of it compounds. A DM who skips the forward-planning beat for two weeks is the DM whose pod misses a milestone in week 4.
Weekly cadence
The DM runs a defined weekly rhythm:
- Monday: Sprint planning if applicable; weekly customer status update.
- Daily: Async standup review.
- Wednesday: Mid-sprint check on milestone trajectory.
- Friday: Sprint demo if it's the end of a sprint; week-in-review note to customer.
The cadence is calibrated to the engagement during onboarding. Some engagements want daily customer touchpoints; some want weekly only. The DM adapts but doesn't drift — predictable rhythm is part of what makes the pod feel embedded rather than outsourced.
Monthly cadence
Monthly responsibilities that don't appear in the daily/weekly grind:
- Engagement review. 60-minute deep dive with the customer's engineering leadership. Velocity, governance, risks, looking-forward.
- Pod composition check. Is the current specialist mix still right for the work? Should anyone rotate? Is the seniority distribution healthy?
- Risk-register update. What's been resolved, what's new, what's escalating?
- Platform sync. The DM reports to the platform's engagement architect. New patterns from this engagement get shared back; lessons from other engagements get applied here.
How to evaluate whether your DM is doing the job
Six observable signals:
- You don't run standups. If you're running them, the DM isn't owning them.
- Code reviews flow without your involvement. The pod's tech lead approves; you only see merged PRs unless you opt into review.
- Milestone status is proactively communicated. You don't have to ask. The DM tells you.
- Risks surface early. Issues are flagged before they become missed milestones, not after.
- Escalations resolve at level 1. Most problems get solved in pod-DM conversations without needing the platform's engagement architect or your engineering VP.
- Composition adjustments are proactive. The DM proposes pod changes when they see the work shifting; you don't have to ask for them.
Missing any one of these is a yellow flag. Missing three or more is the engagement's biggest fixable problem.
What a DM doesn't do
To stay clean about the role's boundaries:
- They don't write production code. Some DMs come from engineering backgrounds and could; the role is operational, not implementation.
- They don't make architectural decisions. They can suggest and provide inputs.
- They don't negotiate contracts. That's the platform's engagement architect.
- They don't replace your product owner. Scope and outcome definition is still your team's call; the DM facilitates and surfaces but doesn't own product strategy.
How DMs handle missed milestones
Worth its own section because it's the test case for the role. When a milestone is missed:
- The DM owns the conversation. Not the engineers. Not the platform's account team. The DM communicates the miss, the cause, and the corrective action.
- Cause analysis is honest. Was it scope ambiguity? Pod composition mismatch? Customer-side dependency? Underestimation? Different causes, different fixes.
- Corrective action is concrete. "We'll work harder" isn't an answer. "We'll add a senior backend specialist for the next two sprints to clear the architectural debt that caused the underestimation" is.
- Platform-funded remediation if the cause is internal. If the miss was on the platform side (pod composition, talent quality, governance failure), the platform absorbs the remediation cost — the customer doesn't pay for the fix.
A good DM owns missed milestones. A weak DM lets them drift, blames the engineers, or escalates upward without taking ownership.
Frequently asked questions
What's the typical DM-to-engineer ratio?
One DM per pod, where pod size is 4–8 specialists. Below 4 specialists, the DM may split across two pods. Above 8, the structure usually shifts to a tech lead handling some operational load alongside the DM.
Can the DM be remote from the pod?
Yes — VDCs are remote-by-default. What matters is the DM has structured communication channels and is responsive within agreed SLAs. Geographic colocation isn't part of the role.
What experience should a DM have?
Typically 8–15 years of delivery experience, often coming from senior engineering, project management, or scrum-master backgrounds. The platform's hiring bar for DMs is higher than for individual specialists because the role's leverage is higher.
What if we don't like our DM?
The DM is a named role in the contract. If there's a fit issue, request replacement — the platform handles it within 30 days, with knowledge transfer to the incoming DM. Replacement is rare but available.
Where to start
If you're inside an engagement and the DM isn't operating like the role above describes, that's the conversation to have. Start with the platform's engagement architect, not your engineering VP — the scope is operational and the right escalation path is platform-side.
To talk through DM expectations before signing or in-flight, schedule a 30-minute call. For the broader pod role context, see roles inside a VDC. For the failure modes when DMs aren't operating right, see anti-patterns.