VP Engineering Playbook

Pre-sprint: the governance readiness check

Before committing to sprint scope, check two signals:

IFRIntent-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.

MTTCDMean 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.

01Navigate to /changecontrols/designaudits — filter by FAIL status, current sprint date range.
02Identify which contributors are generating the most BLOCKED results.
03Ask: is this concentrated in one team (targeted enablement needed) or spread across many teams (Lens calibration review needed with the architect)?

Important

Do NOT use DCS to pressure individual engineers — it is a system health signal, not a performance metric.

Post-sprint: the conformance retrospective

At the end of each sprint, 15 minutes with the architecture lead:

DCS

DCS trend

Up, down, or stable from last sprint?

PDT

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

IFR trend over the quarter

Is the team getting better at intent-first development?

MTTCD

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:

Step 1

Navigate to /changecontrols/designaudits, filter by FAIL, identify the top 3 failing Lenses by frequency.

Step 2

For each failing Lens — is this a real architectural violation (team awareness issue) or a Lens misfiring on legitimate code (calibration issue)?

Step 3

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.

Step 4

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.

/steerings/pillars

Review Pillar coverage across engineering domains. Each team or domain that generates PRs should have a Pillar with active Lenses. A Pillar with zero Lenses produces no CDA signal — those PRs go unreviewed. Use LPP to identify thin coverage.

/steerings/bestpractices

Document engineering best practices here — the standards your teams are expected to follow. Best practices that are not referenced by Lenses are advisory. Best practices that have a corresponding Lens are enforced on every PR.

/steerings/patterns

Approved architectural patterns for teams to reference. Patterns define how things should be built (approved service communication pattern, approved data access pattern, etc.). A Lens can enforce that only approved patterns are used.

/steerings/policies

Engineering-level Policies — the process and structural rules your teams must follow. Examples: “all new services must have a registered Architecture Ledger entry before development begins”. Policies that lack corresponding Lenses are aspirational, not enforced.

/steerings/announcements

Use Announcements to communicate governance changes to teams — new Lenses activating, Pillar restructuring, DCS trends you want teams aware of. Announcements are visible to engineers in the rkito interface.

The VP Eng Steering signal: if Governance Depth is flat or declining, the Steering layer is not growing with the codebase. New domains, teams, or services are going ungoverned.