How to manage old, unmotivated, change resisting programmers?
16 comments
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.
we don't want to filter out, but manage.
Old age is not something to be managed. People are old, not by choice, but by natural processes that no one can control. You will be old one day and hopefully no one will see that as something that has to be managed, but if we feed into this negative trend then it is likely you will be seen in that same light. In the meantime, make a positive move away from ageism and remove that attribute from your mental profile of employees who requirement more management than others.
Your question implicitly suggests that you wouldn’t have problems managing young, unmotivated, change resisting programmers.
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?
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?
Young people generally don't resist change because change benefits them. People who have invested 5 years into an obsolete skillset are most resistant to change.
Could you define “manage” in more detail and possibly provide an example?
Right now this is very vague and it sounds like you’re facing an immovable obstacle.
Right now this is very vague and it sounds like you’re facing an immovable obstacle.
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.
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.
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.
That is exactly what the manager at my last company did. Unless the workload was too great for the rest of the team to do alone, the more aged members of the team worked on internal tools (unless those were too high profile).
What sort of change?
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.
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.
I’d type out an answer but I just saw Sandi Metz’ amazing talk on influence in the context of software teams.
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.
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.
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...
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...
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.
Get someone older than you to manage them.
Is this at Oracle? :-)
Sounds a lot like the other old school tech companies as well: IBM/Cisco/HP/Intel/etc...
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.