staff and principal engineerings are still leaders who spend an awful lot of their time coaching and mentoring, they probably just don't have direct people management responsibilities. There are very few situations that will give you an advanced IC title for doing stuff that "no one else can do" because of one word: leverage. It's not economic (in all but the rarest, most specialize cases) for me to say "I want 10x developers who are snowflakes" vs. "I want my senior engineers to increase their sphere of influence and make every developer fractionally better". It's very hard for a senior developer to increase their skills 10% YoY, but actually pretty easy for them to help 20+ developers get 1% better. Staff and Principal developers go deep on the leadership aspects (I shudder to say architecture, but it is the "good" parts of this) and very, very wide on their application & influence. As a result the opportunities for deep engineering work are more like mining than farming.
I manage 2 core teams, one a "platform" team made up of all senior => principal engineers, and they spend a lot of their time shepparding other less experienced teams while trying to answer very tough, vague questions like "what bottlenecks do we predict at 10x scale? What can we opportunistically do today?". No one gets huge, dedicated time blocks to code without some degree of accountability and expectation.
I manage 2 core teams, one a "platform" team made up of all senior => principal engineers, and they spend a lot of their time shepparding other less experienced teams while trying to answer very tough, vague questions like "what bottlenecks do we predict at 10x scale? What can we opportunistically do today?". No one gets huge, dedicated time blocks to code without some degree of accountability and expectation.