One thing to keep in mind is that there is a difference between a metric and measure. A measure is basically exactly what it says on the box: it's something that you have measured. A metric is a measure that you use to drive process changes.
LOC is a good measure, but a truly terrible metric. The reason it is a terrible metric is because it easily gamed (both consciously and unconsciously). The same functionality can be implemented in 1 line or 100 lines. The amount of time it takes to write 1 line can be more than the amount of time it takes to write 100 lines. You get the point.
LOC can, however, be a good measure. You can test this yourself if you like. Go through an old project (something with a year's worth of code). Make a list of all the features that were implemented in that year. Estimate the amount of work for each feature (or use whatever estimates you had before). Make a rolling average of "amount of work" over each week. Now go into your code repository and make a rolling average for the number of lines of code changed each week (so basically just add the lines added to the lines deleted).
I think you will find that there is a correlation between the average estimated effort and the average change in LOC every week. This is because over the life of a project, developers tend to use the same kinds of techniques, the same idioms, etc.
Occasionally, you will find that the relationship between estimated effort and LOC changes dramatically. In my experience, you will discover that this corresponds with a change in development mentality. Something has happened on the team that changes the way they write code.
So it's a good measure for that kind of thing. For example, I once had to deal with political problems from upper management where they were convinced that the programmers were not focusing on their job. I could show them very easily from graphs of estimated effort and lines of code that it was very much business as usual.
All this to say that if your team lead is encouraging you to increase your number of lines of code out the door, then it is indeed a flawed metric. But if the team lead is measuring productivity with lines of code, it may very well be a decent measure. You can't use it to affect productivity, but you can use it for other purposes.