Today’s post is inspired in part by this post on programmers stack exchange. The question is about how to motivate a coworker who isn’t motivated to try new things and isn’t using the best practices for the current language/programming paradigm. Buried in the comments is the nugget “I find [the] biggest issues are the guys who’ve been doing this for 10, 15, 20+ years,” referring to the subset of the senior engineers who, if they are not using the accepted practices, are the hardest to get through to. The implication is that those senior engineers that either haven’t kept up or just never learned, are a bigger issue than the newer (or junior) guys. This makes sense – the newer engineers aren’t particularly invested in any technology or practice, or they may not have completed any big projects at all to see how the technologies worked out.
The senior engineers are the demographic to target to affect technical change, regardless of your role in the organization. After writing it down it seems obvious, but I want to discuss what I see as the interlocking reasons why it’s true. First, the senior engineers are the ones teaching the juniors. Second, the senior engineers are the ones who built most of your current system, and in doing so they defined normal expectations for development. As a corollary to that, anyone else saying that things should be done differently is implying that the senior engineers were doing the wrong thing before. Third, this is what they are used to doing and have become complacent. They’ve been doing it this way for years, and if they have been doing it for years they haven’t given anything newer a chance. Fourth, the senior engineers may have lost their passion for development, since anyone can lose interest in something they’ve been doing. Fifth, would be burnout, this is different from losing passion in that they’ve been pushing too hard, and have let themselves slip on the things they know are good in the long term for a short term win. Let’s walk through these reasons in a little more detail.
That senior engineers are teaching the juniors is again obvious; it is rare to be so lucky as to hire an entry-level engineer that is both super motivated and ready with all sorts of ideas that they want to go out and put into practice. And, even if your senior engineers aren’t teaching technical ideas, they are informally teaching the cultural values of the organization. This could be done via code reviews (or lack thereof) where the values of what is considered “good” are socialized. If a junior doesn’t use a standard library and writes 10k lines of code to do something they could have just pulled in a package to do, and nobody tells them they were wrong then that’s now accepted behavior. That means that to a certain degree, you just set back that junior’s development.
If your current senior engineers built the system, and that system isn’t obviously flawed, they could see that as a validation of whatever they did to build that system. A working system is a validation of anything and everything they did to build it, even if they were the only one utilizing that process or toolset. Success excuses many sins, but you still developed a bad habit doing it. When someone else shows up and starts trying to change things, people will get defensive about they way they were doing it before. They can’t separate the technical criticism from what they are viewing as a knock on their capabilities or insult.
The practices, tools, and resources that the team is currently used to (and their attachment to them) may be the problem. I discussed this before in a post on complacency. If a team isn’t trying something new regularly they will get stuck with a narrow set of tools in their toolbox, and not have the right tool, or even know there is a tool to be looking for. In the context of this question, complacency wouldn’t be not looking for new things to try, but not remaining open to new ideas. Senior engineers should be driving the evaluation and adoption of new tools and techniques, not just following along, but following is still miles better than hindering.
If an engineer lost their passion for building software, you aren’t going to motivate them to learn to build software differently. They won’t want to put in more effort than the minimum, which precludes any real learning. You could find them a different role that better matches their current interests. But it can be difficult for them to acknowledge that, or to find a role that fits their interests and skills.
Burnout is a whole post on it’s own. It’s different from losing passion for software. It’s where engineers don’t care to build this thing, or work with these people at all. They just want to be done with the project or release and get on with their lives. This can be a really nasty issue, since you can move from burnout to complacent or dispassionate easily and get stuck there.
As an engineer you can target other engaged senior engineers to try and spread a technical change. If you can pass on that change to one other senior engineer and have them help champion the change to any other engineers they work with, then you’ve doubled your efficacy. This will help you apply peer pressure to the late adopters among the senior engineers and have the idea seen by more junior developers. None of this will directly help deal with a senior engineer who isn’t engaged, but the idea is to flow around their disinterest. They may not be interested in changing but they may also not be interested in keeping you from doing something.
If they are actively blocking a change, try understanding why they are against the change. You are trying to understand if it’s a resistance to change in general versus resistance specific to the change you are suggesting. If the resistance is specific to a particular change work with what they are telling you. If they are resistant in general, I would suggest to take a step back and consider whether you advocating a best practice (unit testing, SOLID, design patterns, etc) or something newer and less well-accepted (a specific library or tool, a new language or paradigm). If you are advocating for the former keep pushing, try to show the value of the change by using it in other places. If the latter, perhaps you should invest your energy in a more productive way.