What if my organization requires a CAB for every production change?

Keep the CAB, change the inputs. Move approvals to evidence-based: link `Argo Rollouts` canary results, `Prometheus` SLO checks, and rollback plans. Pre-approve low-risk classes of change (config, flags, non-functional) and push the rest to asynchronous review with a 48-hour SLA. We’ve helped clients get auditors to accept this with ADRs and ticket attachments.

How do I keep product from feeling held hostage by platform work?

Expose the architectural runway in `Jira`, link enablers to features, and commit dates in the weekly handshake. Tie modernization work to product OKRs (latency, conversion). Use flags so product can ship UI while platform finishes plumbing. Publish a weekly summary that shows what moved a product metric, not just infra vanity.

What tools do I need to start?

Minimum viable stack: `docs/adr` folder, `Slack`/`Teams` channel for decisions, `Jira` board with enablers, and whatever you use for Git. Nice-to-haves: `ArgoCD`, `Argo Rollouts`, `Prometheus`/`Grafana`, `LaunchDarkly`, and `Backstage` for service catalogs. Don’t let tool shopping delay the cadence.

How do I measure if the cadence is working?

Within 4–6 weeks you should see: deployment frequency up, lead time down, change failure rate down, and MTTR down. ADR decision latency under 3 days. Handshake hit rate over 80%. At least one decommissioned asset per month and growing traffic on the new path. If not, inspect WIP, decision SLAs, and whether leaders are enforcing error budget policies.

Culture · Oct 2, 2025 · 9 minute read

The 30‑Minute Weekly Ritual That Kept Our EKS Migration From Blowing the Quarter

Modernization doesn’t have to kneecap your roadmap. Put product and platform on a shared decision cadence and watch velocity and reliability go up—together.

Alex Mercer

Partner, GitPlumbers

20 years shipping and rescuing software at scale. Ex-Netflix platform, ex-Stripe SRE. Led migrations from monoliths to `EKS` and from CABs to canaries without blowing quarters—or audits.

Rituals don’t ship code—decisions do. Put them on a cadence and everything else gets easier.

Back to all posts

The problem you’ve lived through

You’ve got a quarter’s worth of roadmap tied to new revenue, and a modernization push that was supposed to “just move us to EKS.” Two sprints in, the platform team is wrestling Istio mTLS, product can’t ship a simple onboarding flow because Kafka ACLs aren’t ready, and Security shows up with a CISA KEV vuln that nukes the release calendar. I’ve seen this movie: modernization becomes an infinite side quest, product quietly forks the monolith to hit dates, and now you’re running two broken worlds.

The fix isn’t another framework. It’s a decision cadence that keeps modernization and product in lockstep.

Below is the cadence I’ve implemented at a fintech, a healthtech, and a B2B SaaS—each with compliance, legacy anchors, and too many stakeholders. It’s boring in the right places and ruthless where it matters.

Related Resources

Key takeaways

Create a three-tier cadence: daily ADRs, weekly product–platform handshake, monthly Architecture Business Review.
Make decisions visible with `docs/adr` and a public RAG heatmap; measure decision latency and closure rates.
Tie modernization epics to product OKRs and error budgets; kill stealth rewrites and timebox experiments.
Use progressive delivery (`LaunchDarkly`, `Argo Rollouts`) so change safety replaces CAB theater.
Hold leaders to SLAs: decisions within 48 hours, no “maybe later” without a date and owner.
Instrument outcomes: DORA metrics, SLO burn, unit cost, migration burndown, and backlog flow efficiency.

Implementation checklist

Stand up a `docs/adr` folder and pick `adr-tools` or a simple template.
Schedule a 30-minute weekly product–platform handshake; publish a RAG heatmap.
Define decision classes (two-way vs one-way) and set a 48-hour SLA for approvals.
Create an architectural runway board with enabling tasks linked to features in `Jira`.
Wire progressive delivery: `LaunchDarkly` flags + `Argo Rollouts` + `Prometheus` checks.
Start measuring: DORA metrics, SLO burn, cost per transaction, ADR decision latency.

Questions we hear from teams

What if my organization requires a CAB for every production change?: Keep the CAB, change the inputs. Move approvals to evidence-based: link `Argo Rollouts` canary results, `Prometheus` SLO checks, and rollback plans. Pre-approve low-risk classes of change (config, flags, non-functional) and push the rest to asynchronous review with a 48-hour SLA. We’ve helped clients get auditors to accept this with ADRs and ticket attachments.
How do I keep product from feeling held hostage by platform work?: Expose the architectural runway in `Jira`, link enablers to features, and commit dates in the weekly handshake. Tie modernization work to product OKRs (latency, conversion). Use flags so product can ship UI while platform finishes plumbing. Publish a weekly summary that shows what moved a product metric, not just infra vanity.
What tools do I need to start?: Minimum viable stack: `docs/adr` folder, `Slack`/`Teams` channel for decisions, `Jira` board with enablers, and whatever you use for Git. Nice-to-haves: `ArgoCD`, `Argo Rollouts`, `Prometheus`/`Grafana`, `LaunchDarkly`, and `Backstage` for service catalogs. Don’t let tool shopping delay the cadence.
How do I measure if the cadence is working?: Within 4–6 weeks you should see: deployment frequency up, lead time down, change failure rate down, and MTTR down. ADR decision latency under 3 days. Handshake hit rate over 80%. At least one decommissioned asset per month and growing traffic on the new path. If not, inspect WIP, decision SLAs, and whether leaders are enforcing error budget policies.

Ready to modernize your codebase?

Let GitPlumbers help you transform AI-generated chaos into clean, scalable applications.

Talk to GitPlumbers about setting up your decision cadence Download the decision cadence checklist

Related resources

The Mentorship Program That Stopped Our 2AM SEVsIf your ‘bus factor’ is one, you don’t have a system—you have a person. Here’s how to build a mentorship program that reliably transfers critical system knowledge, fits enterprise constraints, and moves the numbers that matter: MTTR, onboarding time, and change failure rate.