I've been a team lead before and I know the rules of normalization very well, so I'll interject here.
I've already tried to explain to him that it is easier for me to work with a normalized structure, but somehow I failed to convince him.
Academics of normalization
When you say normalized, exactly which normalization level / standard is right? 2nd normal form? 3rd normal form? Boyce–Codd normal form? 6th normal form?
There are a lot of levels of normalization, each with increasing complexity of rules: https://en.wikipedia.org/wiki/Database_normalization
So by saying that X is better than Y because normalization is good, you are implying a single, unambiguous rule of what is right.
Analysis of normalization and tradeoffs
We normalize primarily to optimize write performance and guarantee data consistency.
Look at this page about GitHub database performance: https://johnnunemaker.com/database-performance-simplified/
Notice how the "how to optimize writes" recommendations are the inverse of the "how to optimize reads" recommendations? This is a general pattern you will find. There exists a tradeoff between read performance and write performance.
The specific normalization condition you are describing is to split a table into 3 tables. Let's assume it's not 1:1 and so some of the tables have a smaller row count and you've reduced the storage footprint. That means that updates to that data set may be more efficient. Now how do you read the data set? By joining 3 tables. Joining requires looking at 3 tables instead of 1, so it will be more expensive.
You've optimized writes at the expense of reads.
In a past role, we found that almost every important query joined in a single particular table just to find a single value. 10% of the cost of most queries was joining to this one table. It was not being used to filter. So duplicating that column (which would never change) onto a few frequently queried tables improved performance by 10% across the board. It was a thoughtful, deliberate decision done by people who knew what they were doing.
Back to your example. If you split that table into 3 tables with a 1:1 relationship, then you always have at least the same number of rows to update, so there is no benefit in terms of writes, but now reads have to join 3 tables. So you're taking a performance cost without a benefit.
Some data is written far more often than it is read. Some data is read far more often than it is written. Since we have a tradeoff between read efficiency and write efficiency, we should optimize for the situation that matches our usage patterns.
Given that you're new to the company, your team lead probably knows more about how this data is used than you do.
So: How can I convince my teamleader that another data structure would be better?
The fact that you didn't bring this to stackoverflow or the DBA Stack Exchange and ended your question with asking how to convince someone you're right shows that you haven't considered your team lead may actually be right.
Next time, you should approach a disagreement by asking him to explain his concerns and then if you still don't agree, go to stackoverflow.com or dba.stackexchange.com and ask someone to explain the technical merits to you. You should try to see disagreements as a learning opportunity rather than opportunities to force your will on others. Especially when you're new and surrounded by people more knowledgable than yourself.