Motivating older programmers is different from motivating younger programmers. They've seen layoffs, acquisitions, failing companies. They've also seen multiple project management philosophies come and go and generally aren't impressed with agile and scrum. Most older programmers I've worked with want some combination of the following: money, being able to do good quality work and good work-life balance. They're unlikely to pull all-nighters or work more than 40 hours because at this point they've seen how destructive and ineffective those are. To motivate them you can offer flexible hours, remote working privileges, vacation time. You can also check with them to see if they want to explore different roles (would they want to do some project management? UX design? devops/system administration? Also you are doing regular 1:1s, right?)
Now you may encounter some problems with these older programmers learning new technologies (I had a former COBOL programmer give up on web services even though he was using Microsoft COM apis on a regular basis). In these cases, there are two good solutions. 1) Spend extra time with the programmer, mapping the terminology they're learning with the terminology they're familiar with. 2) Have them work on different projects that are more closely aligned with their current skills.
If so, do you think there is an innate difference between old unmotivated, change resisting programmers and young unmotivated, change resisting ones, or could your attitude towards the two groups be different?
Right now this is very vague and it sounds like you’re facing an immovable obstacle.
Do not expect any wonders from them, and you cannot just change them - try to reduce risks,harm, and demotivation they can bring and treat them as adults.
Have you asked them what they don't like about the change? - Just letting them say their peace to the right people will alleviate some of their anxiety, especially if the concerns are repeated and addressed or at least responded to.
Does it clearly solve problems in the existing system? - Show them the pain categories in the old system that the new one will address, features that work better or are easier to maintain.
Are you giving them enough learning/experiential on the new system? - Let them try out new methods on the new system such as testing solutions that they feel might not work, so they can see all is good, or really less impossible they may have thought.
Once they feel effective on implementing the change then they will better cope with what needs to be done and work toward it.
Highly recommended.
https://m.youtube.com/watch?v=VzWLGMtXflg
As for the rest, I’d take a step back and check if it is possible that the “old, unmotivated, change-resisting” could be possibly judgments (hint: they are) and what did they result from.
Example: I requested that we make changes X, Y and Z, and Peter refused on the premise that ... (to replace “change-resistant”)
Also, Peter is 45. (To replace “Old”)
Working with judgments is difficult because they close the possibility for dialogue. Working with observations opens possibilities for inquiry.
Also, even programmers can feel when they’re being judged, so there’s that.
If the team does poorly, most likely will be disbanded, so they'll have a vested interest to stay together and for the people who don't want to be part of it, you as a manager have to find them a better fit in another team in the company and replace them with a better fitted employees...
