Capability Design
Designing enterprise capabilities that work under real-world constraints
Most large-scale change in financial institutions does not fail because of intent, funding, or technology.
It fails because capabilities are not designed as systems.
My work focuses on designing enterprise client and risk capabilities that remain coherent under pressure — across policy, governance, operations, data, and technology — and continue to perform as conditions, regulation, and scale change over time.
This is not programme delivery.
It is capability design.
What I mean by capability design
Capability design sits between strategy and execution.
It is concerned with how an institution actually functions, not how it is described. In practice, this means designing how:
policy intent becomes operational rules
risk ownership is embedded in day-to-day work
data is created, governed, and relied upon
roles, handoffs, and controls interact under load
change can occur without eroding integrity
It is distinct from:
process documentation
target operating models in isolation
technology-first transformation
compliance-driven redesign
The objective is not elegance.
The objective is durability.
Core Design Domains
The capability design work I do consistently spans five interdependent domains. Treating these separately is one of the most common causes of failure.
Operating Model Architecture
What exists, how it fits, and why
Enterprise client and risk capabilities need to be designed as modular, arrangement-anchored systems, not as collections of processes or platforms.
This includes:
clear decomposition of capabilities
explicit boundaries between services
shared client, entity, and network constructs
independence from vendor-specific models
The aim is an operating model that can absorb change without continual redesign.
Governance & Design Authority
How coherence is maintained over time
Complex capabilities degrade unless they are actively governed.
Effective governance is not about forums or escalation; it is about:
cross-functional design authority
disciplined alignment between policy, standards, and procedures
control over change impact, not just change volume
institutional ownership beyond delivery programmes
This is where many transformations quietly unravel.
Flow, Capacity & Performance
Why work fails under pressure
Most operational problems are framed as quality or productivity issues when they are, in fact, flow problems.
Designing for performance requires explicit attention to:
demand shaping and intake control
role clarity and case orchestration
capacity, buffers, and utilisation
backlog dynamics and stabilisation
Without this, even well-designed models collapse under load.
Quality, Assurance & Integrity
Knowing whether the capability is actually working
Quality cannot be managed through sampling alone.
Sustainable assurance requires:
population-level integrity
clarity on what “correct” means at any point in time
understanding how errors propagate through downstream activity
treating data quality as a risk, not an inconvenience
This is essential for trust — internally and with regulators.
Change, Stabilisation & Improvement
Recovering broken systems — and keeping them healthy
In stressed environments, optimisation is the wrong starting point.
Effective intervention depends on:
stabilising BAU flow before redesign
separating backlog remediation from live operations
sequencing interventions deliberately
creating the conditions for self-improvement
This is where operational science matters more than methodology.
Designing the System, Not the Parts
These five domains are mutually reinforcing.
Weakness in governance undermines architecture.
Poor flow erodes quality.
Uncontrolled change degrades everything.
Most failures occur because organisations optimise individual components rather than design the system as a whole.
Capability design is about ensuring system level coherence.