I do think when the team is more technical than the manager, he has to coach the team to communicate the useful information to him. It’s his job to be able to synthesize information and to ask questions that make the team think outside the scope of their work, try to find or tease out any gotchas. Lastly a manager should be aware of the impacts their teams work will have on others and intervene when he thinks something might go wrong.
It’s always positive when the manager has a very technical background or deep knowledge of the tech stack, but they should be aware of micro managing.
Ran into a lot of situations like this:
The other common issue was that the non-technicals didn't grasp the need for absolutes and specificity. One common issue revolved around dates.
So we would get a ticket that "such and such permission should expire at a reasonable time on the date specified." Reasonable time was not defined and it turned out to be whenever the particular thing closed.
They would also forgot to list exceptions to that expiration policy, which the people doing it manually would have seen on the post-its this system replaced.
That usually either gives the implementor enough information to wholeheartedly agree with the proposed solution, or to suggest something more appropriate.
If the project is a smaller one, then the developer is supposed to be acting in an analyst-developer type role. In my fairly limited experience the analyst part tends to take a back seat in these smaller projects.
I believe, though people are free to disagree, that it’s on the people developing the solution to ensure it satisfies the users needs. If the user is jumping to a solution, then it’s up to the team to take a step back and ensure the problem has been satisfactorily defined.
Note: I work on internal business apps used in a large corporation, and I have never worked on consumer facing apps.
If a manager starts analyzing the technical information in front of them without the background to do so, they are missing the point. They should rely on the opinion of their more technical counterparts when the information is technical.
Yet, the opposite is also true, if a technical background person becomes manager and doesn't trust their accounting, finance, marketing counter part, then they wouldn't be a very good manager either.
The above assumes that the manager has a more general role and that decisions on technical topics isn't their only job. If yes, of course a technical background should be required.
The interesting parts start to pop up when you need to make difficult choices. Good managers with a technical background are scarce and therefore not usually available. Sometimes you need to make a choice between a bad manager with a technical background, a good manager without a technical background and no manager at all. Whichever choice is made, it will never satisfy everyone.
Both the people part _AND_ the technical parts are the hard parts of technical management.
Of course some domain knowledge is needed.
My anecdotal experience with manager is either : they are useless and will rubber stamps things. Or they are actually involved, then, you want someone that has a vague idea of the process of doing the work. I vastly prefer someone who has produced code at some point. It’s fine if it was 10 years ago the last time it happen.
It's easy to say that something that seems simple when explained in simple terms is easy or quick to implement, but the people 'at the coal face' are often all too aware of the implicit complications of the task.
They need to build and facilitate a team to be run by itself and arbitrate on difficult decisions, sell team, etc, etc.
Also, you’re going to be manipulated and hoodwinked by the managers around you who are technical.
Lastly, the engineers you’re managing are going to laugh at you behind your back.
I’ve seen all of this happen before.