I bet you read "Training, training training" and thought "yeah, but I'm pretty good. I'll skip that bit." Do not underestimate the differences between being an

I bet you read "Training, training training" and thought "yeah, but I'm pretty good. I'll skip that bit." Do not underestimate the differences between being an effective individual contributor and an effective engineering manager. A lot of the concepts a good manager is driven by are counter-intuitive. For example, technical "leadership" as a manager can be repellant, especially to the more senior of your team, and interpreted as evidence of lack of trust. The political environment of the company will also dictate your success. Half your job is to be the team coach/servant. The other half is making sure the rest of the company understands that what your team is doing is high-value (and making sure that actually is true). The OP asked "what skill-sets from earlier were important in the transition." Surprisingly little. One of the team's biggest jobs (which you should try to delegate, by the way), is breaking down a problem into smaller, doable chunks. You'll have done this on smaller scales as a coder, and finding reasonable separations of concern can make or break projects. At the same time, you shouldn't be doing all this work yourself. The more responsibility (not just tasks, but decision-making) you can delegate to your team, the more they will own their work and feel responsible for their own success. These are very different jobs, but training and spending time in those roles can help you on both sides.