To be clear, your "old" programmers should be among your most valuable employees as they should know what pitfalls to avoid, what the warning signs are and should know a great deal of design patterns or tricks to help improve your project.<p>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?)<p>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.
Let's start removing "old" from the list of things we want to filter out of our workforce. Age discrimination is real and it surfaces in the most insidious ways such that adding it to a list of negative traits just seems natural.
I did not have experience with the whole team or department consisting of such guys, my situation was just several individuals (and I could not just fire them) within overall good collective. My appoach was to be very straightforward in communications, no motivational bullshit and no teaching tone. Just straight to what I expect from them to deliver. And I tried to give them tasks that are less related to critical core functionality - more like admin tools, etc.<p>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.
What sort of change?<p>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.<p>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.<p>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.<p>Once they feel effective on implementing the change then they will better cope with what needs to be done and work toward it.
I’d type out an answer but I just saw Sandi Metz’ amazing talk on influence in the context of software teams.<p>Highly recommended.<p><a href="https://m.youtube.com/watch?v=VzWLGMtXflg" rel="nofollow">https://m.youtube.com/watch?v=VzWLGMtXflg</a><p>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.<p>Example: I requested that we make changes X, Y and Z, and Peter refused on the premise that ... (to replace “change-resistant”)<p>Also, Peter is 45. (To replace “Old”)<p>Working with judgments is difficult because they close the possibility for dialogue. Working with observations opens possibilities for inquiry.<p>Also, even programmers can feel when they’re being judged, so there’s that.
Lead by example e.g. don't ask them to do stuff you wont and make it about the team, if they like to be part of it, they have to pull their weight and have to have the backs of their coworkers...<p>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...
First, check if old person really does want to grind hard on coding. If not, there could be issues that came up or accumulated over time. Burnout is most likely example - how many humans do well staring at code for decades? Not all programmers become more productive over time. Just an anecdote really but surely this is the case for many.