How to attract people to work on very old and outdated technologies?

Question

I work in a IT company that is deeply specialized in projects made with old and outdated technologies.

The biggest projects are usually a mix of Cobol (the oldest versions, not the most modern) and Java 4 (at least 60 projects on this stack), but we also have projects in Java 2 (less than 5), Java 3 (a dozen), Java 4 alone (at least 30) and Java 5 and 6 (usually translation without any refactor on architecture or logics of projects in older Java versions). We usually don’t use any Java frameworks (such as Spring, Hibernate, etc.), mainly because when the projects begun these frameworks did not exist. We also have assembly, assembly - Cobol, assembly - Cobol - Java (usually Java 4), C, C++, Fortran, Visual Basic projects (and probably a few other languages). Our software projects often don’t have any graphical interface; when one exists is in Cobol or in JSP displaying tables (CSS is barely used and there are only a bunch of projects that use vanilla Javascript). Our projects usually last from 3 to 5 years, but we also have projects that have lasted for 20+ years (as far as I know this is very very uncommon in the IT world).

We CANNOT change the stack of the projects and the language used because these are choices of the clients. We work with multinational/worldwide banking and insurance groups that widely use these languages. For example: a worldwide bank and finance group has all its internal systems (not only batch, but also the ones used by operators in branches) in Cobol on mainframes. The only part of the system not in Cobol is the home banking site, that in fact is not ours.

People working in my company, according to HR statistics, remain on average about 6 and a half years (another thing that in IT is very uncommon), but we have colleagues working here for 20 or 25+ years (maybe on the same project or on the same kinds of projects). Our salary is well above average (HR statistics, speaking with friends in other companies and simply comparing our job listings with those of others), for a senior could be up to the double of competitors.

In the last 5 years (and even more from last 2 years) we are facing enormous difficulties in hiring new developers, especially juniors to mid level ones. A lot of our job listings for those positions receive a ridiculously low number of applications and even less are the people that show themselves interested in our outdated projects after the first interview. How can we reverse this trend?

Answer 1

20% Time + Open Source

You've probably heard about Google's 20% Time policy. In essence, any employee can ask to use up to 20% of their time on pet projects.

I suggest that you implement something similar.

---

The problem of working with antiquated technologies on maintenance projects is dual:

1. Technology skill obsolescence: the technologies learned in the course of the project do not open any door; this means gambling on retiring prior to your experience no longer be needed.
2. Creativity death: maintenance, especially on high-stakes projects, often require the most surgical changes possible. There are a lot of important skills here, but I would NEVER work in a job where large-scale improvements are impossible.

This is where 20% Time comes into play!

On their 20% Time, encourage your employees to have fun. I would personally suggest participating to Open Source projects, as it has multiple benefits for both your company and them:

1. It promotes your company: look, those people are paid to develop on X, Y, ...
2. It helps employees develop skills in the area they are interested in: from kernels to JavaScript/CSS frameworks, with everything from graphics, machine-learning, big-data, etc...
3. It gives employees a creativity funnel: don't go wild on the COBOL codebase, there's likely an Open Source project out there who'd like people to come up with advanced design ideas!

And best of all, when one of your client decides to move to Big Data Framework X (I hear it's all the rage), with luck you'll be able to boast: "Do you know, we just happen to have 3 contributors to the project on our team with all the expertise you could need to help you design your application!".

---

Paid royally to work on cool Open Source projects of my choice?

Well, now that's a cool offer!

Answer 2

If you advertise looking for someone with COBOL experience, tough luck. So who could do this job? Someone less than ten years from retirement, who can afford to switch to a dead end technology, and who is willing to learn a new / old language. I learned Swift just recently. Compared to that, COBOL is primitive (I know it, took a two week course in 1979). No problem to learn it whatsoever. Advertise for someone with experience who has seen it all, offer an excellent salary with several years of job prospects, and tell them they are expected to learn COBOL, not know it.

PS There are development environments that I wouldn’t put up with, so that might be a problem.

Answer 3

This is the issue with mounting technical debt and sticking with aging tech - the amount of people familiar with the technology declines slowly at first and then quickly as they age and leave the workforce.

Eventually, the people who understand the tech will be rare as hen's teeth and will command high salaries if the tech is sufficiently essential to the business. At the same time the number of businesses which require people with these backgrounds is vanishingly few.

The name of the game in the modern IT environment is career security. If you keep getting stuck with one aging technology stack, eventually you will find it harder and harder to get a new job. This is why junior and mid-level developers don't want to join you - it could be a death sentence for their careers.

Best thing you can do is to start regularly updating your current applications and core technologies to modern standards. This will mean rewrites of almost everything - potentially completely from scratch. This will be time-consuming, difficult and more than likely costly. This is how you get new people on board - by telling them you are updating to modern standards using the latest technology stacks.

Otherwise you will eventually find when some business essential application or service eventually breaks that there is nobody who can even attempt to fix it.

Answer 4

Maybe be more prepared to hire older people eg those that are returning to the workforce after being stay at home parents or carers.

My general experience is the IT industry is incredibly ageist, often to their own detriment.

Answer 5

You're finding out painfully why so many developers specializing in old languages are making serious bank right now.

As a young developer, it's a losing proposition to adopt these technologies now - best practices and capabilities are so far from where they were back then, and software development is such a fast moving field, that if you don't work with the latest & greatest or at least most widely used technologies, you're gimping your own career hard. They'll have to expect that in 20 years so few people will be doing stuff like fortran or COBOL that their newly acquired skillset will be useless - a bleak proposition.

So do what you must - offer on the job training to people who otherwise wouldn't get hired anywhere, explicitly mention you'll hire people with prior convictions for criminal offenses (if you can square that with insurance), offer a more then competitive salary, better benefits.

The crux here is you're asking new devs to sacrifice their future career prospects, so you have to compensate adequately for it.

Answer 6

1. Remote development. Let them choose their cost base and lifestyle.
2. Flexible time. Let them work when they want.
3. High salary. Let them know their craft is appreciated.
4. Stability. Let them know this is a long term prospect.
5. Fun. Let them know the technical challenges are just as interesting as they ever were.
6. Collective. Organize a club feel around this retro infrastructure maintenance.

Answer 7

You need to offer a high enough salary to compensate applicants for the negative effect on their career which specialising in outdated technologies will have.

If you have too few applicants who want to take the job once they find out about it, the salary you are offering is too low.

Alternatively: can you amend the job spec so that people in the role spend no more half their time working with outdated tech? That could ameliorate candidates’ anxiety that they’ll end up stuck with worthless skills.

Answer 8

No JavaScript, no CSS, no obscure Annotations, just plain Java... That alone does surely catch my attention...

Increase the reach of your offer

Try to participate in University events. At my University there was a week where Companies would come to the campus and give speeches about what they did and why they were a good working option. Then they would gladly collect CV's of interested students. You may even receive a paid grant to get to know each other from the inside.

Catch their attention

Nowadays there's more frameworks than programmers and it's cool of you're using the latest framework which saves you from typing a semicolon at the end of each line...

So, why would a programmer be attracted to an old technology stack? No JavaScript, No CSS, just Java would be a good enough catch phrase for me (not related to any film).

Salary is one that's already been mentioned. What about pride? This job is not suited for everyone, you need to be a capable developer because you can't simply browse SO for the solution... Maybe this job offers intellectual challenges that will make you love it.

When you post a job offer on the Internet, give the feeling that the company is not dinosaurs with computers (I'm sorry, but it's the first thing that comes to my mind when I read COBOL). Are there any activities your workers perform that the attendees may join if they're hired? Laser games, maybe?

Does the job offer allow you to work some days a week from home after the onboard stage?

Keep them interested in your offer

For some people salary may not be what catches their attention, but something that keeps them interested. Another typical one is training: I highly appreciate jobs that sponsor official (out of the company) certificates.

If technologies are uncommon or rare, your candidates may want some job stability. Do you offer a long-term contract? Also, what are the chances of internal promotion?

Answer 9

I worked for a company (as a consultant) that was technically a private entity, but was exclusively allowed to work for the local city's governmental branches.

As is custom with government software development (in my experience), the projects weren't great. I worked on a 25 year old undocumented social security platform that was once written in COBOL, ported to VB by unsupervised interns, ported to VB.Net with no refactoring unless it broke the build, and several generations of underskilled development teams working on it with no sense of ownership and leaving the project undocumented and more fragmented than it already was.

There were many other projects like this. About 80% of the work was focused around keeping outdated and spaghetti-code-infested codebases operational because the government couldn't spare the budget to improve it.

Long story short: the developers started leaving en masse. The only ones left behind were those who didn't know (or try) any better, which only compounded the issue further.

When the company got a budget increase for one year, they decided to refactor the company in order to retain its younger and more experienced employees. And they succeeded.

What they did is (privately) acknowledge the shitty projects, and offered a massively increased work/life balance:

• Tasks are assigned the 1st of the month. You are expected to deliver them at the end of the month.
• Anything that happens inbetween those dates is your call. Work from home when you want to (all you had to do was put it in your agenda).
• Management does not set deadlines. The developer (random selection for poker session, much like jury duty) set the deadlines themselves, and the customers signed off. The company did not (to my knowledge) ever force the developers to lower their estimated hours.
• The offices were changed to flex spaces. Some floors had extra tables (for those who often do ad hoc meetings or conversations), other floors only had small one-person tables (for those who wish to work in peace and quiet).
• Other than being present for meetings (usually one every two weeks), no attendance was required.
• Work was evaluated based on the end result, not time spent.
• The company intranet was put online, making it possible to work from anywhere with an internet connection.
• Other than the code repository (internal TFS), all tools (including email) were available on every PC with an appropriate login.
• Should you not be able to deliver, you either get your project manager's approval to push your deadline, or you can go and convince the customer directly (note: most developers would already be in contact with the client directly anyway). As long as either the company or the client signs off, it's all good.
• Leave application are approved virtually regardless of scheduling (note for internationals: we have paid time off here, and the amount of (paid) leave days is known by you and your employer).
  • Anecdotal: I had to ask for a three month absense once (due to work reasons, not holiday). Without speaking, the PM turned to his laptop, opened a spreadsheet, put a 0 in three columns, and that was the end of it. No discussion.

Did this improve the quality of the projects? No. There still wasn't budget nor time to redevelop these applications.

But the company started retaining the good developers, and the easy going work environment gave them more than enough slack to offset the otherwise unenjoyable project work.

Before, the company was choking on unskilled (or unwilling) employees who weren't effectively contributing but were creating more work in an attempt to look busy. It's very hard to get rid of these employees when they outnumber the "skilled" developers.
Maybe it's not applicable everywhere, but that "create work to create job security" mentality is something that is stereotypically attributed to government workers here. It's very common.

Because the company gave the employees an almost criminal amount of freedom, employees felt free enough to not bother looking busy anymore. Work was being graded based on the end result, not on time spent working.

I've read other cases where companies experimented with a "free leave" system, i.e. the employees were free to take as much leave as they wanted. And, as it turned out, the average leave taken did not significantly change from the rigid leave system they had before.
Some abuse happened, but many employees felt free enough to take leave when they wanted to, that they became less insistent on the specific leave days they were alotted.

Personally, I heralded the downfall of the company, but I have to stand corrected. While the quality of the work hasn't improved, they've managed to offset the horrible projects with an amazing work/life balance.

Answer 10

I work in a IT company that is deeply specialized in projects made with old and outdated technologies.

The biggest projects are usually a mix of Cobol ...

Consider changing your company's mindset and approach. Instead of requiring simply Cobol expertise (and your coder to code just in Cobol), also ask for static source code analysis expertise, and hire people able to use or even develop static source code analysis techniques (perhaps even some in-house semi-automatic code transformer/analyzer). That market is more attractive (technologically). Of course you'll need to offer competitive salaries (and you would perhaps hire PhD level developers).

BTW, I know a few companies (specialized SMEs) doing static source code analysis (and semi-automated code transformation/refactoring) on decades old Cobol code.

A person having worked a few years on source code analysis of Cobol is likely to find some other interesting job later (e.g. would move to another company doing source code analysis of Java). A person expert in Cobol (only) has to stay in that world (and is gambling that there would be still some other job in Cobol). Of course, source code analyzers are often coded (the tools themselves, not the code they are analyzing) using fancy technologies (e.g. Ocaml, Haskell, etc...)

Of course, you would then also sell to your clients the service of refactoring (perhaps even rewriting partly) old Cobol code (so convince them that technical debt is a worry). And that is not cheap.

BTW, if you know some H2020 or future FP9 European project proposal where such a work -static source code analysis of Cobol, not manual refactoring of Cobol code- could fit (but, in july 2018, I don't know any) -or if you want to propose a direct industrial contract with my employer CEA, LIST-, don't hesitate to contact me by email to [email protected]. I am working in a lab with static source code analysis skills (but our current tools are not targetting COBOL; we could adapt them for COBOL -not sure that makes technically sense-, or develop COBOL static analysis tools, if and only if we are funded for that; my naive opinion is that your market might not be large enough for that: developing static analysis tools is expensive and takes time. But if your company -or client- can afford a million € project for 4 years, please contact me; more probably you'll better -and that is difficult- network and find several other companies willing to share the risk and cost).

My naive opinion is that the skills you are after are costly, but not that much. In a few years, they could be even more costly and rare, and then a static analysis and semi-automated refactoring approach would make much more sense. Your company could bet on that and start building its own static source code analysis of Cobol code. And yes, that takes years and costs a lot. There is No Silver Bullet.

Answer 11

TL;DR: You shouldn't expect juniors for these roles.

There are some very excellent comments, and I can't list the source authors effectively, but those points are basically this:

You're asking someone to go into a dead-end job and risk being unemployable.

There's only one best-case scenario listed: The person working on these old stacks retire before the stack does.

For a junior, we're talking about 30-40 years... you really do not expect to work at a place for this length of time, especially if you will be unable to get another job after working there. If I gain 5 years of experience in all the tech you worked with, what exactly will that do for my next job? Would it even add to my employability or subtract from it?

I don't think you can realistically expect juniors to go for these positions. This is a career track that is extremely risky, and unless you offer up some sort of massive early-retirement pension, the risk is extremely high... they join your company, work for 5-10 years, get married, have kids, and then suddenly become unemployable.

You have to accept what your business model is and consider whether hiring juniors are even realistic.

Answer 12

I am a junior developper working in a company with the same constraints and languages as yours and I disagree with people saying to update your technologies or expect an aging population. The technologies choice is out of our hands but we are sure Cobol won't die soon. New projects are unlikely, but the maintenance domain is very large. My answer is maybe lacking insights of what the "real" market is like, but it is how and why I got into my company. What my company decided to do might be France-specific, but I'm sure you will find comparable solutions in your country.

First of all, we take interns and pay them twice as much as the standard. We take care not to have too many interns, juste a fine number that we can care for and handle (one per group ie one in roughly 12 people). Then, we try to systematically offer a position at the end of the internship, or a part time learning (sandwich course I think we name it in English). The idea is to look as attractive as possible to juniors, and offer them what they need (experience, stability, good money or just an internship). Make sure to tell them you have maintenance contracts for the decade, and that they can progress in the company as they get more experience. I do not guarantee you will keep them for 10+ years, but 3 or 4 out of 10 might stay for 5+ years.

We also have a strong partnership with schools and faculties around. The idea is that our juniors might have a good experience and share it to their friends/colleagues, the university finds a way to make sure their students find a job and we have a recruiting pool. We also offer cooption (you get a bonus if you suggest a recruitee that is recruited).

When I was applying, my colleagues showed me they had a nice work environment without going in the whole Google like workplace. It can be simple touches like offering flexible time, activities with colleagues or a massaging seat.

We are not afraid to hire people from different walks of life. Many of my colleagues are former researchers in biology and physics. We also have a partnership with the national unemployment agency. Lately, we have won a contract with them in exchange of the hiring of 14 unemployed persons selected by them. We have formed them for 2 months, them let them work for 3 weeks to see how they were doing, and they are now all hired.

Answer 13

As I said in comments, this is the sort of job I would like (though I work mostly in science & engineering, not business apps), and I don't think I'm alone.

So how do you attract me? First, be willing to hire older* people. I think there are plenty of people out there who have a lot of experience in these languages, and who actually enjoy programming, especially if the project is inherently interesting to them. Offer part time work, flexible hours, and telecommuting. Good pay helps, but it doesn't have to be spectacularly so. Frankly, at this point in my life, I don't need to work (unless the current President totally screws up the economy, in which case we all may be going back to farm labor :-(), but neither am I interested in being "retired".

*Or other people from non-traditional backgrounds, as for instance a friend of mine from university with a lot of good experience that's ~20 years old, because she decided to be a full-time mom. Well, the kids are grown, and she's bored, but everyone wants either new grads or people they've headhunted from other companies.

Answer 14

I would suggest looking for people in their early 30s to mid 50s especially those who are thinking about getting out of IT because they are no longer into the brogrammer scene. Settled people with children especially women who can't work the ridiculous hours of some start-ups. Retirees whom no longer need to keep up with the Joneses.

Offer things attractive to this group like paid daycare. No overtime. Lots of vacation time. Flex hours. Remote working. Part time. Retirees especially might like the part-time part as they are not going to want to work full-time and aren't going to care as much about staying current.

See if you can offer projects that are a mix of some with older technologies and some cutting edge stuff. Or offer 20% time to work on projects using any technology they want to learn.

Answer 15

This question has answers I totally agree with, but I believe they are missing a few minor nuances.

I don't believe you're selling your entry-level positions as apprenticeships very well. Try using a combination of modern code-writing practices (pair programming, some version of agile) with the old technologies you're working with, and getting junior-mid level guys who want to take the next step up interested by saying, "Hey, these old guys know COBOL / etc. like the back of their hands. That will help you code in easier languages much better."

Because that's the truth. Offer entry-level guys the opportunity to inherit knowledge of dozens of languages / sub-languages that will die, but leave a huge footprint behind that needs maintenance and someone who can understand the code for upgrading.

Also: update your tools and use the best you can find. Automated build systems connected to source control, cloud servers if you can manage them, etc. If you have a modern-looking programming environment that does something old-fashioned, you may get both more productivity out of your existing employees and be able to attract whippersnappers like you want.

Answer 16

As with any "how to hire programmers?" question,

for better or worse, there is one and only one answer.

Money.

---

OP is basically saying "We're finding it incredibly hard to hire { a certain type of } programmer..."

But wait. It is incredibly hard to hire ANY particular type of (good) programmer at the moment.

Answer 17

Demphasise technology. Put accent on learning universal skills.

Bascialy: "learning how to learn".

Lots of people here point out that learning COBOL is a "dead end", touting as example to the contrary eg. Spring. That's quite unreasonable. Spring is merely 15 years old today. It's unsafe to assume that something can last you a lifetime. What you need is to shatter this erroneous preconception and educate candidates that their job security doesn't rely on any particular technology, but on their ability to adopt any technology necessary at a given point. Wrap it into some cool, marketable term, like "cross-language agility".

Also, you can emphasize on long-term hob security. High turnover rate in IT is not a goal by itself, it's merely a tool to increase salary. If you offer good salary from the start, 6+ years average is a good thing. "A job where you'll want to stay".

However, when one switches jobs, especially a junior, the general skills are not as important as immediate experience in given technology. To address that concern, you should offer courses, workshops, side-projects and open source involvement, etc in modern technologies. Basically, a side-project to keep tabs on current developments. Something that your employees could write in their resume to not appear as 100% dedicated to IT archeology. For me, it would be most interesting to rewrite an existing project with new tools just to see if it would do any better - but it should be something for your people to decide.

The final issue is the current state of the job market. Everyone has openings, but there is not enough people to fill them. Even in modern jobs like mine, we got like 2 reasonable respondents to a posting. Most channels yielded exactly 0, the only responses we got came from a FB group. Maybe try that, instead of trying to convince mass-produced graduates to COBOL, look for people who already are curious about programming history (or low level) and train them into programmers.

Answer 18

Diversify your client base. You claim you cannot change tech stacks because of your clients, but you can change clients.

Your current trajectory has two concerning end points:

1. You cannot hire new developers, therefore cannot fulfill the clients' needs, and you lose all your clients.
2. Your clients update their technology, and your current staff is unable or unwilling to go along, and you lose all your clients.

Answer 19

Coming at the problem from a slightly different angle:

Noteworthy is that a lot of people who see a job posting that says "COBOL" will just look the other way, because it's a new (to them) technology that they have certainly had no exposure to. Likewise, Java 4 (or pre-4), and so on. I think the most important thing here is to advertise, upfront and openly, that you are not expecting people to come in with ANY COBOL experience WHATSOEVER, and to live true to that. Having personally gone through a bunch of interviews, there were a lot of companies who said in their phone screen "yeah, we use that technology but we don't expect people to actually know it, you can learn on the job" and then the interview was all specific questions on the minutiae of that technology. This is not cool, and unfortunately too many companies do this so "we don't actually require this in our skill set" on the job posting holds little weight with applicants, imo.

What might be more helpful is, in your job posting, explain how applicants are expected to learn these old technologies at the company, to prove that you don't actually expect them. Then, during the interview process, keep your questions as general and technology-agnostic as you can: be aware that probably nobody you interview actually has the skill set you're looking for, but if they've applied then they're willing to learn it; this means that asking questions about those technologies during the interview is likely to be a red herring and give you a lot of false negatives, i.e. people who are good developers but don't know your tech stack (as has already been established, nobody knows your tech stack except you, because of your niche business).

The other thing to consider is, who are your applicants? Off the top of my head, I think you can probably divide a good applicant to your company into one of two buckets:

1) People who are extremely smart, extremely talented, for whom life at Google is rote and mundane, who are looking for a bigger challenge in a niche market. When you say you pay double your competitors, are you considering Google as a competitor? Because for these people, your competitor is Google, Amazon, Twitter, Facebook, etc, i.e. the tech giants. These are people who could go work anywhere they wanted, but they're choosing you because they think your company provides a particular interesting challenge to them. However, these people want to be compensated for what they're worth, and you should expect to be paying them what they're worth or they're not going to be interested.

2) People who have no other choices; their skills with modern technologies suck, so they're going with you because "might as well give it a shot". These people have much lower expectations, but they are generally much worse developers, so it's debatable if you want to be targeting them aggressively. If you do, though, posting on job boards is probably not where you want to be; these people have already looked through job boards, applied to hundreds of postings, and are sick of the grind. For these people, you should contact recruiters/headhunters. These applicants may be waiting for a headhunter to call them with whatever new and shiny job description is on the table, and you want that to be yours. The important thing, though, is that job boards are not going to get these people; if they wanted a job from a job board, there are many companies they could apply to that don't require (or look as though they require, even if you don't in reality) knowledge of COBOL and Java 4.

There is a third group, which is developers who are so old that they grew up on COBOL and Java 4. The reason those developers aren't under discussion is because they are close to retirement age; even if they were to join your company en masse, you would only be delaying the problem you currently have for maybe 5-7 years, and then you'll be in the same position all over again. Targeting these people is not the solution you're looking for.

Answer 20

One sign of a good company is that they anticipate their manpower needs and have a plan to meet those needs regardless of what the current stock of unemployed developers has to offer.

The opposite approach is to rely on luck. Only fools do that.

Your hiring practices should depend on identifying people with the aptitude for software. It's a bonus if they know the specific language(s) that match your needs, but a lack should not be a show-stopper.

Your on-boarding training program should include a boot camp for the specific skills you require.

My own company's flagship product is coded in COBOL. We hire entry-level talent and teach them COBOL. We also code products in C++. We hire entry-level talent for these products, and teach them C++. Ditto for C#, SQL, JavaScript, VBScript, etc.

Answer 21

Offer the roles part time

Those around retirement age, particularly if they have been COBOLling for decades, are more likely to be looking for part time roles than younger workers. The median hours worked for 56-75 y/olds is less than half that of 26-55 y/olds in these IFS statistics, even as both vary.

It may seem counterproductive to get part time employees as you'll get less work per hard-to-recruit employee, but you may be able to convince them to add hours after they've joined.

Accept second jobs

If I were to see such an opportunity, the only thing that would persuade me to apply would be the possibility of simultaneously doing work on up-to-date technology. If I could work on my skills in new technologies (at sub-median pay) whilst simultaneously doing this job (at high pay), that would be an acceptable compromise.

Or mix the role

If you have a part of the business which does work on new technologies, offer a mixed role in which above-average pay gets the employee both new experience and the higher pay of the old technology.

Most small-business development roles involve a degree of new mixed with a degree of maintaining the (in)glorious old; sometimes, you accept you'll spend a week fixing something that came out of the ark, just because.

Offer a very family-friendly environment

There is a huge hole where there should be jobs which work around the family schedules of skilled-but-family-orientated people. A role which combined the above opportunities to learn/use up-to-date technology, paid decently well, and was thoroughly flexible, would be an absolute gift. I have a family, I would love to be able to work between picking up the kids, with a couple of days at home, doing extra work in the evenings or when sitting outside the ballet lesson.

Answer 22

Per LeopoldT's (OP) comment:

As far as I know my company is the biggest in the country for these kind of projects. And the only one so specialized in these old technologies. Another factor is that for clients is very difficult to move to competitors after 20, 25 or more years with us: the amount of knowledge to be transferred is simply tremendous (also for money to spend)

If your company is still doing well (i.e. with enough resources), then an effective solution to attract the younger generations may just simply be:

• assign X hours of the current developers time to build up courses on those technologies;
• create contracts which include a paid tutoring period of time based on these courses;
• add clauses to the contract that will require the recruit to work certain amount of time after taking the course (not a legal expert: this might not be possible or it may need adjustments);
• advertise in universities with those same courses highlighted (possibly only requiring a bachelor's degree and basic programming skills for the screening tests), mentioning something similar to: "We are the largest company developing with [programming language/technology] in [country] and a stable career progression might just be waiting for you with us!" (not the marketing expert either... some adjustments might be needed).

Answer 23

Collect talent, train talent, secure talent.

This won't be cheap, but you probably knew that already. The good news is that you have a unique opportunity in centralizing resources for deprecating technology.

First and foremost, collect talent. Get the best developers in your fields that you can. Relocate them from wherever. You can probably get an unshady H1B for this to import developers. This becomes your backbone.

You'll need to advertise that you have talent to spare. Social-friendly blogging is probably your best bet. You want to get as many of your best and brightest out in the public eye in hopes that one or two of them become a minor celebrity. The marketing people will appreciate the exposure, but your real goal here is posturing in the development community. You want the other A-players to see people they know and respect. It'll draw more resumes and create a virtuous cycle of collecting talent.

Next, train talent. The top tier of college graduates is off limits to you. Sorry, but that's life. You want to screen the leftovers. Get HR in touch with state agencies to find out who's doing retraining. You'll probably be able to set a curriculum, have them trained on the state's dime, and pay barely half their salary for the first 3-6 months. Set appropriate expectations for them: this is an internship position with the rare possibility of hire, but you'll pay them more money than most of them have ever thought possible if they work hard and succeed. Do career fairs at community colleges and take their best and brightest. Be a sponsor of some of those self-paced online learn-to-hire programs and snag yourself some strong self-starters. Give people who have a portfolio but no resume a chance (and probably stick them in with the career change interns for safety). If you have to, recruit the bottom half of CS graduates, but I'd avoid it if I could. Then you train them using a mix of your collected talent and the best available standardized curriculums.

Finally, secure talent. Once they've made it past your probationary period, you do not lay anyone off for any reason ever. You make this abundantly clear in your interview and recruiting processes. A job with your company is a job for as long as you follow the rules and produce results. If you've done a good job collecting talent, you'll become a valuable asset for enterprise customers because you already hired nearly everyone they'd want. You can also do it at scale because even though individual clients come and go, you should have a big enough pool of clients to keep all the bills paid. That part is marketing's problem.

Answer 24

A lot of our job listings for those positions receive a ridiculously low number of applications and even less are the people that show themselves interested in our outdated projects after the first interview.

Your company sucks. The job you are offering sucks. The pay sucks. Don't fool yourself in thinking it's the applicants' fault, or the interviewees' fault. It's you. Nobody even wants to apply for your jobs, the few that do, don't even want to continue to interview after a first meeting. You are not just failing to attract candidates, you are actively driving them away. (You're also in the midst of a period of lowest unemployment in American history.) You need radical change.

Our salary is well above average, for a senior could be up to the double of competitors.

Highly unlikely. Let's get real about salaries. Don't imply with hints and coded language, and make me guess. I don't know what your basis of comparison is. Tell me what you're paying. Are you paying people $350k+, 425k+? That would possibly be double. What's a "senior" at your company? 5-10 years out? Then how is that relevant to applicants or interviewees? What's the Xmas bonus -- 15% of salary, or is it a $50 grocery card?

We CANNOT change the stack of the projects and the language used

Which means you need to "buy" (i.e. hire) a scarce resource -- the people willing and able to work on older, outdated tech. Basic economics says a scarce resource will cost a lot more.

Now, there are people who would be happy to do this work. But, as other people have stated here, you need to 1) pay them a lot (i.e. more than what is comfortable for you) and 2) be ridiculously flexible with hours, location, vacation time, prior experience / willingness to train, acceptance of part-timers, older workers, and 3) publicize this -- like I said, don't make me guess what you're paying or whether I can work from wherever I want. And keep in mind, the people most qualified and competent are going to be the ones most able to demand higher salaries and least willing to accept rigidity like specific hours -- because generally, they are skilled, smart people who have had successful careers for a long time.

We work with multinational/worldwide banking and insurance groups

That's a big plus. They've got plenty of money right now.

Answer 25

To get someone to take a job, they must believe it is a good job for now and either:

• Truly believe it will be a good job for the rest of their working life
• Or believe it will not stop them from getting their next job

As no one can predict the following:

• how long a company will be in operation
• whether the company will be bought over and/or the work moved to another country
• whether the employee will be forced to leave due to a bad boss
• if an employee wishes to relocate due to a relationship etc

Most people are sensible enough not to believe a job is for life, unless they are only planning to work for a few more years.

The bottom line is this. Most employers expect people with up-to-date experience in the systems they are using... hence there is nothing you can do to attract and retain candidates, without giving them some work on modern systems.

Therefore you may need to take on additional projects that allow you to train all staff in modern systems and give them the experience while having them spend a few months a year on the "outdated" technologies.

Or maybe you can become the best employer in town for training, with everyone knowing that when someone has worked for you for a few years, they can get jobs with lots of other companies. You can also offer flexible contracts, free workplace childcare, part time work arrangements, the list goes on. Essentially making you the only employer in town that fits well with some peoples' lifestyles.