Several years ago, I began my slow pivot from day-to-day development into management. It began with a shift to an "engineering co-lead" role where I was a quasi-manager in partnership with a product manager who was the formal lead for the team. I spent my days mostly coding, but also scheduled monthly 1:1 meetings with the other engineers on my team and invested significant time in architectural planning and technical design.
It was a great role, and I was able to leverage both my people management skills and my coding chops.
A subsequent role added formal management responsibilities as I took the reigns of an engineering team entirely. Unfortunately, my days now consisted primarily of meetings, planning sessions, whiteboard conferences, and documentation. Whereas before I'd spend 70-80% of my time in the code, now I was down to less than half, spending my time instead focused on code review and strategy.
In my current role, I spend perhaps less than 20% of my time in the code. Everything I do is to support my team; to unblock my developers so they can be their most effective selves while I shoulder the burden of planning, strategizing, and even coordinating with stakeholders. The evolution is probably most pronounced in my public GitHub profile. In 2015, more than 90% of my contributions were commits - both to open and closed projects.
As of today in 2019, only 45% of my contributions are commits - mostly private, weekend projects. My contribution chart has shifted heavily towards code review, which isn't a bad thing.
One question I get frequently, both from former colleagues and even my own family, is "how do you keep your skills fresh if you aren't spending time writing code?" I have two general answers.
Code Review
I love working with other engineers on code. It's refreshing to see the approach someone else will take to solve a particular problem. More often than not, it's a radically different solution than the one I've baked in my own head, and trying to understand the different viewpoint that spawned it is an intriguing experience.
I learned computers in an entirely different way than many people in the field. As a result, I see computing problems very differently than most people. Often times, this is to my advantage and leads to an out-of-the-box solution for a tricky problem. Sometimes, though, it's useful for me to sit and ponder how a formally-trained software developer would approach the issue. It helps me thing through things a bit differently and, ultimately, I'll come to an even better solution than if the team had taken one or the other approach in isolation.
Also, code review gives me a chance to teach. It's never enough to just tell someone "this code smells." Instead, I'll take the time to explain what is wrong with the code. An anti-pattern here, a nested loop too many there, a mutation of global state over there. It's important to be able to find these issues, it's even more important to be able to explain them to someone seeing them as an issue for the first time. Re-explaining basics helps keep my eyes and my ability to explain various concepts fresh.
Self Study
Never underestimate the power of just sitting and trying to learn a new concept. I originally learned how to work with the web worker API in order to present on the topic at a jQuery conference. I live-blogged a walk through of RabbitMQ and queues to teach myself the API (in PHP) so I could later expose the same system to Scala. I'm working my way through the RingCentral APIs so I can better understand their platform and further exercise my Python coding skills.
Think of coder fitness the same way you'd think of physical fitness. If you run every day for work, you're going to be in great shape to join your friends for a jog down the beach on a random Saturday. If you spend your days sitting at a desk and never get your heart rate above 120, that weekend 5k would seem impossible.
I don't run for a living. But I do visit the gym before work so I can hone my cardio skills.[ref]I admit, I need to run even more and add some weights to my regimen, but you get the idea...[/ref] I might not code 100% of the time, but I'll spend a weekend here or an evening there working through a coding challenge so I can keep my skills up. Working with the MonkeyLearn API last week was fascinating, and I'm excited to try the AWS Comprehend API in a little bit as well. Both systems help me refresh my coding skills, while also working on projects I find intellectually stimulating.
Investing in self study and taking some time to work on personal projects is a must. I carve dedicated time out of my schedule to do just that - the same as I do for writing. It's important to set time aside and choose to sacrifice one vice or another to make the room.