Dealing With The Fear Of Losing Your Technical Skill Set When Stepping Into A Management Role

When I was promoted to my current role of VP of Technology a little over 2 years ago, one of my biggest fears was that my technical chops would quickly deteriorate. I had been writing code since I was in grade school and after having done it for 20+ years, I had gotten to be decent at it. It would be such a shame, I thought, if all the hours, money, and energy I had invested into becoming a developer would go to waste because of the lure of becoming an “executive”. I also feared what would happen if 6 - 12 months after having become a VP, it turned out that I was either really bad at my new job or hated it (or both) AND my technical skill had rusted to the point that I couldn’t find another job as a developer. I would then suffer and my wife and my son would suffer and my future generations would suffer… I know I’m exaggerating a bit here but the fear was real. Despite my fears, however, I decided to accept the promotion because of 2 main reasons: Becoming the top technologist for a company was a career aspiration of mine and the opportunity was simply too great to pass up.

As soon as I transitioned to my new role, most of the time I had available for coding had to go towards other, more important responsibilities, which I had fully expected. Furthermore once I stepped into the role, I realized very quickly that it would be impossible for me to be an effective manager AND have time to code as much as I want to AND still be present for my family. I had to pick 2 out of the 3.

Fast forward 26 months from when I was promoted - I’m happy to share that I do not believe my technical chops have gotten rusty in the past 26 months. Sure, there are certain aspects of my technical skill set that have deteriorated, such as:

• I’m not nearly as up to date as to the ins and outs of our primary application code base
• I’ve gotten rusty at writing JavaScript and Sass/CSS

Those are it. While I’m writing a lot less Java code than before, I’ve been writing enough of it to still stay sharp. I’m probably writing just as much SQL (if not more) compared to my pre-VP days. Becoming a VP has forced me to actually care and know a little bit about ops-related items, such as CDN, WAF, DNS, Jenkins, various AWS services, and configuration management, which means I’ve gained a lot of knowledge and awareness in these areas. I admit I was pretty ignorant about these sorts of things during my pre-VP days. I’m more comfortable on the Linux command line than ever before. Just about a month ago , I was able to write a script that scans through all of the previous day’s application logs, looks for errors, and sends it out in a readable email format on a daily basis. It may not seem like a big deal to many but I know that I would’ve struggled much more with getting something like this done during my pre-VP days. I also led the effort in converting our primary application from Ant to Gradle, which was completed several months ago. It took me over 6 months to complete and I ended up spending a good amount of time working on this on my own time but the effort was well worth it. I now know something about Gradle and can attest to the fact that it’s infinitely better than Ant or Maven.

When I became a VP, I had told myself that I want to stay technically sharp–sharp enough for me to be able to transition to being a sole contributing engineer without much trouble. Even though I really enjoy being in engineering management and have proven (to myself at least) that I’m decent enough at it, it’s still important to me that I stay technically sharp. Not only do I think that maintaining my technical chops enables me to be a better resource to others on my team as well as to the rest of the company, I think it’s just me being smart. For every single engineering management opportunities out there, there are dozens if not hundreds of sole contributing engineering roles. This will always be the case.

Leading Snowflakes, is a book I highly recommend reading if you’re in an engineering management role and this book stresses the importance of making time to make things even as a manager. In fact, this is the very first chapter of the book and I’m so happy this is where the book starts off. The fear of losing my technical chops pushed me to regularly make time to do Maker things from the very first day in my new role. I regularly block out anywhere from 2 - 6 hours each week on my calendar to do Maker things and I use this time to push up various kinds of code changes that end up in production. While most of the Maker tasks I work on are small-ish items I can complete within just a few hours I also work on larger, more complex items from time to time and work on them over several weeks and months. Most recently I spent about 20 hours doing some major refactoring around how configuration files are organized in the code base. While the effort took about 2 months (my wife had a baby in the middle, which elongated my development effort a little…) I’m so glad I got it done.

You might be in a situation now where you’re currently in a senior-level engineering role and are considering making the switch to a managerial role. If the fear of losing your technical acumen is causing anxiety about the move into management, I think it’s likely that you’ll have at least some control over your ability to continue to stay sharp technically. If, as a manager, you are going to continue to work closely with technical folks, a few hours of dedicated Maker time will go a long way towards helping you not lose your technical skill set.

• 2023 2
• 2021 6
• 2019 1
• 2018 5
• 2017 9
• 2016 25
• 2015 6
• 2014 6
• 2013 15
• 2012 16
• 2011 8
• 2010 13