When organisations struggle to find mainframe skills, the conversation usually turns to the same conclusion: there are no people left who know this technology. The expertise is ageing out. It cannot be replaced.
That conclusion is wrong. And it is costing organisations dearly.
The framing problem
A European organisation posted a job opening for a “Mainframe Developer.” They received three applications. The hiring manager was frustrated: you cannot find COBOL skills anymore.
A recruiting firm reposted the same role under a different title: “Enterprise Application Engineer for high-volume, mission-critical transaction processing.” The job description talked about building super-reliable systems, processing millions of transactions per day, working with AI capabilities, Python, Java, and yes, COBOL.
They received 47 applications in two weeks. All applicants were under 40.
Nothing changed except the framing. The talent was always there.
What the job description should say
If you are serious about staffing your mainframe teams, your job posting should read something like this:
“We are building transaction-processing systems that handle a significant share of the world’s financial transactions. You will work with AI accelerators, containers, event streaming, and Python, alongside COBOL, processing millions of operations per second. Your code will touch critical infrastructure every day.”
That is not spin. That is an accurate description of what mainframe developers do. The problem is that most organisations describe the same work as “maintaining legacy systems” and then wonder why no one applies.
Focus on the modern stack in your job postings: Docker and Kubernetes, Git, Jenkins, Ansible, Python, Java, GenAI tools, Kafka, REST APIs, VS Code and modern IDEs — alongside COBOL and PL/I. Be clear and forward-looking: your platform runs everything from code written in 1985 to services deployed yesterday. That is not a liability. It is the reality of running systems that cannot fail.
It works in education too
In my book I describe two cases in which organisations changed their approach to mainframe talent — one in industry, one in higher education. The results were striking in both. Enrolment numbers increased dramatically once the work was framed differently and connected to real impact. The students and candidates were always there. They just needed a reason to look.
The lesson from both cases is the same: awareness and framing are everything. The talent is not missing. It just has not been shown why this work matters.
Hire for potential, not experience
A smart developer can learn COBOL in weeks. She will not attend a week-long classroom course; she will use YouTube, GitHub, and online communities. What you cannot teach is curiosity, problem-solving ability, and a willingness to work with diverse technologies across different eras.
Look for strong problem-solving ability, programming fundamentals in any language, a learning mindset, and communication skills. The mainframe-specific knowledge follows.
Internal mobility — an underused path
Your best source of mainframe talent may already be inside your organisation. Cross-training existing developers is faster, cheaper, and lower-risk than external hiring:
- Java developers can learn mainframe Java — WebSphere Liberty is a natural bridge
- Database experts can learn Db2 for z/OS
- DevOps engineers can learn z/OS automation via Ansible and Zowe
- Cloud architects can learn hybrid cloud architecture patterns
Existing employees already understand the business, the systems, and the organisational context. That knowledge takes years to build externally. Cross-training creates valuable cross-platform expertise and costs significantly less than recruiting from outside.
Invest in modern tooling
If your developers are still primarily using ISPF and 3270 terminals, you are sending a clear signal: we do not invest in our people. A minimum modern baseline includes VS Code or Eclipse with z/OS extensions, Git for source control, automated CI/CD pipelines, GenAI-supported development, and modern collaboration tools.
Modern tooling does two things: it makes existing staff more productive, and it makes the platform attractive to new developers who expect to work with familiar tools.
The bottom line
The talent is available. You just need to make the work visible, modern, and appealing. When you do that, the applications will come.
And if staffing concerns are driving your platform decisions — if you are considering replacing the mainframe because you cannot find the people to run it — fix the staffing problem first. It is faster and cheaper than replacing an entire platform. And if you are planning to migrate away, you will need mainframe expertise throughout that multi-year journey anyway.
Staffing strategy, internal mobility, and building a mainframe workforce for the future are covered in my book Don’t Be Afraid of the Mainframe: The Missing Introduction for IT Leaders and Professionals, available on Amazon, Barnes & Noble, and other bookstores.