Every office I’ve ever worked in has had both a messy kitchen and a kitchen scold who hated the messiness of the kitchen. They put up signs on the microwave about your mother not working there and they send out emails about cleaning dishes and not leaving the coffee maker on with empty pots. Scolding just starts to seem like an inevitable part of having a kitchen.
Programming teams often have a code scold, sometimes a team lead but often self-appointed, and if you have a project manager, they are almost always process scolds. They all have a lot of best practices and process methodologies and TPS forms that you need to understand and implement and complete. The main enforcement mechanism for a lot of sophisticated, high-minded software development life cycles turns out to be nagging.
Usually nagging doesn’t work very well, and they know it doesn’t work, but they just nag harder. It’s difficult for them to see that it may not be the people who are the problem. The problem may be, in fact, that their process stinks.
Constant nagging and its counterpart, constant complaining, are often symptoms of wasteful friction in your process. You can double-down and really turn up the volume, or you can approach it as another problem that needs to be fixed in getting your project out.
If you are always nagging your team, consider first if what you’re asking them to do is really necessary. Are things going fine without it? If so, try dropping it and seeing what happens. Maybe people aren’t doing it because they know that it’s not worth doing.
Sometimes, though, you really do have something valuable in mind. Maybe people don’t experience your problem first-hand and therefore don’t realize the importance of it. If you haven’t fully explained why you’re asking people to do something, give it a try. Maybe they didn’t really understand and it’ll make a difference.
Let’s say that doesn’t work. Appealing to people to do something they don’t want to do is often not very successful. What’s next? As Proust tells us, ‘To goodness and wisdom, we make promises only; pain we obey.’ That sounds Machiavellian, but Proust wasn’t very interested in power. He was a non-judgemental observer of human nature, and he preserved an equanimity about people’s failings and frailties that would make an engineer proud.
Appeals to good and wise truths, like we all want a tidy kitchen and our mother doesn’t work at the office so we have to all pitch in to keep it clean, are not enough. If people aren’t doing what you’re asking, don’t let it be voluntary. Are people letting coffee pots burn? Get a coffee maker that doesn’t use pots.
Do you want to improve the quality of your team’s code? Perform code reviews, set obligatory standards for test coverage, run static analysis reports and fail commits that are not good enough. Or create a build-deploy pipeline that both makes clear the value of what you’re asking and doesn’t give developers a choice about how to do things. Or find some tool that gives you more visibility and/or control into what developers are doing that is bothering you so much.
Whatever works. There is no silver bullet magic answer for all situations, and a lot of these things involve overhead, but figure out what’s important to you and then start trying different ways to make it happen. But please, stop nagging.