Time for some character development

I like to think of it as a specialization in your skill tree. If you are like me, you probably have a lot of fun wrestling with code and tricky technical problems, which leads you toward a different specialization: the Subject Matter Expert (SME).
But I chose the Manager path when planning my career next steps, even though most would assume the obvious move was to double down on what I was already good at. Personal experience led me here. As an SME, you get to design, plan, and build things. That’s fun. But I try to be efficient with my time, and above all else, my life.
I have met great managers who saved me and our clients a significant amount of wasted effort. Chasing the newest tech just for the sake of it is not always the best play. So I would rather fight smarter, even if that means dealing with more people than machines.
The manager role does not replace technical skills. It layers on top of them. The people who struggle most in early management are usually the ones who try to stop being technical entirely. That is the wrong move.
What changes is where your time goes. Less doing, more enabling.
The single most important skill, and the one most engineers underestimate. Not presentation skills. Not writing reports. The ability to say what you mean to someone who does not share your context, and to understand what they mean when they say something vague.
Most miscommunications in engineering teams are not technical. They are a project manager and a developer using the word “done” to mean different things.
You will always have more to do than time allows. The skill is not working faster. It is deciding what does not get done today, and being able to explain that decision to both your team and your manager.
This is harder than it sounds because the wrong answer has visible consequences and the right answer often does not.
Understanding what motivates someone, when they are struggling but not saying it, when feedback will land well versus when it will backfire. This is part intuition, part paying attention.
You will not get it right every time. The goal is to be wrong less often than you would be if you ignored it.
A specific skill worth naming because most meetings are bad and most engineers know it. A good meeting has a clear purpose, starts on time, ends with a decision or a next action, and does not include people who have nothing to do there.
If you cannot describe in one sentence what the meeting is for, you are not ready to schedule it.