Nobody Is Coming to Fix It

There is a moment that arrives quietly in a lot of companies, and it lands like a dropped stomach.

You finally decide to hire someone to work on your aging system. You write the job post. You wait. And either nobody qualified answers, or the few who do want a small fortune, or your one veteran developer picks that exact week to mention, casually, that he is starting to think about retirement. And you realize something you had never quite let yourself think all the way through.

There is no bench. Not in your company. Anywhere.

You always assumed that if the person who knows your system left, you could simply hire another one. That assumption had been quietly expiring for years, and you only found out on the day you needed it to be true.

The clearest place to watch this happen is COBOL, the language that still silently runs a shocking amount of the modern world. This is not ancient history. COBOL still processes around 3 trillion dollars in transactions every single day and handles the vast majority of ATM withdrawals in the United States, with hundreds of billions of lines of it still in active use (https://www.metaintro.com/blog/cobol-developer-shortage-legacy-systems-career-opportunity-2026). The systems did not go away. But the people did. The average COBOL developer is now around 55 years old, and roughly 10 percent of them retire every single year (https://www.pragmaticcoders.com/resources/legacy-code-stats). More than 85 percent of universities dropped COBOL from their curriculum back in the 1990s, when everyone decided it was dying (https://www.metaintro.com/blog/cobol-developer-shortage-legacy-systems-career-opportunity-2026). Three decades later the language is alive and the talent is not, and 60 percent of the organizations depending on it now say that finding anyone who can work on it is their single biggest problem (https://www.pragmaticcoders.com/resources/legacy-code-stats).

Read that as an owner. The software is immortal. The workforce is mortal. And nobody warned the companies caught in the middle.

Now, your system is almost certainly not COBOL. But do not let that comfort you, because the exact same physics apply to every technology, just on a faster clock.

Here is the principle nobody explains when you first choose a stack. Every technology has a talent curve. When it is young and fashionable, developers flock to it, bootcamps teach it, and hiring is easy and affordable. It peaks. And then, slowly, the world moves on to the next thing. The people who know your aging framework stop being plentiful. The new graduates never learned it. The ones who do still know it realize they have become rare, and rare people set their own price. You did not move an inch. The market moved out from under you.

And the cruelest part is the timing. This never announces itself. For years, hiring for your system is perfectly fine, so you file it under solved and stop thinking about it. Then one year it is quietly not fine, and by the time you truly notice, you are trying to hire scarce, expensive talent for an unfashionable system, from a position of near total weakness, at the precise moment you need that talent the most. You have the least leverage exactly when the stakes are highest.

When we sit down with a company at Cause of a Kind, one of the questions we ask is not just whether their software is aging. It is whether the world that can support that software is aging along with it. Can you still hire a human being to care for this thing, at a price that makes sense, next year and the year after that? Because a system you cannot staff is not an asset you own. It is a countdown you are pretending not to hear.

So here is the wisdom, and it reaches into every hiring decision you will ever make.

When you choose a technology, you are not just choosing a tool. You are choosing a labor market. You are placing a quiet bet on who you will be able to hire in five years, and at what price, and how easily. The smartest technology decisions are partly talent decisions in disguise, made by people who thought one move ahead and asked not only whether this can do the job today, but whether anyone will still know how to run it when the person who built it is gone.

Build on what people are still learning. Not on what they are only retiring from.

If you have ever felt that small cold drop when your most essential technical person mentioned slowing down, or watched a job post for your system sit there collecting silence, then you already know this is not a someday problem.

The software will outlive the people who understand it.

The only question is whether you plan for that on your schedule, or on the day they hand you their notice.