"Delayed Gratification" and "Patience" have a whole lot to do with each other and I've benefitted from both in many ways, especially on the job.

We recently had a huge problem where a 32 CPU/256GB RAM box running the Enterprise Edition of SQL Server saturated at about 85% average CPU.  I was working on determining what the root cause was (there were a ton of symptoms) but, in the mean time, they said they were going to throw hardware at it.  I was going to tell them that it wouldn't help and could make matters worse (which it did)  but I remember telling them that before (they wanted to be sure they had capacity, is the short story) and that they needed to fix some code.  They didn't fix the code.  So I did NOT tell them again that hardware wasn't going to fix it this time.  I didn't set them up for failure but I did give them the "opportunity to fail" instead of fighting them this time.

There were multiple benefits to doing so...
1.  They stopped asking me what the fix was while the hardware was being ordered and shipped.  That gave me 3 days to do a really deep dive (it was a very strange problem and turned out to be Entity Framework related connections that had MARS enabled).
2.  It gave me the opportunity to prove to them that when I said hardware wasn't the fix for what they perceived to be scalability problems and they did so by their own hand making the point even more convincing.
3.  I now have a 48 CPU/384 GB box that can handle just about anything provided that they write the right kind of code.
4.  They now know that I'm right about hardware and listen much more intently when I propose fixes to code and have made such fix recommendations an action priority.
5.  It also helped them change their minds a bit about changing from on-premise hardware to the cloud, which I don't actually want to do for multiple reasons.  The cloud isn't necessarily a bad idea to me... it's just a bad idea for the nature of our business.

As a DBA, one of my jobs is to help other people with their jobs but and as the saying goes... "A man forced against his will is of the same opinion still".  I'm frequently involved with new things/proposals and there have been several times where I tell them "If you do it that way, here are the problems that will occur and how to avoid them" and there have been several times where someone is passionate about the changes or new thing they want to make.  I've learned that when it gets to a certain point, more time will be spent arguing about it than (provided it will not cause harm to any data or the company) simply giving them the "opportunity to fail".  Again, I'm not saying that I set them up for failure.  I'll even help them with what they want to do as best as I honestly can because, remembering that "One good experiment is worth a thousand expert opinions", sometimes people need to fail to realize that someone else is right (and, yes... I include myself in that even when I think I'm right).

It's also a hard lesson for some people to learn.  They want to change (supposedly improve) something or do something new a different way and it looks like the same thing they tried previously and failed at, maybe a year or two ago.  I remind them of how it didn't work before.  The occasional (extremely rare lately) response is "Yeah, but this is different".  The "opportunity to fail" begins again but, no matter what happens, we're all going to learn from it as a team and to the benefit of the company we all work for.   😉