At a Glance
A run-vs-change-the-bank capacity model calculates change headroom by subtracting mandatory obligations, minimum run capacity, volatility reserve, and transition overhead from gross capacity for each constrained role. The output is a role-by-role allocation and a stop-or-sequence decision—not a universal budget ratio.
RTB/CTB capacity allocation worksheet
Build the model by constrained role or decision forum, not by total headcount. Recalculate it when incident load, regulatory obligations, or transition activity changes.
| Input | What to quantify | Executive test |
|---|---|---|
| Gross role capacity | Available capacity for a constrained role group in the planning period. | Is the denominator based on named people and realistic availability? |
| Mandatory obligations | Regulatory commitments, remediation, resilience work, and fixed control activity. | Which demand cannot be deferred without breaching an obligation or tolerance? |
| Minimum run capacity | Capacity needed to sustain service, control performance, and planned maintenance. | What service or control indicator fails if this allocation is reduced? |
| Volatility reserve | Capacity protected for incidents, defects, and unplanned evidence requests. | Is the reserve based on observed volatility rather than optimism? |
| Transition overhead | Parallel run, reconciliation, training, cutover, and decommissioning effort created by change. | Has the portfolio funded the temporary load that change creates? |
| CTB headroom | Residual capacity available for transformation after protected demand. | Which initiatives fit, and what must stop or move? |
CTB headroom = gross role capacity − mandatory obligations − minimum run capacity − volatility reserve − transition overhead.
Illustrative only: a 100-FTE constrained role group with 20 FTE of obligations, 45 FTE minimum run capacity, a 10-FTE volatility reserve, and 8 FTE of transition overhead has 17 FTE of CTB headroom. A plan assuming 35 FTE of change capacity is short by 18 FTE and needs stop, sequence, or simplification decisions.
Decision rules before approving the portfolio
- Model the bottleneck roles and decision forums separately; aggregate averages hide the constraint.
- Protect explicit run, control, and volatility floors before allocating transformation demand.
- Count dual-running and decommissioning work as transition load, not free capacity.
- Require named stop or sequencing decisions when demand exceeds calculated headroom.
Why RtB versus CtB is back on the executive agenda
In banking, transformation ambition is increasingly constrained by a simple reality: the same people, platforms, and governance forums must deliver both stable operations and continuous change. The classic Run the Bank (RtB) versus Change the Bank (CtB) distinction remains useful, but only when it is used as a capacity model rather than as an accounting label.
Executives validating ambition level are effectively asking an ambition reality-check question: how much change can the bank absorb without degrading operational resilience, control performance, and customer service, and what must be stopped or simplified to create room for strategic work.
RtB and CtB in operational terms
For a full breakdown of what Run the Bank and Change the Bank mean and why the distinction matters, see Run the Bank vs Change the Bank: Executive Trade-offs. In short: RtB is the non-discretionary work that keeps services safe, compliant, and available; CtB is the work that changes how the bank competes. If RtB is under-resourced, the outcome is higher incident volume, control breaks, escalating remediation load, and slower change that consumes even more capacity.
In practice, the line blurs because modern outcomes are always both running and changing. Payments, digital channels, fraud, and cyber defenses must evolve continuously. Treating them as episodic CtB projects often leads to an accumulation of temporary fixes that permanently raise RtB costs.
The ambition reality check: cost, complexity, and capacity constraints
RtB versus CtB becomes decision-useful when it is translated into the constraints that govern throughput. Three constraints repeatedly determine whether strategy is realistic.
Cost: the RtB “tax” and the CtB illusion of available funding
Banks commonly describe a majority share of spend as RtB and a smaller share as CtB. The problem is not the split itself, but the hidden consumption that sits outside program baselines: audit and exam work, remediation obligations, third-party risk management, unplanned incidents, and policy and control updates. These demands consume the same constrained roles that CtB relies on, reducing the “usable” portion of both budgets and time.
Complexity: when the portfolio creates more work than it delivers
Complexity is the primary multiplier of cost and time. Parallel architectures, duplicated tools, bespoke integrations, and inconsistent data definitions increase testing effort, release risk, and evidence production. A transformation portfolio becomes unrealistic when each incremental change increases the burden to run, govern, and assure the environment.
Capacity: the bottlenecks are roles and decisions, not headcount
Capacity constraints typically sit with product ownership, platform and data engineering, cyber and resilience engineering, control owners, testers, operational SMEs, and the decision forums that unblock work. When these bottlenecks are spread across too many initiatives, throughput falls, quality degrades, and the bank compensates with workarounds that raise RtB burden.
A practical RtB versus CtB capacity model executives can govern
A workable capacity model helps leaders convert debate into decisions. The goal is not to perfect categorization but to quantify trade-offs and protect execution quality.
1 Classify work by outcome and obligation
Classify demand into three buckets: mandatory obligations (regulatory, remediation, and resilience work), run sustainability (platform upkeep, controls, service management), and strategic outcomes (growth, customer experience, structural simplification). This makes explicit when CtB plans are being built on capacity that is already committed.
2 Measure “usable capacity” for constrained roles
For constrained roles, track available hours after obligations and operational volatility are deducted. Treat sustained incident volume, recurring audit requests, and repeated rework as signals that usable capacity is overstated. If the model assumes 100% availability, it is not a capacity model; it is a wish list.
3 Quantify the dual-running and transition load
Transformation creates a transition load that behaves like RtB: parallel run, additional monitoring, reconciliation, procedural updates, and training-to-proficiency time. Executives should require that this transition load is forecast, staffed, and funded explicitly, otherwise CtB will cannibalize RtB and increase operational risk.
4 Require stop decisions and decommissioning as capacity creation
Capacity is created when the bank stops work, retires systems, and removes complexity. If the plan only adds CtB initiatives without specifying what will be decommissioned or deprioritized, the portfolio is structurally unrealistic. Make decommissioning and standardization visible as first-class work with owners and dates.
5 Align governance to throughput, not reporting volume
Governance should accelerate decisions and reduce rework. Standard patterns for security, compliance, and evidence expectations reduce late-stage friction. Where governance multiplies forums and bespoke reporting, it becomes a capacity drain that cannot be offset by delivery methodology changes alone.
Integrating RtB and CtB through outcome-led funding
Many banks are moving toward outcome-led funding and more continuous delivery models to reduce the artificial boundary between run and change. The executive ambition check is whether the model actually reduces complexity and decision latency, or whether it simply renames work while leaving underlying constraints untouched.
A practical posture is to fund outcomes (for example, a customer journey, a payments capability, or a fraud domain) with explicit allocation for both reliability and evolution. This creates a clearer accountability loop: teams own service stability, control performance, and delivery throughput, while leaders can make trade-offs transparently rather than through periodic budget reshuffles.
Using maturity evidence to validate ambition in the RtB versus CtB model
A disciplined ambition reality check benefits from evidence about the bank’s actual digital capability, not just its declared priorities. A digital maturity assessment supports this by mapping RtB and CtB constraints to measurable readiness across platform modernization, delivery discipline, data and analytics foundations, operating model effectiveness, and integrated risk and control execution.
Reviewed by
The Founder & CEO of DUNNIXER and a former IBM Executive Architect with 26+ years in IT strategy and solution architecture. He has led architecture teams across the Middle East & Africa and globally, and also served as a Strategy Director (contract) at EY-Parthenon. Ahmed is an inventor with multiple US patents and an IBM-published author, and he works with CIOs, CDOs, CTOs, and Heads of Digital to replace conflicting transformation narratives with an evidence-based digital maturity baseline, peer benchmark, and prioritized 12–18 month roadmap—delivered consulting-led and platform-powered for repeatability and speed to decision, including an executive/board-ready readout. He writes about digital maturity, benchmarking, application portfolio rationalization, and how leaders prioritize digital and AI investments.
References
- https://www.linkedin.com/pulse/aligning-value-mix-integrating-run-bank-change-concepts-emile-vos-mmepf
- https://www.financialprofessionals.org/training-resources/resources/articles/Details/all-aboard-gaining-alignment-through-the-strategic-investing-process
- https://prashantcss.medium.com/run-the-bank-vs-change-the-bank-95a3122d621c
- https://www.linkedin.com/pulse/outcome-first-banking-why-run-bank-change-fiction-dan-molloy-4e2ye
- https://atuldeeke.medium.com/ctb-vs-rtb-the-subtle-art-of-navigating-the-crossroads-of-innovation-stability-2a3320725883
- https://deloitte.wsj.com/cio/run-the-bank-better-withagile-01563152525
- https://www.oracle.com/a/ocom/docs/fs-intelligent-bank-global-solution-brochure.pdf
- https://www.linkedin.com/posts/gaurav-kumar-a06388168_the-run-the-bank-team-plays-a-vital-role-activity-7093554558555029504-V2ay
- https://www.materialplus.io/sg/perspectives/the-dual-imperative-in-banking-a-balancing-act-between-operational-efficiency-and-innovation
- https://visbanking.com/bank-strategic-planning
- https://execution-excellence-manifesto.org/en/run-the-business-vs-change-the-business-en/