I've never really seen 'separate but equal' career tracks be true. The manager track is always better compensated and has more say in the direction of the business.
IMO - talking with people makes both parties feel better but is overrated for affecting change. A better way to manage and grow talent is to put people in a position to succeed. This involves giving the right tasks to the right people, removing obstacles and distractions, understanding when and how to prioritize production(product stories) vs productivity (i.e tooling, infrastructure, and tech debt). None of this happens in 1:1s. You need to intimately understand your developer lifecycle and how your engineers are getting blocked or where they're wasting their time and how to go about fixing that. Even though they're often mediocre communicators an engineer-manager is better at making those decisions.
I think the difference in compensation is inevitable in the free market. To command respect from engineers, you have to be a good engineer yourself and have to be smart and have a lot of technical depth. Among this set of people, it is very hard to find people who are also good at managing people. I think great engineering managers are genuinely rarer than great developers, and consequently, they will be better paid.
The infuriating part is that Taylorist management dogma has made the average (likely mediocre) manager better compensated than the average engineer despite most being demonstrably lower skilled at management than an individual contributor of similar years of experience.
This pushes even middle management roles into a more sales-like personality set of people that are money-motivated to a larger degree than is perhaps healthy for the needs of the role. Upper management does need a sales angle to a degree but your usual engineering manager is not being focused appropriately if they have to "sell" the needs of their department - the prioritization for different departments are better done in committee fashion transparent across managers rather than one-on-one back room dealings that a lot of situations turn into when we talk about "managers should be enabling and removing barriers." Political in-fighting among managers is negative value to any compan - it's a civil war in effect. Some companies resemble the economic output of war-torn nations almost as a result.
In the job I just left, management couldn't remove the most important barriers at all - the biggest cost savings that every competent company could do easily would always be the last thing possible. Meanwhile, most management directives boiled down to "do more with less than is healthy... and don't burn people out!"
When you have managerial dilemmas, something will be dropped. Work just plain won't get done, deals won't be made, costs will overrun, or people will burn out and leave. Your company culture is what will determine what to sacrifice.
You need to talk to your people a lot, in order for them to get comfortable talking to you. 95% of the time, you're just shooting the shit. But 5% of the time, they'll have some critical information. Conversely, if you don't talk to your people, they won't volunteer this info out of the blue. You have to lay the ground work first.
One of the decisions to make in choosing a management career track or not is if you want to eventually have more say over the business - what your team works on - or more say over how it's done - how the team engineers things. Someone in an architect-role can have a lot of say over the latter that upper-mid-management won't (and even a CTO type who could impose decisions on that generally shouldn't be, they're too far away from the code).
I'm wondering how this works in a self organizing team. If people are taking tasks that aren't their strong suit, what can you do as a manager? Hand select stories?
We currently do that, partially because many of our team are newer to the company, but also because we think we can choose fairly well, since our team is somewhat splintered in our products (iOS in obj-c, android in Java, the rest in js).
It's possible to give the final say on task selection to the programmers while still allowing the manager to have useful input. Instead of bossing people around, the manager just offers their opinion, and the rest of the team respect it as being from a position of oversight. And if they really disagree, they can explain their reasons and the manager is better informed in future.
Self organizing teams only work well with the right sort of people. If your team is dividing up tasks in weird ways and for strange reasons they they need mentoring, a bad apple pared or are not actually capable of being a self organizing team.
IMO - talking with people makes both parties feel better but is overrated for affecting change. A better way to manage and grow talent is to put people in a position to succeed. This involves giving the right tasks to the right people, removing obstacles and distractions, understanding when and how to prioritize production(product stories) vs productivity (i.e tooling, infrastructure, and tech debt). None of this happens in 1:1s. You need to intimately understand your developer lifecycle and how your engineers are getting blocked or where they're wasting their time and how to go about fixing that. Even though they're often mediocre communicators an engineer-manager is better at making those decisions.