Managers should code, but not at work
Should managers code? This question doesn’t seem to have a clear answer. There are proponents and opponents to the debate, each having valid points on their side. I recently coded a side project at work and this led me to reevaluate my stance on this matter. Having gone through it, I can say, that my position has changed from managers shouldn’t code to managers should code, but not at work.
I have been managing engineering teams for a couple of years now and one of the things I did as I transitioned was to stop coding. The main reasons being, attempting to code on your team will make you a blocker to others on the team, there aren’t enough hours in the day to have all your meetings and one on ones as well as code, and it is important to demonstrate trust to your team by stepping back from coding.
On the flip side, as time passes and you aren’t coding as a manager, you get disconnected from your team. You slowly begin to forget what it actually is like to build systems and products. You find it harder to follow some of the team’s technical decisions. In the long run, this can lead in the worst case to a loss of respect from the team due to a lack of credibility.
This conundrum created by these two options leads to an everlasting conflict for engineering leaders. At its heart, is a tug-of-war between the manager and maker schedules. The manager schedule is comprised of continual context switching, moving from meeting to meeting. The maker schedule on the other hand, requires large contiguous blocks of focus time to create. As a manager, your job dictates you operate on the manager schedule but in order to code, you need a maker schedule.
Recently, I got to set up a meeting scheduler application for my team refactoring and deploying Yelp Beans on our systems. It was a ‘side project’ that I started working on during a work hack week and continued thereafter. It is now deployed and in use by the team.
I discovered a couple of things going through this experience. Firstly, I really missed coding and the feelings of accomplishment and success you get from building something, and from locating and fixing elusive bugs. I also realized that I was a lot more disconnected from my teams day-to-day than I initially thought: the nitty-gritty of our dev environment set up, and how we packaged and deployed our services. All in all, it seems that I should code more regularly so I can empathize better with my team.
I, however, noticed that working on this project had an impact on my managerial duties. In some one on ones, I couldn’t fully focus and listen to the subject at hand. At the back of my mind, I was thinking about my code: what optimizations I could make, how to squash the current frustrating bug etc. In the worst of cases, I “hijacked” part of the one-on-one to pair program.
While my team were great sports about it, I do not think it is a sustainable model. I found it very hard to context-switch from my code and to fully focus on meetings: The manager vs maker schedule strikes again. But I enjoyed the experience overall and do not think that fully stopping to code is great either.
In the end, I’m going to continue to code, but not at work. I need a clear delineation between being a manager and coding, so I can fully focus on my team and meetings.