Improving Developer Velocity Inside Bank Security Constraints
Where the Weeks Actually Go Between Idea and Production
A senior engineer at a large bank once described their first month as follows: two weeks waiting for access to the repository, three days waiting for a development environment, a week waiting for test data, and two days of actual work. Nobody in that chain was obstructive. Every step had a reason, a form, and an owner. The aggregate outcome was a highly paid specialist reading documentation for a month.
That is what constrains developer velocity regulated banking environments, and it is almost never the security control itself. It is the administration of the control, the queue in front of it, and the fact that nobody measures the wait.
Where does the time actually go?
Into queues, not into keyboards.
| Stage | Typical elapsed time | Effort actually consumed |
|---|---|---|
| Access and entitlement provisioning | Days to weeks | Minutes of approval clicks |
| Environment availability | Days to weeks | Minutes of provisioning, if automated |
| Test data suitable for the work | Days | Hours, if the tooling exists |
| Code review turnaround | Hours to days | Under an hour of reading |
| Security scan finding remediation | Days to weeks | Variable, often minutes per finding |
| Dependency on another team's change | Weeks | Small, but serialised |
| Change approval | Days | Minutes in a meeting |
| Release window wait | Days to weeks | None |
The right-hand column is the point. In almost every row the effort is small and the elapsed time is large, which means the improvement available is not about working harder or hiring more engineers. It is about removing waits.
Why is waiting rather than typing the dominant cost?
Because queues accumulate calendar time while consuming almost no effort, so effort-based planning cannot see them.
A project plan built from estimates of work will show six weeks of engineering and deliver in five months, and the discrepancy sits in gaps between activities that nobody estimated because nobody was working during them. Measuring elapsed time from first commit to production exposes it. So does the simpler exercise of taking one real change and drawing every wait on a timeline, which usually produces a diagram that makes the case without further argument.
Do you know the elapsed time from first commit to production for a typical change?
What should be measured?
Five delivery metrics, per team, reported over time.
The DORA software delivery metrics give the accepted set: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. The research consistently finds that speed and stability are correlated rather than traded off, which is the most useful thing a CTO can put in front of a risk committee, because it undercuts the assumption that going slower is inherently safer.
| Metric | What it exposes | Common misuse |
|---|---|---|
| Change lead time | Queue time across the whole path | Measured from ticket creation, hiding engineering wait |
| Deployment frequency | Batch size and release friction | Counted for non-production deployments |
| Failed deployment recovery time | Rollback and detection capability | Measured only for major incidents |
| Change fail rate | Whether speed is costing quality | Defined loosely so it stays low |
| Deployment rework rate | Hidden instability | Not tracked at all |
Why does measuring per team beat measuring per organisation?
Because an organisational average conceals the distribution that actually matters.
One platform team deploying forty times a week and fifteen product teams deploying monthly produce a respectable-looking average and tell you nothing. Per-team figures show where the friction concentrates, which is usually in teams working on the oldest systems or those with the most third-party dependencies. That distribution is the intervention list. It also prevents the metric becoming a target, since the useful question is why a specific team's lead time is nine weeks rather than whether the average improved.
How do golden paths help?
By making the controlled route the default and the fastest one available.
A golden path is a supported way to build and ship a particular kind of service, with the controls already embedded: the pipeline template that enforces review and produces evidence, the base image that is already hardened and patched, the logging and telemetry wired in, the secret management integrated, and the deployment target already configured. An engineer who follows it gets working infrastructure in hours and compliance for free. An engineer who needs something different can deviate, with review, which is where the architecture conversation belongs rather than at the start of every project. Containerised platforms make this materially easier, which is part of the argument in containerisation and Kubernetes in regulated environments.
Why should the compliant path be the fastest path?
Because engineers optimise for finishing their work, and policy does not change that.
If the approved route to a database takes three weeks and a workaround takes a day, the workaround will be used, discovered later, and remediated at cost. The design principle follows: rather than adding enforcement to make the slow path mandatory, make the controlled path quick enough that nobody looks for an alternative. That reframes platform investment as a control investment, which is also how it should be funded. The same logic drives test data provisioning, since a masked dataset that takes a week guarantees production copies, as covered in test data management without exposing production PII.
What can be removed without removing control?
Duplicated approvals, manual evidence gathering, blanket gates, and reviews that check nothing a machine cannot.
Four categories are usually safe to eliminate. First, the same fact approved twice by different bodies, which happens when governance forums accumulate without anyone retiring one. Second, manual evidence collection, which should be an automatic pipeline output rather than a person taking screenshots, as covered in audit-ready CI/CD evidence trails. Third, uniform gates applied to changes of wildly different risk, which is solved by tiering rather than by removal. Fourth, checklist reviews where the reviewer is confirming things a static check already confirms, which wastes a scarce reviewer on work a machine does better and leaves less attention for the design questions only a human can assess.
None of that is deregulation. The enforcement mechanics of approval and duty separation are a separate design problem with their own answer, set out in automating change approval and segregation of duties. The point here is that a control operating in seconds and a control operating over three days provide the same assurance at very different cost.
How do you fix access and onboarding?
By treating time to first commit as a tracked service level.
Measure the elapsed time from an engineer's start date to their first merged change and publish it. Then attack the components: entitlement bundles defined per role so onboarding is one request rather than fourteen, pre-approved standard access for a defined role granted automatically, just-in-time elevation for anything privileged, and self-service for repository and tooling access within the bundle. Reviewing entitlements remains necessary and gets easier when they are bundled, because a role definition can be reviewed once rather than a thousand individual grants. The zero trust posture this implies is described in zero trust architecture.
How do you fix environments and data?
By making both self-service, disposable, and quick.
Waiting for an environment is the single largest queue in many bank estates, particularly where testing anything requires cooperation from twenty downstream systems, which is the problem addressed in environment provisioning for banks with many downstream systems. Data is the paired constraint: an environment without usable data is not an environment. Both need to be requestable in minutes, versioned, and destroyed automatically, and both are platform investments rather than project ones, which means they need funding that does not depend on a change programme sponsoring them.
How do you handle security scanning without blocking?
Break the build on newly introduced high-severity issues only, and manage the rest as a backlog with deadlines.
The failure mode is familiar: a scanner is introduced, produces four thousand findings across the estate, the pipeline is configured to fail on any finding, delivery stops, and within a month the gate is set to advisory and everyone ignores the output. The workable configuration is narrower and stricter: fail on new high-severity findings introduced by this change, since that is actionable by the person who caused it; place everything else in a backlog with remediation deadlines by severity; and prioritise by exploitability and reachability rather than by raw severity count, because a critical finding in a code path that is never executed matters less than a medium one on an internet-facing endpoint.
| Finding category | Pipeline behaviour | Ownership |
|---|---|---|
| New high severity, introduced by this change | Fail the build | The change author |
| New medium or low, introduced by this change | Warn, ticket automatically | The owning team, deadline by severity |
| Pre-existing high severity | Do not fail the build | Backlog with a named deadline |
| Pre-existing medium or low | Do not fail the build | Periodic reduction target |
| Dependency vulnerability with no available fix | Documented exception with review date | Security, with compensating control |
Is a change freeze a control?
Rarely. It is usually a confidence problem expressed as a calendar.
Freezes exist because someone does not trust the release process, which is a reasonable position when the release process is untrustworthy. The cost is that change accumulates during the freeze and goes out in a large batch afterwards, which is precisely the highest-risk deployment shape. The path out is to earn the confidence with automated regression and reliable rollback, then narrow the freeze to genuinely sensitive windows such as period end, as discussed in change freeze and release management and supported by the coverage described in core banking regression automation.
What about the oldest systems?
Accept a two-speed reality and invest to shrink the slow side.
Some systems will not reach weekly deployment, and pretending otherwise sets up a programme to fail. The honest approach is to measure the slow estate separately, keep it safe rather than fast, and direct modernisation investment at whichever parts of it constrain the most valuable change. Cost pressure often provides the business case, as in mainframe cost reduction, while landing zone work determines how quickly new services can be stood up at all, as covered in sovereign cloud landing zones.
Supervisory expectations are compatible with all of this. The EBA's guidelines on ICT and security risk management, applicable from 20 May 2025 and amended to align with DORA's application from 17 January 2025, set ICT risk requirements for credit institutions, investment firms, and payment service providers. Nothing in that framing requires slow delivery; it requires managed delivery, and automation is the more reliable way to manage.
Is your change freeze protecting you, or batching up your riskiest deployment of the quarter?
Talk to Digiqt about release confidence and freeze reduction
What does velocity theatre look like?
Measuring output instead of flow, and celebrating movement instead of delivery.
The recognisable signs: story point velocity reported as an engineering metric, commit counts or lines of code on a dashboard, deployment frequency counted for non-production environments, a platform team measured by tickets closed rather than by lead time in the teams it serves, and any initiative that improves a number by redefining it. The worst version is removing a control and calling the result velocity, which converts a delivery problem into a risk problem and eventually into an incident. If a control is genuinely unnecessary, retire it deliberately with risk acceptance recorded; if it is necessary, automate it.
How should this be sequenced?
Measure, then attack the largest queue, then build the paved road, then keep measuring.
| Phase | Duration | Deliverable |
|---|---|---|
| Baseline measurement | 1 month | Five delivery metrics per team, plus a wait-time map for one real change |
| Access and onboarding | 2 months | Role-based entitlement bundles, time to first commit tracked |
| Environment self-service | 3 to 4 months | Requestable, disposable environments with data |
| Golden path for the commonest service type | 2 to 3 months | Template carrying controls, evidence, and telemetry |
| Scan triage model | 1 month | New-high-severity gating, backlog with deadlines |
| Change tiering | 1 to 2 months | Differentiated approval by risk, lead time reported per tier |
| Freeze reduction | 2 to 3 months | Narrowed windows justified by regression coverage |
| Ongoing | Continuous | Quarterly review of the largest remaining queue |
The final row is the operating model. There is always a largest queue, and the discipline is to find and remove it repeatedly rather than to run a one-off improvement programme.
Which metrics matter?
The five delivery metrics, time to first commit, environment and data provisioning lead time, and the proportion of work following the golden path.
Report the delivery metrics per team and trend them. Report time to first commit as the onboarding measure, since it captures the whole access chain in one number. Report provisioning lead time for environments and data, because those are the largest queues in most institutions. And report golden path adoption, since a paved road nobody uses indicates the road does not go where teams need to go. Detection capability belongs alongside these, given that fast delivery depends on knowing quickly when something is wrong, which is the subject of detecting production issues early.
Velocity in a bank is not achieved by asking engineers to move faster. It is achieved by removing the waits nobody was measuring, and by making the controlled path so much quicker than the alternative that compliance stops being a negotiation.
Frequently Asked Questions
Where does delivery time actually go in a bank?
Into waiting: for access, for an environment, for test data, for an approval, for a dependency team, and for a release window. Very little of it is spent writing code.
Why is waiting rather than typing the dominant cost?
Because handoffs and queues accumulate calendar time while consuming almost no effort, which makes them invisible in effort-based planning and dominant in elapsed time.
What should be measured?
Change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate, reported per team rather than aggregated.
Why should the compliant path be the fastest path?
Because engineers optimise for getting work done, so if the controlled route is slower than the workaround, the workaround becomes the real process regardless of policy.
What can be removed without removing control?
Manual evidence gathering, duplicated approvals of the same fact, blanket gates on low-risk change, and reviews that no longer inspect anything a machine cannot check.
How should security findings be handled without blocking delivery?
Break the build only on newly introduced high-severity issues, triage the rest into a backlog with severity-based deadlines, and prioritise by exploitability rather than raw count.
Is a change freeze a control?
Usually it is a symptom of low release confidence rather than a control, and it tends to increase risk by concentrating change into large batches after the freeze lifts.
What does velocity theatre look like?
Measuring story points, commits, or lines of code, celebrating deployment counts to non-production, and removing controls rather than automating them.
