How do we pick the initial capacity band for modernization?

Start at 15–20% per domain. Use your last quarter’s incident volume and SLO misses to bias up or down. If MTTR > 2h or you’re burning >30% of your error budget monthly, move to 25% until stability returns. Review monthly in the investment council.

Won’t product hate “losing” capacity to tech debt?

They’ll hate outages and missed dates more. Frame modernization as risk-reduction with measurable outcomes (latency, availability, cost). Keep a single backlog and require every modernization epic to attach to a product KPI and SLO. Show a Friday scorecard. Transparency buys trust.

What if Security or Finance won’t work in Git?

Bridge it. Mirror RFCs into their systems (e.g., Confluence export) but make the PR the source of truth. Add a `CODEOWNERS` rule so approvals are required. If approvals block for >48 hours, escalate at weekly triage, not by DM.

We tried ADRs before and they gathered dust. What’s different here?

Two things: expiry dates and kill criteria. Every ADR expires unless renewed with evidence; every experiment has a stop condition. And ADRs live next to code with CI checks that fail if a service has no current ADR for critical areas (e.g., data access).

Culture · Oct 9, 2025 · 9 minute read

The Cadence That Keeps Modernization From Hijacking Your Roadmap

How to build a decision rhythm that funds modernization without blowing up delivery schedules, trust, or SLOs.

Alex Ramirez

Partner, GitPlumbers

20 years in the trenches from bare-metal colo to multi-cloud, led SRE and platform teams at a Fortune 100 retailer and a couple of unicorns. I’ve broken prod so you don’t have to.

Modernization only works when it ships on the same train as features. Change the calendar, not just the code.

Back to all posts

The Cadence That Keeps Modernization From Hijacking Your Roadmap

Key takeaways

Implementation checklist