Formula
MTTCD = average(
resolution timestamp
− blocked timestamp
)
across resolved cases, trailing 30 daysThresholds
On pace
Governance keeping upSlowing
Review requiredBlocked
Governance incidentReading it
MTTCD is the operational velocity metric of the architectural governance process. When a PR is blocked due to architectural drift, or when a Change Intention enters the review queue, the clock starts. MTTCD is how long that clock runs before resolution. Long MTTCD means blocked architectural decisions are accumulating — and the longer they sit, the more likely workarounds are introduced that make the eventual resolution harder.
MTTCD has a compounding risk property: blocked PRs that sit unresolved for more than 7 days create pressure to merge workarounds. Teams begin to route around the governance process not out of disrespect for it, but because the process is slower than their delivery cycle. A high MTTCD does not just slow delivery — it actively corrodes the governance culture by making the CHI process feel like an obstacle rather than an enabler.
For SREs and engineering leadership, MTTCD is the operational risk accumulation signal. Each day a blocked architectural decision sits unresolved is another day the underlying structural question remains open — and other code may be building assumptions on top of that unresolved question. MTTCD > 14 days is not just slow governance; it is architectural risk that is compounding daily.
How rkito produces it
Every blocked architectural event starts a timer. rkito watches for two trigger conditions: a CDA audit producing a BLOCKED status, or a Change Intention entering DRAFT state. From that moment, rkito tracks the branch until a resolution event occurs — CHI approval or a revised PR that passes the CDA. MTTCD is the average delta across all resolved cases in the trailing 30 days, available at /changecontrols/dashboard as a pipeline velocity metric.
- 01
BLOCKED event recorded
CDA audit produces BLOCKED status OR CHI enters DRAFT state
- 02
Clock starts
Timestamp of the BLOCKED event captured — MTTCD timer running
- 03
Resolution events monitored
CHI approved OR PR revised and CDA re-run producing PASS
- 04aRESOLVED
Resolution event detected
Delta = resolution timestamp − blocked timestamp
- 04bRED THRESHOLD
No resolution within 7 days
Case crosses red threshold — MTTCD contribution accumulates
- 05
MTTCD recalculated
Average delta across all resolved cases in trailing 30 days
- 06
Available at /changecontrols/dashboard
Surfaced as a pipeline velocity metric alongside UDR and IFR
Who reads it
MTTCD is the explanation for delivery delays that appear in sprint boards as "blocked." If MTTCD is 9 days, every blocked PR waits 9 days — and that shows up as unpredictable sprint completion. High MTTCD is not an architect failing to approve; it is a governance process running slower than delivery.
MTTCD > 14 days means identified architectural risks are accumulating. The longer a blocked design decision sits, the more operational risk is building on top of it — other code building assumptions on an unresolved structural question. MTTCD is the pre-incident signal SREs should be tracking.
MTTCD identifies where the governance process is breaking down — is the CHI review process too slow (architect bandwidth), too complex (unclear scope), or too infrequent (review cadence issue)? Each root cause has a different fix. MTTCD tells you there is a bottleneck; the CHI backlog tells you where.
How it misleads
What to do at each threshold
Step-by-step response playbook for each signal state.
The governance process is keeping pace with development velocity. Confirm the signal is real.
- Monitor that fast resolution is not indicating shallow review. A fast MTTCD alongside low CRPR (Comment Resolution Rate per Review) is a rubber-stamping risk signal — approvals are happening quickly because no one is reviewing carefully.
- Confirm at
/changecontrols/dashboard. If both MTTCD and CRPR are healthy, the governance process is genuinely operating at pace. Track trend over time — creep from 36h to 60h over a quarter is a trajectory signal.
Decisions are taking longer to resolve than your delivery cycle can absorb. Find the bottleneck before teams start routing around it.
- Navigate to
/changecontrols/changeintentionsand review pending CHIs by age. Identify which are stalling and why. Common causes: CHI scope unclear (author and reviewer have different mental models of what is being approved), reviewer bandwidth (one architect reviewing all CHIs), or process unfamiliarity (new team members not knowing how to respond to CHI review comments). - Check whether teams are starting to introduce workarounds for blocked PRs. A yellow MTTCD alongside rising UDR is the leading indicator that governance is being bypassed — not ignored, but outpaced.
Treat as a governance process incident. Blocked architectural decisions are compounding architectural risk.
- Quantify the backlog: how many CHIs have been pending > 7 days, what is their cumulative scope. This is the architectural risk inventory that is currently unresolved and accumulating.
- Distribute reviewer load across multiple architects. Consider a synchronous review session to clear the backlog. Do not assign all CHI review to a single person — that is not a process, it is a single point of failure.
- Investigate whether the CHI scoping process needs to be simplified to reduce reviewer effort per CHI. If reviewing a typical CHI requires an hour of architect time, MTTCD will always be high — the solution is scoping discipline, not more architects.