Governance is the operational layer that turns a pod of vetted engineers into a delivering team. In a Virtual Delivery Center, governance is platform-default — sprint cadence, code-review SLAs, milestone definition, escalation paths, reporting rhythm — not bespoke per engagement. This is what makes "fully managed" actually fully managed.
This piece walks through the four governance layers that operate in a healthy VDC engagement, what each layer does, who owns it, and how the layers interlock so the engagement runs without your engineering management owning the operational load.
Layer 1: Sprint cadence
The base operating rhythm. A typical VDC pod runs on 2-week sprints, with the standard ceremonies:
- Daily standup — async by default (posted in Slack/Teams), live only when the pod requests it. Reads in 5 minutes; identifies blockers and dependencies.
- Sprint planning — start of each sprint, 60–90 minutes. Pod commits to scope based on milestone schedule.
- Mid-sprint check-in — informal, async or 15-minute call. Reality-checks against plan.
- Sprint demo — end of each sprint, 30–45 minutes. What shipped, what's left, what changed.
- Retrospective — end of each sprint, 30 minutes. What worked, what didn't, what to adjust.
The pod's delivery manager runs all five. Customer engineering leadership attends sprint planning and the demo; daily standups are pod-internal; retros are pod-internal with customer optional.
The point of the cadence: predictable rhythm. The same ceremonies on the same days produce muscle memory that compounds over the engagement.
Layer 2: Code-review SLAs
Quality gates that operate inside the pod, not at the customer's review boundary. The pod's tech lead is the final reviewer for non-trivial PRs. Specialist engineers review each other's work for the rest. The customer sees merged code, not in-flight review threads.
Standard SLAs:
- First reviewer feedback within 4 working hours.
- Final approval within 1 working day.
- Escalation to the tech lead if a PR has bounced 2+ times without resolution.
The customer's senior engineers may opt into specific reviews — for architectural changes affecting downstream systems, security-sensitive PRs, or new conventions being introduced. They don't review every PR; that would defeat the model.
Layer 3: Milestone definition and sign-off
The contractual unit of work and the contractual unit of acceptance.
Definition
Milestones are scoped 2–4 weeks of work. Each one has:
- A title and number.
- Deliverables (concrete, testable).
- Acceptance criteria (specific conditions).
- Dependencies (what the customer side needs to provide).
- Estimated duration.
The pod's delivery manager facilitates milestone definition. The pod's tech lead drives technical scope. The customer's product owner approves and confirms acceptance criteria are testable. Output: a milestone document that's specific enough to ship against.
Sign-off
Once the milestone deliverables are produced, the sign-off flow:
- Pod ships the demo at end-of-milestone.
- Customer's product owner reviews against acceptance criteria.
- Sign-off (or "needs work") within 2 business days.
- If needs-work, the pod addresses; cycle repeats.
- Sign-off triggers payment per pricing model.
Healthy engagements sign off in the same sprint. Unhealthy ones drift to multi-sprint sign-off cycles — that's a customer-side bottleneck, see the anti-patterns post.
Layer 4: Escalation paths
Every engagement has friction. The escalation paths determine whether friction resolves quickly or compounds.
Three levels
- Level 1: Pod-level resolution. The pod's delivery manager handles the issue. Most disputes resolve here within 48 hours.
- Level 2: Platform-level resolution. The platform's engagement architect intervenes. Triggered when the DM can't resolve at L1, or when the issue spans multiple engagements/pods.
- Level 3: Contract-level resolution. Legal/exec on both sides. Reserved for genuine disputes — milestone failures, contractual disagreements, force-majeure scenarios.
What good looks like
- ~85% of issues resolve at L1.
- ~13% resolve at L2.
- ~2% reach L3.
- L1 SLA: 48 hours.
- L2 SLA: 5 business days.
- L3: contract-defined.
If your engagement has frequent L2/L3 escalations, the issue is usually at L1 — your DM isn't owning operational decisions, or the customer's leadership is escalating issues that should resolve in pod-level conversations.
Reporting rhythm
Predictable communication is governance's external face. Standard cadence:
- Daily: async standup post in shared Slack/Teams channel.
- Weekly: milestone-status update from the DM (Mondays). 1-page note covering progress, risks, looking-forward.
- Sprint-end: demo + sprint-review note.
- Monthly: engagement review. 60-minute structured session with customer engineering leadership covering velocity trends, governance health, risk register, and looking-forward 1–2 quarters.
- Quarterly: business review with the platform's engagement architect. Cost-of-delivery review, strategic alignment, multi-quarter roadmap.
The customer doesn't have to ask for any of these. They arrive on cadence. If they don't, governance has slipped.
Audit trail and documentation
Underneath the operational governance is the documentary trail. The platform logs:
- Every commit with author, reviewer, milestone association.
- Every milestone sign-off with actor, timestamp, decision.
- Every escalation with level, owner, resolution time.
- Every pod-composition change with reason, effective date.
- Every scope change with originator, decision-maker, effective sprint.
This is the chain of custody auditors look for. It's also what lets engagement reviews be data-driven instead of impressionistic. For regulated sectors, see how a VDC handles compliance and audit.
How governance shifts with engagement maturity
The governance layer doesn't stay static. Three phases:
- Days 1–60: Heavy customer involvement. Sprint planning is collaborative. Milestone acceptance is granular. Escalations occasionally need customer engineering leadership.
- Days 60–180: Customer steps back. Pod operates with platform-default governance. Customer engineering manager is consulted, not running operations. Escalations rarely reach customer side.
- Days 180+: Steady state. Customer involvement is at the strategic layer (quarterly reviews, scope decisions). Operational governance is fully platform-owned.
If at day 90 your engineering manager is still spending 8+ hours per week on operational governance, the model hasn't transitioned and that's the conversation to have.
Frequently asked questions
What if we want shorter sprints (1 week) or longer (3 weeks)?
Both are doable. 1-week sprints work for fast-iterating product work; 3-week sprints work for deeper architectural cycles. The platform adapts during onboarding. 2-week is the default because it balances feedback speed against ceremony overhead.
How does the platform enforce code-review SLAs?
The pod's delivery manager monitors PR-stale time. Anything stale beyond SLA gets flagged and the DM intervenes — either reassigning the reviewer or surfacing the blocker. The metric is tracked at the pod level.
What if our scope keeps shifting?
Milestones recompose. Scope changes don't trigger contract amendments — the milestone schedule adjusts, the pod recomposes if needed, work continues. This is part of what makes the model elastic vs traditional outsourcing.
How are decisions made when the customer and pod disagree?
Three patterns: scope decisions are customer's call (your product, your roadmap); architectural decisions inside the pod's scope are the pod tech lead's call; operational decisions about how the pod runs are the DM's call. Disputes follow the L1/L2/L3 escalation path.
Where to start
If you're inside an engagement and the governance feels heavy or thin, run a quick assessment against the four layers above. Most engagements that feel "off" have one specific layer that's operating wrong — fixing that one layer typically resolves the broader feeling.
For a structured governance review, schedule a 30-minute call. For role-level context on who owns what, see how a DM keeps a VDC on track and what fully managed actually means.