Legacy Skills Shortage in Banking: Automation and Knowledge Capture
When the Only Person Who Understands It Retires in March
Every bank has one. A system that processes something essential, has run for decades, and is genuinely understood by two people, one of whom retires next year and the other of whom is a contractor. The situation is well known internally, discussed periodically, and rarely acted on, because there is no incident, no finding, and no deadline until suddenly there is.
The legacy skills shortage banking technology institutions face is not fundamentally a recruitment problem. It is a concentration of operational dependency on individuals, and it responds to the same treatment as any other concentrated dependency: measure it, reduce it deliberately, and stop assuming the current arrangement will persist.
Why is this a risk item rather than an HR problem?
Because the failure mode is an operational one and the mitigations are engineering ones.
Framing it as recruitment leads to a search for people with skills that are genuinely scarce, at prices that keep rising, for systems that are shrinking in number. Framing it as concentration risk leads somewhere more productive: which systems, which people, what happens on the day they are unavailable, and what would reduce that dependency regardless of whether anyone is hired. The evidence that this is a real and durable pattern is not new. The US GAO's 2019 review of federal legacy systems examined ten critical systems aged between eight and fifty-one years, specifically citing COBOL and a dwindling pool of people skilled in it, and found that only two of the ten agencies had modernisation plans containing milestones, work descriptions, and disposition strategies, while three had none at all.
Operational resilience frameworks also reach this territory, since the Basel Committee's principles for operational resilience, published 31 March 2021, take a principles-based approach covering technology failures alongside pandemics, cyber incidents, and natural disasters, and build on operational risk, governance, business continuity, and outsourcing foundations. A dependency on one person to recover a critical service is a resilience question by any reading, which is the mapping discipline described in operational resilience and impact tolerances.
Why does the exposure concentrate in so few people?
Because the systems stopped attracting new people long before they stopped being important.
Nobody joined the institution in the last fifteen years hoping to specialise in the batch scheduler. The people who understand it learned it when it was current, stayed, and accumulated knowledge that was never written down because they were always available to answer. Each departure removes a share of that and increases the load on those remaining, which accelerates their departure. The dynamic is self-reinforcing and it does not stabilise on its own, which is why it needs deliberate intervention rather than monitoring. The wider hiring picture is covered in the technology talent shortage playbook.
How many people could recover your most critical legacy system at three in the morning?
How do you quantify the exposure?
Per system, count who can change it, who can operate it under pressure, and how long a replacement takes.
| Dimension | What to record | Why it matters |
|---|---|---|
| Change capability | People who can safely modify it | Determines whether it can evolve at all |
| Operational capability | People who can diagnose and recover it live | Determines what happens during an incident |
| Depth of understanding | People who know why it behaves as it does | Determines whether changes are safe |
| Availability profile | Employment type, notice period, retirement horizon | Determines how much warning you get |
| Replacement time | Realistic months to competence for a new person | Determines the size of the gap |
| Consequence of failure | What stops if the system does | Determines the priority |
Publish the resulting table to executives without softening it. A system with one person able to change it, one able to recover it, and a twelve-month replacement time is a stated risk, and stating it plainly is what unlocks investment. The pattern usually correlates with accumulated technical debt, which is the subject of reducing technical debt in core systems, and with the wider workforce exposure described in workforce skill shortages.
What knowledge actually needs capturing?
Six kinds, of which only two are usually documented.
| Knowledge type | Typically documented? | How to capture it |
|---|---|---|
| What the system does | Partially | Behaviour extraction and characterisation tests |
| How to operate it normally | Usually | Runbooks, then automate the routine steps |
| How to recover it when it fails | Rarely, and often out of date | Rehearsed recovery with the runbook updated during the rehearsal |
| Why it behaves as it does | Almost never | Structured interview and decision records |
| Which oddities are deliberate | Almost never | Annotate the anomalies before the person leaves |
| Who to call outside the institution | Never | Named contacts at vendors, schemes, and counterparties |
The fourth and fifth rows are where the real value sits and where capture is hardest, because the knowledge is not written anywhere and its holder does not experience it as knowledge. It is simply how things are.
Why is intent the part that never gets written down?
Because the reason was obvious at the time and nobody records the obvious.
A rounding rule that appears wrong implements a regulatory requirement from 1998. A duplicated field exists because a merged entity's data could not be reconciled. A job that runs at an odd hour does so because a counterparty's file arrives then. Each decision made sense to the person who made it, none of it is in the code, and once the person leaves it is indistinguishable from a defect. The consequence is expensive: teams "fix" deliberate behaviour and discover the reason from an incident or a complaint. Capturing intent means asking specifically about the strange parts, and the question that works is not "how does this work" but "what would someone new get wrong about this".
How do you capture behaviour rather than descriptions?
By pinning current behaviour in executable form before anyone changes anything.
Characterisation tests capture what the system actually does rather than what it should do, which is exactly what is needed when the specification is lost. Feed controlled inputs, record outputs, and assert that they do not change. For batch systems the same approach works at file level: keep a set of representative inputs and their outputs, and compare byte for byte. The result is a safety net that lets a less experienced person make a change with confidence, which directly reduces the dependency on the expert. The mechanics are the same as those described in core banking regression automation, and the resulting harness is precisely what any subsequent migration needs, whether that is COBOL to Java conversion or incremental strangler fig extraction.
Why are tests better documentation than documents?
Because a test that becomes untrue fails, and a document that becomes untrue does not.
Documentation decays from the moment it is written, silently, and the reader cannot tell whether they are looking at current truth or a description of 2014. An executable check is verified on every run, so its accuracy is continuously proven rather than assumed. Documents remain necessary for intent, context, and the human explanations that no test can carry, but for behaviour the executable form is strictly better and it is the form most institutions invest in least.
What can automation genuinely replace?
Routine operational work, which is most of the volume and none of the difficulty.
| Toil category | Automation approach | Residual need for expertise |
|---|---|---|
| Scheduled manual interventions | Scripted and scheduled, with alerting | Low |
| Routine restarts and clean-ups | Automated with guardrails | Low |
| Standard recovery steps | Runbook automation triggered on defined conditions | Medium, for confirming the diagnosis |
| Health checks and reporting | Fully automated monitoring | Low |
| Access and environment requests | Self-service with entitlement checks | Low |
| Diagnosing an unfamiliar failure | Not automatable | High, and rising |
| Deciding whether to intervene at all | Not automatable | High |
Automation removes the work that consumes specialists' time without using their judgement, which is worth doing on its own terms and reduces how many specialist hours the institution needs. It does not reduce how much specialist judgement it needs, and confusing the two produces a comfortable-looking operating model that fails on its first unusual day. The delivery-side version of this argument is set out in developer velocity inside bank security constraints.
Why can automating the routine make the rare harder?
Because routine work is how people stay familiar with the system.
If every ordinary intervention is automated, nobody touches the system until something unusual happens, at which point the person responding has neither recent practice nor context. The mitigation is deliberate: rotate people through supervised exposure, run recovery rehearsals rather than reading recovery documents, and treat incident response practice as a scheduled activity rather than an outcome of bad luck. Institutions that automate heavily and then stop practising end up with fewer, less practised responders, which is a worse position than the one they started from.
Has anyone actually rehearsed recovering that system, or only read the runbook?
Talk to Digiqt about recovery rehearsal and knowledge capture
Should modernisation be the answer?
Sometimes, but not as a response to the skills problem alone.
Replacing a system because it is hard to staff is an expensive way to solve a staffing problem, and it typically takes longer than the retirement horizon that prompted it. Modernise where there is a business case in its own right, as covered in legacy core system modernisation, and in the meantime reduce the dependency through capture and automation, which delivers value in months rather than years. Targeted extraction is often the better middle path: remove the two or three functions that generate most of the change requests, leave the stable remainder alone, and shrink the surface that needs scarce expertise. Cost pressure sometimes provides the business case independently, as discussed in mainframe cost reduction, and restructuring overnight processing often removes a large share of the manual intervention burden, as covered in batch window elimination.
What are the sourcing options, honestly?
Five, each with a real limitation worth stating.
| Option | What it gives | The limitation |
|---|---|---|
| Retain the current holders | Continuity | Deferral, not resolution, and cost rises each cycle |
| Retrain existing engineers | Institutional context plus new skills | Slow, and only works if the work is interesting enough to keep them |
| Apprenticeship or graduate pipeline | Long-term supply at reasonable cost | Requires experienced people to teach, which is the scarce resource |
| Specialist contractors | Fast capability | Knowledge leaves with them unless capture is contractual |
| Managed service or vendor | Transfers the operational load | Transfers dependency rather than removing it, and requires exit testing |
The contractor row deserves emphasis. Bringing in a specialist without a knowledge capture obligation in the engagement produces a dependency that is more expensive and less loyal than the one it replaced. Make capture a deliverable with acceptance criteria. The managed service row deserves equal care, since dependency on a supplier carries the whole third-party discipline described in technology vendor due diligence and exit testing.
How do you handle a known retirement?
Treat the notice period as a capture programme with deliverables, and start before the notice.
The worst version of this is a leaving date, a handover document written in the final week, and a farewell. A workable version starts a year out: paired working on real changes, the departing expert reviewing rather than performing, capture of intent through structured interviews focused on the anomalies, characterisation tests written together, and recovery rehearsals led by the successor with the expert observing. Where the relationship allows, a part-time consultancy arrangement after departure is worth having as insurance, and it is far cheaper to negotiate before the person leaves than after.
How should this be sequenced?
Measure, capture intent while people are still there, pin behaviour, then automate.
| Phase | Duration | Deliverable |
|---|---|---|
| Dependency mapping | 1 month | Per-system counts of change and operational capability, with horizons |
| Prioritisation | 2 weeks | Ranked by consequence times fragility, agreed with risk |
| Intent capture for the top systems | 2 to 3 months | Structured interviews, decision records, annotated anomalies |
| Characterisation testing | 3 to 4 months | Executable behaviour capture with a comparison harness |
| Runbook rewrite through rehearsal | 2 months | Recovery documents corrected by actually performing recovery |
| Operational automation | 3 to 4 months | Routine toil removed, with guardrails and alerting |
| Successor development | 6 to 12 months | Named successors with supervised real experience |
| Targeted extraction | 6 to 12 months | The highest-churn functions moved off the constrained platform |
Intent capture comes early deliberately. It is the only item on the list that becomes impossible rather than merely harder once the person has gone.
Which metrics matter?
Capability counts per system, capture coverage, characterisation coverage, manual intervention volume, and time to competence.
Report how many people can change and how many can operate each critical system, and treat any count of one as a named risk with an owner and a date. Report knowledge capture coverage against the priority list. Report characterisation test coverage as the measure of whether change is safe for a non-expert. Track manual intervention volume as the automation measure. And measure time to competence for people joining the area, since a falling figure is the clearest evidence that capture and automation are working, and a static one means the knowledge is still in people's heads.
The retirement date is fixed and the capture window is not. What makes this tractable is accepting that the goal is not to replace the expert, but to reduce how much the institution needs one.
Frequently Asked Questions
Why is the legacy skills shortage a risk item rather than an HR problem?
Because it is a concentrated dependency on a small number of people for systems the institution cannot stop running, which is the same shape as any other single point of failure.
How do you quantify the exposure?
Count, per system, how many people can change it, how many can operate it under pressure, and how long a replacement would take to become effective, then rank by consequence of failure.
What knowledge actually needs capturing?
What the system does, why it does it that way, how to operate and recover it, what breaks and how it presents, and which apparent oddities are deliberate business rules.
Why is intent the part that never gets written down?
Because behaviour is visible in the code while the reason for it lived in a decision made years ago by people who have left, and nobody records reasons at the time.
Why are tests better documentation than documents?
Because a test fails when the system changes, so it cannot quietly become untrue, while a document describing the same behaviour decays silently from the day it is written.
What can automation genuinely replace?
Repetitive operational toil such as routine restarts, scheduled interventions, and standard recovery steps. It does not replace the judgement needed when something unexpected happens.
Why can automating the routine make the rare harder?
Because the routine work is how people build familiarity, so removing it without deliberate exposure to the system leaves nobody practised when an unusual failure occurs.
What should be measured?
People able to change and operate each critical system, knowledge capture coverage, characterisation test coverage, manual intervention volume, and time to competence for new joiners.
