Sounds like some of your coworkers thought an EM role was [a lead developer], which it is not. As a manager, being an IC leads to a bunch of structural problems with the code and therefore the team.
Even if you make it a separate track, it's hard to define what the promotion looks like for more senior engineers, especially at successful companies. When you have $2M of cash in the bank thanks to stock, does a 10% pay bump from senior to staff matter? Does the title bump matter? How can you reward a long-standing successful senior engineer in a way that seems meaningful?
This isn't a question I have an answer to, but "make them a manager" is definitely the wrong one. The majority of my managers have told me how jealous they are that I get to code all day. More than one has told me straight up they do not want to manage. I've watched several teams implode under managers like that.
I think it's completely valid to not want to manage. Hopefully your lead doesn't pressure you to take such a role in the future. But have you thought about what success would look like in your career otherwise?
It is also valid to not be particularly ambitious, to enjoy the craft of software engineering until you retire, and spend the mental energy you would spend on getting promoted on hobbies, family, advocacy, or whatever else brings value to your life... though it can be hard for those of us who are more ambitious to realize that.
I had a boss who was being weird about making me a lead for the first time. I needed him to make it official, not fret the title. I told him I didn’t care what he called me as long as people did what I asked them to do.
If you want to stay an IC, I can not recommend loudly enough that you learn to manage your finances and your consumption. Managing your “needs” makes your savings last longer. Getting a raise just lets you build your savings faster, which might not be the same (especially since your needs will be inflation adjusted but your savings will not).
It’s harder to maintain the courage of your convictions when you are in debt than when you are doing okay.
If someone makes you work for a promotion, they are manipulating you. That could be good (in a mentor) or bad (in a labor exploiter). But you are being manipulated, and it’s better if it’s really your choice, not your mortgage or your kids’ braces.
I initially didn't care about titles, but they do constrain what work you can do. The reality is that if your title is one of an individual contributor, even if you lead culture change at the company level, they will always look for the code. If they don't find it, you will be in trouble.
One thing I have learned over the last year of my life is that being "Shadow lead" - the one actually pulling the strings and making things happen, with no formal title/recognition - is the worst spot to be in. The work you are doing doesn't match what you should be doing on paper, so you are very vulnerable if somebody decides to take a closer look.
It's "glue work" but on a larger scale. It's important, but will go unrecognized. It's emotionally exhausting to build a team and get a head pat and told someone else will lead that now, thanks, and by the way how much code did you write recently?
Though I do wonder what you mean by "official" but without the title. It might be the case that "everybody knows" what you do, but if your lead is replaced or just changes their attitude, suddenly your IC work is under the microscope, and could be found lacking.
If the software team is of a medium size, let's say, less than 50 people, then it surely isn't how you paint.
The CTO / Manager(s) for sure know the impact of the ICs and likely nobody is measured by LoCs. I personally have never worked in an organization (10 companies and counting) where LoC has ever been mentioned as something being measured.
Though that was the stupidest way to come to that conclusion, it is true that I was doing less IC work than other members of my team. I had surfaced this several times in 1:1s and thought that was what he expected. For instance, some weeks I had literally 20 hours of meetings, with significant overhead attached to those; it is hard to make much progress coding in that environment.