Treat your question as an exercise in user research. This time, the users who you are researching are your own development team. How and where do decisions get made? Who is influential in making those decisions? How do they communicate? What are the competing priorities? How does work actually get done?
Once you have a better understanding of your audience, you can tailor your approach. If the team communicates through their bug-tracker to capture work items, then you need to learn how to use that bug-tracker for UX work. If there's one person whose disapproval, or even noncommittal attitude, will result in nothing happening, then you need to get them on board. If there's one person who only cares about a single topic, you need to figure out how to talk about your work in terms of their single topic. If there's a leader who only seems to communicate via PowerPoint, you need to capture your ideas in a PowerPoint deck that they're going to love. If there's someone who only cares about something quantifiable, then you need to discuss your results in terms of something quantifiable. It's worthwhile noting that quantifiable is not just in terms of income from your product, but also in terms of developer productivity. If you can show that doing something one way is faster or easier to implement, or has a lower maintenance cost, that is an excellent argument to those who only want to hear about it if it's quantifiable.
Most importantly, it's not sufficient to only do this for one person or team, and it's not sufficient to do this a single time. It's not one-and-done. You need to be engaged with the team throughout the development cycle. You could do an amazing job up-front and get people on board, but disengage and learn later that they cut your work because there was no one there to represent it. Staying engaged helps you understand the team's constraints, and to work with them to come up with compromises that will make UX improvements in the short-term while still working towards the UX that will make the most improvement for your users in a future release. Staying engaged also means that you have the opportunity to represent users in discussions with them, and you might find that you can answer questions that they have or provide design direction for them without having to do a lot of additional work. Being involved makes you a better member of the team, and a more respected member of the team, which ultimately results in delivering a better user experience.
It's your job to own the user experience. Don't complete a design, or deliver a research report, and let that be the end of it. The best user experience is the one that actually gets delivered. The difference between a good designer/researcher and a great designer/researcher is the one who knows how to work with a team to make real improvements to the user experience.