I think that the most important thing I've learned while trying to improve my abilities as an organizational change agent (read: a programmer that likes to get his way), is to never ever present some idea as a best practice. If you don't know the reasoning well enough to explain it with that reasoning alone, you don't understand the problem or the practice well enough to suggest it.
One of the most powerful techniques you can use for convincing people is to stop coming to them with improvement ideas when the problems they solve aren't already obvious to them. I've been on both sides of these kinds of attempts to convince people and they rarely work. When I'm on the receiving end and I hear "Hey Gregg, I think we should do X", I immediately need to know:
What's the problem you're trying to solve?
Why are you prioritizing that problem ahead of our other problems?
What other solutions did you consider for solving that problem?
What are the pros and cons of each possible solution?
What made you consider this solution to be the best of all them for your situation?
The first question is the foundation of it all though: What's the problem you're trying to solve? When I'm thinking of suggesting a practice and I can't immediately and clearly answer that, I know I'm stuck in solution-first thinking. No one will be convinced by someone with that approach except the very few that happen to share your biases. I generally drop any idea like that entirely at that point instead of inventing an after-the-fact rationale. If my idea wasn't conceived "problem-first", it's not coming from the right place.
(I once had a junior engineer bravely ask "Why do we use version control?". I had been using version control for almost 2 decades and still really needed to force myself through those 5 questions. It was illuminating for both of us.)
Is your best practice really "best"? Will there never be a better one? Did you give your team a chance to find their own solution that is better for their particular situation?
In general if you think you've found a best practice, you're probably not going to look for one that's better. You'll be standing in the way of your team improving and in fact the craft of software development improving as a whole. You'll be the last to adopt a better a practice if someone presents one.
What you call a "best practice" today came from an open-minded team that decided they wanted to try for something better than the current state of practice. It didn't come from a team that was happy with the status quo.
With all of that said, for things that are inconsequential, just using a "best practice" is often the smartest thing you can do. One real-life example for me was when some engineers on my team decided to use http's DELETE method to update a record in a new way after already using PUT for the usual scenario. They tried it locally and it worked. Why they didn't simply just use a POST to a new url was beyond me, but the reinvention of that proverbial wheel came back to bite us when our reverse proxy didn't allow bodies on DELETE requests. The lesson here is that if there's a standard way to do something and you're working in an area that doesn't really matter to your team/company, I'd always recommend just using the standard way. Sometimes you do just need a proverbial wheel and there's no reason to reinvent it.
Emulating others is a necessary step in learning too. If you're used to looking at practices used elsewhere and considering reapplying what has worked, definitely keep doing that. You should always keep learning about practices used elsewhere and it would be wasteful to always be reinventing the wheel by working only from first principles.
What I'm saying though is that for practices that really matter to your team, the next level is to additionally take the time to deeply understand:
Being rigourous in your understanding of a practice and its rationale ensures that you don't apply the practice unnecessarily, or to the wrong problem, or incorrectly. Without this, you're just emulating a mature team and not actually maturing; you're cargo-culting.
The anti-pattern of "best practices" promotion includes arguing for hand-wavey proxy goals too. I'm talking about reasoning like "Let's do X because X is..."
You may think some or all of these are great proxy goals to pursue (and maybe some are) but I personally think a few of them are terrible proxy goals for almost any situation and I can gaurantee that other people do too (some of which are probably on your team). Ultimately there are two problems with arguing for proxy goals:
(1) Proxy goals can become misaligned with your actual goals. (2) When you're trying to convince someone, you very rarely will know if they are aligned with your proxy goals. They're much more likely to be aligned with the team's or the company's actual goals though.
I've seen examples of all of these types of arguments for proxy goals (and made a couple of them myself) and though they can feel like shortcuts to a convincing argument, they really just make your job as a convincer much harder. First you have to convince somebody that Agile, for example, is a good goal, and then you have to convince them that your solution is indeed the most Agile. Usually they're just trying to get work done, so these unnecessary leaps of logic are extremely taxing on them. You're not going to win the hearts and minds this way. I've been through a few Agile transformations now, and the only successful one was the one where I never used the word "Agile" (It turns out that in general, jargon alienates people! Who would have thought?). Suggest real solutions to real problems in plain English and people will get behind you.
Certainly your customer and/or the company's stakeholders generally won't care about what you think is a best practice if it's not obviously changing actual results. I've personally seen attempts at many of those indirect goals I listed be both successful to one team's goals and detrimental to another's. When they're detrimental, you've blown all your social capital for future influence, so it's important to get them right. And any practice is hard to get right if you don't understand why.
Throwing out your "best practice" mindset and stopping solution-first thinking forces you to be working on solving actual problems. Solving actual problems gives you a lot of clout within your organization, and allows you to more easily push for more ideas in the future.