Let’s have no managers, instead of managers with no engineering experience

A. Engineering Management shouldn't micromanage, but a manager can be invaluable in helping resolve interpersonal conflicts and escalate issues. They can be the "bad guy" when dealing with someone the team reports is consistently underperforming or engaging in poor behavior.

B. Are you an engineer or a technician. An engineer "just" creates fixes. A technician will implement it. Lines blur in programming more than other fields, but some "engineers" make a big deal out of just figuring out solutions that have been solved many times before, like making a backend call.

This is my perspective as an engineer.

He might have a point if a simple API-change impacts 170 test cases. This sounds suspiciously like "no functional tests but let's go for 100% coverage with unit tests" - not necessarily the efficient thing to do, from a management perspective.

>But where they single handedly derail a project due to micro-managing and over simplifying developers’ implementation concerns.

All my managers have been engineers in the past. And over half of them fit this description.

I don't want to downplay the benefit of having some domain knowledge, but the problems described are not a symptom of not having engineering experience. Management requires a good amount of nontechnical skills, and too often a high performing engineer is picked for becoming a manager, with no training whatsoever.

There’s a balance. A group run by clueless managers is bad. Equally through a group run entirely by engineers that don’t think about or consider anything other than their engineering concerns is bad too.

A good manager knows how to find the balance between “what engineering wants” and “what everyone else wants” and gets the best outcome. The best managers don’t need to be expert engineers themselves but they know enough to have a good BS detector and enough to make decent decisions.

While I agree that it helps for a manager to have experience doing what they are managing, I would frame it differently. I've experienced poor engineering managers with engineering experience and good engineering managers with none, to the point that I've developed a more nuanced opinion about what makes a good (engineering) manager.

Great managers can manage things they don't understand and probably never will -- their role does not require domain expertise. I would argue that the hallmark of a poor manager is that they can't manage unless they are a domain expert, which they often use as a crutch to overcome lack of basic management skill. One of the greatest failure modes for software engineering managers with engineering backgrounds is the assumption that they can or will understand every part of the design they are managing. Not only is this unlikely in many cases but this delusion encourages them to dictate elements of engineering design that they are not intimately familiar with, invariably to the annoyance of the engineers that are tasked with doing the work and may have far more technical skill than the manager on the task at hand. For mundane software projects, an engineering manager with an engineering background may legitimately have the domain expertise, which is why it still gets things done despite being suboptimal for everyone.

This is really brought to light when doing complex, high-end software system engineering. In these cases my experience is that most experienced engineering managers with engineering backgrounds fail; because it is impossible to understand what your team does at a technical level, you can't lean on that. It is often difficult for very experienced engineers, now managers, to come to terms with the idea that someone working on "their" project has technical skills that they can't master or at least understand with a 15 minute explanation and a couple hours of research. Engineering managers, especially ones that were previously great engineers, must resist the instinct to technically master everything under their purview -- it doesn't scale. The advantage of non-engineering managers in these environments is that their management style doesn't rely on the assumption that they can technically master any part of the project, so they don't even try.

A big part of being a good engineering manager is letting go of what made you a great engineer. It isn't an easy thing to do.