VP Engineering Playbook
Sprint conformance, team-level drift, process health, and knowing which signals need your attention.
Pre-sprint: the governance readiness check
Before committing to sprint scope, check two signals:
Intent-First Rate — last sprint
Navigate to /changecontrols/dashboard — what percentage of structural PRs had CHI approval before the first commit? If IFR < 60%, there are likely mid-sprint architectural surprises baked into the current planning. Factor in buffer.
Mean Time to Close Decision
Average time to resolve a blocked architectural decision. If MTTCD > 7 days, a blocked PR this sprint will sit for a week before resolution. Plan around that.
If any in-flight CHIs are pending architect approval for entities your sprint will touch: follow up before the sprint starts, not during.
Mid-sprint: the team conformance view
During the sprint, DCS tells you which teams are generating the most design violations.
- Navigate to
/changecontrols/designaudits— filter by FAIL status, current sprint date range. - Identify which contributors are generating the most BLOCKED results.
- Ask: is this concentrated in one team (targeted enablement needed) or spread across many teams (Lens calibration review needed with the architect)?
Post-sprint: the conformance retrospective
At the end of each sprint, 15 minutes with the architecture lead:
DCS trend
Up, down, or stable from last sprint?
PDT per pillar
Any pillar declining for 2+ consecutive sprints? That is the domain needing attention next sprint.
IFR
Is intent-first improving? If not, what is blocking teams from raising CHIs before coding?
PDRP
If any pillar is above 30%, is this one team or systemic? Different remediation paths.
Quarterly: process health audit
Four times a year, spend an hour on the process metrics:
IFR trend over the quarter
Is the team getting better at intent-first development?
MTTCD trend
Is the CHI approval process speeding up or slowing down as volume grows?
GD trend
Is Governance Depth growing? Flat GD means architects are not encoding new architectural knowledge into Lenses.
ADRIFT
If significant, it is an orchestration tooling problem, not a team problem. The fix is rkito MCP integration.
Responding to a DCS decline
When DCS drops by more than 5 points sprint-over-sprint:
Navigate to /changecontrols/designaudits, filter by FAIL, identify the top 3 failing Lenses by frequency.
For each failing Lens — is this a real architectural violation (team awareness issue) or a Lens misfiring on legitimate code (calibration issue)?
Real violation: schedule a targeted session with the affected team. Show them the specific failing Lens, what passing looks like, and why the boundary exists.
Calibration issue: work with the pillar owner to update the Lens prompt via CHI. Do not leave a misfiring Lens active — it erodes team trust in the CDA system.
Your role in Steering
As VP Engineering, your Steering responsibilities sit at the domain level — ensuring Pillars are healthy, translating engineering standards into enforceable artefacts, and keeping teams informed when governance changes.