Great Software Engineering Managers Must Write Code — 3 Reasons Why And 3 Ways To (Re)Start
Connect with your passion, connect with your team.
Some people get into software engineering as a stepping stone to manage other people, deriving satisfaction from managing progressively larger teams and dealing with office politics. This article is not for them.
Most great software engineering leaders I know are really great engineers who “stumbled” into management. They got into engineering because they love building stuff. The act of putting something together — be it Lego blocks or a software product — makes them happy inside. As they got into management, most of them stopped coding.
If you are one of these great engineering managers, I hope this article will not just remind you how much fun coding is — it will give you reasons to rekindle your passion, show you how to start coding again, and use that to better connect with your team.
Why Bother — Should Managers Really Code?
Most engineers quickly find that larger teams are needed to develop products of consequence. As they think about their future, some of them specialize in specific technical areas. For others, both they and people around them find they are good at leading such larger teams. And so they become managers. Their direct job is not to write code any more — it is to manage and lead people who write code.
Shortly after transitioning to management, many managers find that they simply don’t have time to actually code. The demands on their time from meetings with their own team members, reporting status to higher-ups, and other types of overhead, add up to a full time job — and more. Finding focused time to be “in the zone” and code gets harder with much of their time spent on responding to various interrupts.
Once they haven’t coded for a while, managers quickly find they are no longer proficient enough to take meaningful pieces of coding work. The easy solution is to say “well, it isn’t my job”. But while that may be true — that statement misses the many advantages that coding has specifically for managers.
Before looking at the reasons for managers to code, let us tackle one wrong reason: as a manager, do not take a coding project just to share the work with your team. Managing the workload of your team is arguably the most important aspect to management— but not by taking on top-priority coding work that will actually reduce your ability to manage and lead them.
One reason for managers to code is for them to continue having a strong sense of what the engineers they lead actually do. The manager’s ability to know when to push harder vs. when to take a step back, their ability to decide when to invest more into infrastructure vs. customer-visible features, and more, are derived to a large part from their personal sense of complexity and challenge. While a manager must rely on estimates given by the actual subject matter experts, their ability to engage in a thoughtful discussion requires that they are not detached from the reality of what the work is about. Coding — even a bit — really helps keep that “gut feel” good enough to engage in the discussion.
A second, related reason is for managers to be able to connect to their engineers. Engineers often crave the ability to talk to their managers in detail about the work they do and that they are passionate about. The more the manager is still hands-on, the easier that connection is. When the manager is able to bring recent, industry-relevant experience to the discussion with an engineer, that engineer will rightly feel their manager can be trusted. Conversely, if managers are perceived as dealing with PowerPoint and email, building that trust gets harder.
Finally, hands-on coding might be the best way for engineering managers to stay on top of technology advanced in their field of expertise. You can attend conferences, read books, go through articles on medium — and you should do all of these things for the unique value they bring. Still, nothing compares to “learning by doing” and for managers in software engineering, that means coding.
Yes, You Can (Again) — Three Ways Managers Can Restart Coding
OK, so you have coded in the past and loved it enough to make it your profession. You transitioned into management and stopped coding. Now you want to restart — but how? Assigning to yourself high priority work from your team’s backlog may be very dangerous: your top priority is still management. Here are some ideas for ways to restart coding, reap benefits, and have some fun:
If you haven’t coded in a while, consider taking up a personal coding project. Start by thinking what type of project would interest you enough to actually complete. Do you want to create a web application to automate some personal workflow? Maybe immerse yourself in computer vision or machine learning? Write a mobile app? You are a software engineer — there are all just a few clicks away. You may need to dust up the tools you have installed, reconsider whether you develop on some laptop / computer that you have or in a cloud environment, and find the right tutorial to get you started — but mostly you just need to decide what sounds like fun and follow through. I bet that in no time you will feel right at home.
A shortcut to the many decisions needed for a personal coding project is to participate in a hackathon. You could even consider participating in a hackathon as a part of a group, maybe even a group with some of the engineers in your team. Your goal is not to show them “you are as good as them” (if you hire well, and have been in management long enough, many engineers in your team are better at coding than you). The goal is to actually be programming, and a group hackathon may take out some of the complexity in “how to start”, while at the same time super-charging your connection with your team.
I started by saying you should not assign yourself a high priority activity from your team’s backlog. How about taking some low priority task? Is there some minor bug that you really wish be fixed but isn’t high enough priority to actually assign to any engineer? Perhaps some small featurette that speaks to you? Remember, the goal is not to reduce the load for your team — the goal is to do actually experience what your engineers do. Choosing this approach allows you to go through the same tools and workflows that your team does. I bet some of your learnings will come right back to optimizing process, tools and infrastructure creating huge benefits for your team.
In closing
Great software engineering managers can stay sharp by continuing to code, even if for different reasons and in different ways and capacities than when their actual job is coding. If you are a manager who doesn’t code today, the ideas above might help you choose how to start. If you already code, the reasons above may help you justify why. In either case, code and have fun!
