And much of the "good" management I've encountered is actually about protecting your people from the bad management around and above you in the organization.
Many orgs tend to conflate technical leadership with people management and with project management, and they are different things.
> Many orgs tend to conflate technical leadership with people management and with project management, and they are different things.
The problem is that if you get a professional PM, they typically have seniority on the org chart and call the shots, even when they don't have the technical capacity to do so.
I'd like to experience an in team flat structure, one where management/PM is working for the team, not in charge of them.
All the really excellent PMs at Microsoft that I worked with seemed "flat" to me -- they did coordination, technical documentation and basically "glued together" disparate groups. They were technically deep and would have made fine engineers, except they were better at communication and negotiation than your average engineer. They didn't seem to give a damn what the management structure was like, except to steer around it.
The poorer PMs were the ones stuck in hierarchy, who managed schedules, tracked bug counts and (aside from bug triage maybe) did work that could have been largely automated. These folks tended to circulate through and were generally fungible, even at the nosebleed levels of their management tree.
I would happily have traded 20 or 30 of the "bug counter" PMs for a couple of technical PMs who could write specs that meant something. (I saw many "bug counter" PMs quit, or get fired).
Many orgs tend to conflate technical leadership with people management and with project management, and they are different things.