Yep, you just identified the whole trick.

Takes awhile to get a hang of it. You've already picked up on a couple of the harder challenges, and are aware of your own short comings in these regards: that puts you ahead of 80% of managers! Now try every day to get better. Buy some books, read some websites, and now you are on the manager journey.

Best managers I know, find talent and grow it. So delegate, train, motivate. Strait shooting is better then being passive aggressive or allowing people to fail. Feels worse up front sometimes, but better for all concerned. Can't tell you how many times I've had a dialog in my own head about an under performing employee then eventually confronted them and they said "Oh, that's what you want me to do, sure." And then, by god, they went and did it. Be repetitive. Be helpful to others in the org. Margret Thatcher famously said "Everybody brings me problems, he brings me solutions." Be that guy. .... point is there is a million things like this shit.

I would start by kicking off the process of codifying your knowledge. I've used confluence for this, and it's a real art to sit down and work out how to structure your information, the level of detail required, and what should be documented in the first place. I've found that the people I've worked with the went from a technical to managerial role were mostly relied on for that vast technical and organisational knowledge that they had built up over the years.

I'm not sure if you're managing a project, product or divisional team structure, but I would say that no matter what level you're attempting to manage, set some sort of vision for your team to align themselves with. This can cover things such as technical aspirations, or organisational strategic goals.

Trust your team. It doesn't sound like there is any mistrust in your team, but I understand the difficulty in getting over that initial knowledge hump when introducing people to a new domain, especially as an "expert" in the area. Documenting knowledge in clear and concise ways, and making different members of your team experts in certain areas of your knowledge will help them to become more self-sufficient in their quest for knowledge and answers. Consider this an investment.

As a general piece of advice, not aimed at any particular part of your post, you were in the same position as your team members are now not long ago, think about the pain points you had and try to learn from them.

Read this: https://www.nczonline.net/blog/2013/10/15/the-best-career-ad...

I took to heart one sentence from this blog post in particular: "I made sure I only went to meetings that needed me to participate and then I would participate." IE, if you aren't useful to the meeting in a major way, then don't go. That will likely free you up for other things.

Here's a perspective from having progressed into management from technical roles, managing engineers and now back to doing engineering.

My employees used to call me 'meeting attender' since that was what they saw me do day-to-day. That was a big part of it - attending meetings with other teams, departments, etc. that want work done. Then prioritizing that work, and figuring out who on the team can get it done. Distilling large bodies of work into smaller chunks is key, but leave room for implementation details to be decided by your team.

The delegation aspect is most important when transitioning. Setup a feedback loop after assigning work that is short enough to make sure an employee is on the path towards completion but not too short that you are micro-managing. Get out of their way and let them do work.

Your best bet for staying hands on is to pick tasks nobody wants to do that are not on a critical timeline (probably the opposite of what you are thinking right now). Your role's primary contribution is organizing and managing work, building relationships with other teams and your customers (internal or otherwise).

Managing engineers is a different job than engineering. Once you get a handle on delegation, coaching your team comes into play (which helps with delegation later).

I strongly recommend you join the Rands leadership Slack: http://randsinrepose.com/welcome-to-rands-leadership-slack/ where you'll find (and hopefully contribute to) a motherlode of goodness and peer advice.

This question comes up fairly regularly on HN. Here are a couple of old discussions that have some interesting perspectives:

- What are common mistakes that new or inexperienced managers make?

https://news.ycombinator.com/item?id=7769240

- What do technical managers do, anyway?

https://news.ycombinator.com/item?id=5096734

Here's a comment I made a few years ago in the "common mistakes" thread, which I still think is true:

https://news.ycombinator.com/item?id=7770321

One rule to remember is that your time is more valuable than any of the people working for you. So any task that you are doing that could be done by someone in your team should be delegated to the team. Spend your time doing what only you can do. Such as setting priorities, making big calls on the technology for future projects and so forth.

I would also recommend that meeting your team members once per week is about right. More than that and your starting to micro manage and you remember as an engineer how annoying that is. More than a week and things can go too far off track before you can pull it back into line again.

The statement is an issue with me, it implies that managers are not workers themselves.

Further, becoming a manager just because of age is the wrong approach. There is nothing wrong with being a senior engineer (in both age and experience!).

However, i'd thoroughly recommend reading up about servitude management. That is where the raison d'être for management is to enable engineers to be able to do their job. I really respect that model.

I highly recommend taking courses at Harrison Metal. The general management class is 3 days from 10-2pm and they have great electives as well.

I spent some number of years as a consultant helping startup founders do exactly that, and would be happy to chat directly about your situation -- email is in the profile if you're interested.

In terms of general must-have knowledge, I recommend reading "Drive" by Dan Pink, "Tribal Leadership" by Dave Logan, and "How To Make Sense Of Any Mess" by Abby Covert.

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.