I'm a Principal Engineer at a big tech company, so I think I fit your description. But I don't think the phrase "technical specialist" applies to me. From being

I'm a Principal Engineer at a big tech company, so I think I fit your description. But I don't think the phrase "technical specialist" applies to me. From being at a big tech company, I know of some technical specialists, that have an amazing depth of knowledge in one area. For me though, I got to where I am focusing more on knowing a little about a lot of things and being able to tie things together. In our company, Principal Engineers (PE's) have varying responsibilities, but they usually revolve around (1) reducing ambiguity in projects and (2) proactively looking out for technical challenges that can bite the team in the long run. That can mean a lot of different things. For me, it's mostly involved writing design documents to come up with strategies for solving problems (and all that's needed to do that, such as getting iterative feedback, doing deeper dives in particular areas, reading industry or academic research, talking to people who have knowledge in more specific areas) and writing code to tackle more challenging areas. These problems are usually ones that would span multiple development teams. The question of "transferability" that someone else brought up is interesting. At least in my career, I've jumped in to some pretty niche things that have proved in the end to be transferrable. The fact that I had experience managing a data science team before helped me get my 3rd job. A major factor in getting my 4th job came from the fact that in my 3rd job I had worked with Erlang. And my current role I got at least in part because of my experience at a telco startup. What I've found is that in any job, some stuff is completely dead-end knowledge (my domain knowledge about number porting will probably never be used again), some niche knowledge that might come up again (knowing how to do Bayesian probability analysis or write Erlang code), and some things that you'll apply over and over again (how to learn a new domain; how to work in an area where you are not an expert; how to understand customer needs; how to effectively communicate your ideas). In any case, even if you aren't managing people, as you advance as an individual contributor, mentoring and helping other people grow will still be a large part of your responsibilities. In our company, the senior individual contributors often advise managers on how to think about the performance of individuals.