As a manager, you can either lead great devs on a 6-person-month project, or you can remove the good devs and turn that into a 36-person-month project. In the former, you're going to be seen by your peers and upper management and somebody who had an easy task but can't control your unruly employees who keep strange hours and don't follow the dress code. In the latter, you're going to be seen as somebody who successfully managed a very complex project with a large staff, impressively inspiring the employees to mass amounts of unpaid overtime.
The path to success for management lies in controlling larger staffs and larger budgets. Good development just gets in the way.
I remember one of my first forays into management. It was a small team full of really good developers. We delivered ahead of schedule and way under budget. I remember thinking "this sucks, I'm not really DOING anything. I'm just letting these guys go out and kill it and keeping everything out of the way. This isn't going to end well for me".
It was the opposite. My boss was pleased as punch that we came in way under budget and ahead of schedule. The complexity (or lack of) didn't really seem to even show up on his radar.
Because this is supposed to be the job of a good manager. Not bossing people around, but abstracting away and isolating things irrelevant to their tasks.
Congratulations on your success!
This is sick and this is exactly the problem with the manager mentioned in the SE question. The manager should not focus on controlling staff, but on controlling the workplace environment so that developers can focus on building the product, and not on in-office politics, dealing with angry customers, faulty equipment, etc. The role of manager should be one of a servant, not of a boss. Some other terms for that: "shit umbrella" and "developer abstraction layer".
One thing I've learned on the employer/employee side of development (that was initially painful, but now just seems obvious) is that for most software projects as long as the goal is well defined and meets some need in some market as well as expected, all they do need is mediocrity. And I mean this is the sincerest way, not the "fuck them for thinking this" way, but the "they are right to think this" way.
You could be a 10X (or whatever shorthand you want to use for 'very good') developer compared to everyone else on the team and you might feel yourself being Harrison Bergeroned by process, tools and management designed to pull everyone toward the middle and when you quit you'll think "Now they'll see what they are missing", but then you find out they could in fact easily replace you with mediocrity and nobody would notice and the project could even go on to be financially successful if everything else falls into place.
I highly encourage all developers to maximize their talent and ability and always keep learning, but at the end of the day the results I see in the real world (on both ends -- mediocre developers becoming wildly successful and extremely talented developers who don't do nearly as well financially) are that the correlation between pure talent/skill and their financial/career success relative to other developers is fairly loose.