First, realize that change isn't an overnight process - it can take time to make the case for trying something new to your superiors. Second, try to understand (if possible) what motivations your team lead could have for being "stuck in their ways" - this can provide clues on the types of strategies you can use to help persuade them of your perspective.
Instigating a change often requires understanding the context or situation you're in, which is likely beyond the scope of this question. However, a good place to start is by reading Mary Lynn Manns and Linda Rising's book, Fearless Change: Patterns for Introducing New Ideas[1]. It provides a series of change event patterns that you can adopt/adapt for your purposes depending on the situation you find yourself within.
A key takeaway from the book is to keep your skeptics engaged - don't distance them from what you're doing, but also don't let them dissuade you from trying to bring about positive changes. Another is that when you start this process, be prepared for the long haul. It's a lot of two steps forward, three back.
Good luck!
[1] http://www.amazon.ca/Fearless-Change-Patterns-Introducing-Ideas/dp/0201741571
There are different approaches that work for different people based on your comfort and personality. I am highly uncomfortable confronting people. So I try to influence people to see the point over a period of time. BTW, you should probably read the book "Influence without Authority".
Most people respond well when you make problems to be about the company, and about learning/trying out new things, rather than about a person and their ways.
"Hey! I am keen to see how using a framework can help our product. I am looking at some great examples and their cited benefits, and was wondering if we could manage to shift towards using a framework over the next quarter. I know there is a lot on our plate, but I'd be glad to champion this effort. Won't let you down. What do you think?"
I've seen some people use "insult into action" methods as well - where you question someone casually(should not be seen as harmful) in a public situation. Like in front of the CTO, ask an innocent question "Hey TeamLead. Why can't we use XZY design pattern for this? Is there a reason we never use design patterns? I'm sure you have a reason and I'd love to understand."
Is your problem really that "our product doesn't use a framework"? Why is that an issue? What difference does it make?
Perhaps you feel that, using a framework, the team will be able to ship features faster, or get better performance, or higher code quality.
You'll be right. Sometimes. Frameworks have learning curves, and performance overhead, and maintenance costs. They're not always a positive gain.
And on the opposite side you see teams investing too much time on new tech, frameworks galore, instead of making progress to ship a working product.
As much as you feel your team leader is stuck in his ways, he may feel you're coming at him with a checklist of "hot shiny new tech" items you want to cross off, at the expense of delivering real value to customers.
So I suggest starting from the end, by looking at the outcome: are you building the right product? on time/budget? are customers happy? how's the quality?
And if the outcomes are off from where you expect them to be, start looking at what technology/people changes could help improve those outcomes.
Change for sake of change or new tech for its own sake isn't anything good.
But Seeing different aspects/qualities of same thing and not communicating it across is also no good.
Maybe you are above him/her. Make sure you both have noses in same direction, looking at same thing+aspect AND talking about it. Try to live in each other shoes. Commucate a lot. About the why's. Anyway, at the end, It's all your fault, and there is one tough managers choice - change People or Change people. Including you.
Or may be you're under him/her. Have a look at Organisational patterns book (James Coplien, Neil Harrison, http://www.amazon.com/exec/obidos/tg/detail/-/0131467409/). Find some really matching one and leave it "accidentally" by the printer. Yes, organisational, not technical. Technical may follow, later, as they are response/solution to something. Find/point out that something that needs being solved.
In any case check the "Resistance as a resource" (D.Emery, http://dhemery.com/articles/resistance_as_a_resource/)
and... be careful. Change can be .. demanding.
Do not go and tell him straight on his face that you feel he has taken a wrong turn. No leader wants to hear that. You can give him tips as to how using design patterns will help him out.
If you want to use this technique, you need classes that fulfil four basic roles. You already implement three of these four roles by following the dependency inversion principle. The service and the client are the two classes between which the dependency inversion principle intends to remove the dependency by introducing an interface. As you can see, dependency injection is a great fit for applications that follow the dependency inversion principle.
You can read more here: https://stackify.com/dependency-injection/
Besides if you do have any questions give me a call: https://clarity.fm/joy-brotonath
