> My understanding of management is of owning a summarized,
> superset overview of a bunch of areas that I'm (ostensibly)
> coordinating.
I would most definitely agree with you. A manager doesn't need to have more "in the trenches" knowledge than those that report to them. In fact that's probably not even possible or even desirable. Most of my really good managers have been less technical than me.
> Hmm. I certainly don't want to end in the position
> of the manager you're referring to. I'm scared
> about/by the quantity of things I don't know, though,
> across the board, so there's that. (One of those things
> that are hard to sum up as good or bad, heh.)
If you're concerned about it, that's probably an excellent sign that you'll do what it takes not to fall into that trap.
Actually I'll be really specific about the trap our manager fell into. It's SUPER avoidable. Here's what he did:
1. He or his management would present a problem or challenge
2. He would design a solution with his very incomplete knowledge, down to the technical details
3. He would break it up into tasks
4. He would assign those tasks to us
You can see the problem there. The people with the actual in-the-trenches knowledge were completely shut out of the design process and his solutions were often terrible.
Furthermore, WE were the ones made to look bad by this process. HIS management thought he was this uber-competant guy who could not only manage but architect solutions as well! And even break them up into little bite-sized chunks for the engineers to execute!
And WE looked like "negative nancies" who were like, slowing him down by pushing back against these solutions and tasks he handed out. He was like a poor general who was always getting his troops killed, that managed to convince the higher-ups that he was just constantly given bad troops or something.
His favorite retort was "well, what's your suggestion?" when we challenged his poorly thought-out solutions. And it was like... I don't know, Ben. I just got handed your shitty solution five seconds ago and you still haven't even told us what you're even trying to accomplish here. We haven't had three hours or three days or three weeks to come up ideas like you have.
Obviously, the process ought to have gone like this:
1. He or his management would present a problem or challenge
2. He should present the problem to his team, explaining the technical goals as well as how those goals fit into the big picture of the business
3. The team collectively should have designed and discussed possible solutions.
4a. Through that process he should have acted as advisor and sounding board. He should have recognized our greater domain knowledge.
4b. Of course, that street goes both ways. He should have recognized our greater experience and domain knowledge, but we should have also recognized the need for to prove the viability of our solutions to him before implementing them, just like we'd do with any manager regardless of relative age or experience -- the relationship would not work if we expected him to simply "take our word for it" because we we older or more experienced.