Having been in software development for nearly 20 years, it really does depend on the manager, but I would say the preference is option A with very large asterisks. My ideal would be what I would consider "non-technical" manager in role and skills, but have perhaps had direct technical experience X years prior, minimally a solid working understanding of the development/engineering side of the house, even if he/she is not a coder.
I would much rather have a manager that understands the domain of the business and have some technical background/domain knowledge so that they understand the conversation mostly, than having one thinking they are "in charge" of the technical solution and team decisions. Nothing is more annoying than a technical manager to dictates down very specific architecture/stack/implementation decisions down to a technical team [specifically one of senior engineers, specialists, and trained architects]. Sure you can get this with both A & B, but B's trend more over-involved.
A non-technical manager, however, should come with other skills often missing in strictly "technical" ones... specifically the management/strategic ones. Too often you have a manager who was just a technical lead and jumped up to a management role without learning management, perhaps for salary/career development/etc. In these cases, even if they don't dominate the technical discussion as suggested above, they can lack key project/roadmap/strategic skills and experience which basically make them more of a "middle-man" than a manager.
A well-functioning development team or set of teams should more or less be able to make all the needed technical decisions and advise up to the manager and CTO-level roles not only what but why. The CTO and development-side management (again, I am arguing technical knowledgable, but non-tech) should be taking the expert advise from their developers and doing the big-picture strategic stuff. Likewise, they should be bring "problems" (feature ideas, needs that a customer or market is not being used, pain points, long term goals) to the developers for vetting, solution gathering, and implementation advise. As such there is a two way dialog. The management level gathers "outside" data and requirements and informs strategy and goals and the development team provides implementation, architecture, solution advise [or alternatives, as factors such as recurring costs or time to implement all play roles on the business end], and, well, the actual code/solution. The development team is able to focus on their domain/codebase/etc. without having to deal much with the "outside world."
Mind you, I am talking about manager and not "team lead". Leads should always be senior and know at least one software domain to an expert level [i.e. if a web application team, the lead can be front end, back end, or ops, but should know enough of all three domains, even if expert in only one]. Leads should still have a hand in code. Some orgs have leads to help bridge light management function and development expertise, but it depends on the org.
So going back to OPs experience, the non-technical manager is the one lacking. They should have more understanding of what the engineers are talking about.
I would much rather have a manager that understands the domain of the business and have some technical background/domain knowledge so that they understand the conversation mostly, than having one thinking they are "in charge" of the technical solution and team decisions. Nothing is more annoying than a technical manager to dictates down very specific architecture/stack/implementation decisions down to a technical team [specifically one of senior engineers, specialists, and trained architects]. Sure you can get this with both A & B, but B's trend more over-involved.
A non-technical manager, however, should come with other skills often missing in strictly "technical" ones... specifically the management/strategic ones. Too often you have a manager who was just a technical lead and jumped up to a management role without learning management, perhaps for salary/career development/etc. In these cases, even if they don't dominate the technical discussion as suggested above, they can lack key project/roadmap/strategic skills and experience which basically make them more of a "middle-man" than a manager.
A well-functioning development team or set of teams should more or less be able to make all the needed technical decisions and advise up to the manager and CTO-level roles not only what but why. The CTO and development-side management (again, I am arguing technical knowledgable, but non-tech) should be taking the expert advise from their developers and doing the big-picture strategic stuff. Likewise, they should be bring "problems" (feature ideas, needs that a customer or market is not being used, pain points, long term goals) to the developers for vetting, solution gathering, and implementation advise. As such there is a two way dialog. The management level gathers "outside" data and requirements and informs strategy and goals and the development team provides implementation, architecture, solution advise [or alternatives, as factors such as recurring costs or time to implement all play roles on the business end], and, well, the actual code/solution. The development team is able to focus on their domain/codebase/etc. without having to deal much with the "outside world."
Mind you, I am talking about manager and not "team lead". Leads should always be senior and know at least one software domain to an expert level [i.e. if a web application team, the lead can be front end, back end, or ops, but should know enough of all three domains, even if expert in only one]. Leads should still have a hand in code. Some orgs have leads to help bridge light management function and development expertise, but it depends on the org.
So going back to OPs experience, the non-technical manager is the one lacking. They should have more understanding of what the engineers are talking about.