Mean Time to
Change Decision
How long blocked architectural decisions sit unresolved — the operational velocity of governance.
This page describes the intended design. It requires timestamping when a Decision becomes blocked and when it resolves, which isn't tracked yet. It doesn't appear on your dashboard yet, and no org currently has a live value for it.
resolution timestamp
− blocked timestamp
)
across resolved cases, trailing 30 days
What it signals
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.
Who this metric is for
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 this metric gets misused
MTTCD spikes near release dates are timing artifacts, not structural signals. Architects are appropriately focused on shipping. Normalize MTTCD over 90-day windows before drawing conclusions.
Do not use single-sprint MTTCD spikes to pressure architects to approve faster — the goal is faster resolution of the underlying architectural question, not faster rubber-stamping.
Also: elevated MTTCD is not always an architect bottleneck. It may mean the CHI process requires changes that take time to implement correctly. Before blaming the review process, check whether the underlying structural change being reviewed is genuinely complex — complex changes should take longer to resolve.
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/changeintentions and 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.
High MTTCD is the most common structural cause of low IFR — when approval takes 9 days, teams stop waiting and start coding first.
A rising MTTCD feeds a rising UDR. When decisions take too long, teams route around the governance process entirely — producing ungoverned drift.
ABR tells you how many PRs are being blocked. MTTCD tells you how long they stay blocked. Both together reveal whether blocks are clearing or accumulating.
How long are your blocked decisions sitting?
rkito calculates MTTCD automatically from CDA and CHI event timestamps. Connect your repo and see your governance velocity in minutes.