You are identifying and acknowledging some limitations, which as others have said, is a great first step. I have also followed a similar path to you, and moved into a management role a while back. I've put together a few thoughts and my attempts at keeping this comment short hasn't been successful, nevertheless, I hope it helps you in some way.
One of the things that helped me greatly was recalling behaviours of managers that I thought highly of and emulating them, as well as thinking about poor management practices I have been on the receiving end of and making sure that it doesn't happen again. The idea of this exercise is for you to have a clear vision of who you want to be as a manager. This can be as shallow as how you want to be perceived, or go as deep as how you want to act every day.
Once you understand the type of manager you want to be, you can now decide how you want to evolve that idea of yourself based on your experiences and everything you learn. How you communicate your growth as a manager is also something that you should consider. I have worked with management lecturers that advocated authentic leadership, and it is something I try to live by.
Being an authentic leader for me meant being honest with my team when I don't know something, when I'm wrong, and when I'm making a serious attempt to change how I operate as a manager. As an additional consideration though, I manager I respect gave me the advise that such actions can be seen as weakness by other managers and used against me; I made a conscious decision to continue the practice, but you need to decide whether your environment will be receptive to how you want to operate.
This leads to one of the first points you raised, where you wrote "I'm having a hard time with the manager role transition as I enjoy getting my hands dirty and diving in to solve problems." I think it's important to understand that as a manager, you no longer have a single responsibility/obligation to the manager you are reporting to. As a manager your dual responsibilities are to ensure your team are working optimally whilst making sure your manager and the greater organisation know about it. I cannot stress enough that this is more than a full time job.
What changed my perspective about meetings is the following thought - do I want my most productive team members to be in meetings, or do I want to be the filter that ensures only the most useful information goes through. Being a filter can take many forms. It may mean sitting in on exploratory meetings to determine how serious the organisation is about a new task/project, and throwing in a business analyst to further test the waters. Or it may mean immediately pulling your top engineer of their current task to help the company with an incident.
In regards to your comment about "knowing how much information to provide, how much to expect", I think it's best to discuss this with your team. I tend to have a general rule that if I can't imagine myself developing a solution based on the knowledge I have about the problem, then I need to continue dialogue with stakeholders before shifting the focus of my team. Although as you mentioned, being hands-off means you become detached to the realities (read challenges) of implementing working solutions in your environment. This is why I would recommend identifying a technical lead that is basically your 2IC and someone that keeps you technically grounded.
To shorten this comment, I will just conclude by saying that my view of management is that you can still play either a developer, or administrator role, but the system you are working on is the system of organisation that makes up your company, rather than code and servers. As a developer it means you are constantly looking for ways to improve products, ensuring people with the right skills are being utilised or promoted so that they can contribute towards outcomes that benefit all. As an administrator, your role will be to ensure business continuity, by ensuring knowledge is passed on and successions can occur with minimal disruption. All principles that apply to building and maintaining scalable systems all apply to your company, such as redundancy, reliability, efficiency, etc.
My final bit of advice is that you should be honest with yourself about whether the role is right for you. I've seen some people take to management like a new lease on life, while myself I have gone back to a development role with desires of being no more than technical lead or a technical founder, which is a completely different goal altogether.