Just building on the who and why idea ... as a technical manager an important aspect of your job is use your technical aptitude to help your non technical peers clarify business ideas related to, possibly, technical problems. Once problems are clarified, it should be clear whether they are technical or not. At that point you then need to advise at the proper level of abstraction on cost, timelines, possible solution benefits and shortcomings.
Lets think about clarifying business ideas. Non technical people are familiar with issues in their business areas, but they may not be able to clearly describe the issue or identify root causes. Your job as a managerial level engineer may be to interpret a vague understanding that something is not as they want, into statement that can be evaluated as a engineering problem. You may in that interpretation process find that the problem at hand is not a technical problem or that there may be effective non technical means to solve it. Remember that people you are dealing with have developed very different skills to address issues in their businesses areas, and engineering style problem definition is likely not one of those skills. For example, a typical sales manager might deal with sales issues by getting a lot of people in a room, generating visibility, enthusiasm and consensus. He may see that as the way to solve engineering issues as well. Just as you may not have developed the skills to generate institutional momentum and enthusiasm, others may not have the developed the skills to approach problems with engineering perspective. Your value comes from doing that transformation for them and then communicating it to them in terms of their skill set.
Take an example, suppose a peer tells you that it is a problem that you do not "talk like a leader". What does he mean by a leader? I have heard hundreds of definitions of what a leader should be over the years. He is trying to express a mismatch between your managerial execution and his ideal, but I'm not sure if leader is the exact word he wants to express that mismatch. Which of my hundreds of "leader" definitions would most closely match his primary complaint about your execution style? Lets go a step backwards to "dont talk like an engineer". I suspect this statement is getting to the source of his primary complaint so lets investigate this statement.
I mentioned above that you need to advise at the proper level of abstraction and in terms of other peoples skill sets. If you are in a managerial meeting about a new product X and you start talking about Ruby on Rails vs Django or using C++ vs Rust, then you are talking at the wrong level of abstraction. The business does not care if X is Ruby on Rails or Django. They care about whether its a good technical idea. Should they put resources into X? How much will X cost? How long will X take to create? And most importantly how well X might or might not solve the well defined problem you clearly communicate? If you have ever talked technical details in a meeting, then you are talking like an engineer, and your talk is irrelevant to their concerns. Conversely, if you are ever in a meeting, and a peer manager suggests they really need a Y implemented to solve their problem Z, then your job is not to give them cost and timeline information on Y. Your job is to understand that your peer manager might, himself, be operating at the wrong level of abstraction. Y might the the solution to his problem, but maybe he would be better off with a different technical solution. Or maybe he needs to see the problem in a slightly different light.
I cant be sure, but I suspect that you dont have to change perspective and become a leader. Your perspective probably has a great deal of value to your company but you are just not presenting that perspective in a way your peers find maximally useful.