Coding as an engineering manager is an exercise in cognitive dissonance. If you’ve just become a manager, you’ve likely been measuring success by the quantity and quality of the code you ship as individual contributor (IC). Suddenly, you have new metrics for success and your day-to-day work looks wildly different. One mentor tells you that coding as a manager is futile. Another tells you to stay in the code or risk dulling your technical skills. Some companies encourage their engineering managers to conduct IC work as part of their culture (or even codified in their promotion criteria). Others penalize managers for the exact same behavior. It’s confusing and stressful!
Since I started managing, I’ve tried to deliver IC work at least once a quarter (some quarters more successfully than others). In this post, I share some of what I’ve learned: the challenges of coding as an engineering manager*, the benefits, and how to identify well-scoped “unicorn” projects to work on.
Coding as a manager is hard.
Doing IC work as an engineering manager boils down to two challenges: constantly shifting contexts and priorities.
Management requires a lot of context shifting. One meeting you’re coming up with a strategy for headcount, another you’re listening to someone grapple with giving tough feedback, and another you’re leading a kanban meeting. By contrast, coding requires deep work, with an uninterrupted sense of focus for several hours. If you’ve ever tried to code in the half an hour between meetings, you know it looks something like this:
import numpy as np
import pandas as pd
# pull data here
If n in list(TODO):
# look this up, used to know how to do thisAs a leader, your job is to prioritize supporting your teammates. That means having career conversations, providing feedback, and helping them deliver innovative and impactful work. While this often takes place in one-on-ones, there are oftentimes follow up meetings and check-ins with relevant collaborators, too. As you increase the size of your team, it becomes harder and harder to find any breathing room in a 40 hour work week, let alone the several hours needed to code even a small project from beginning to end.
Why you should consider coding anyway*
First, coding an IC project can help build empathy for your teammates, the tools that they use, and the challenges they encounter. For instance, I worked on a project with a teammate and learned about several services around the company and their challenges firsthand. As a result, in later meetings I was able to speak more specifically and with greater confidence about them. I submitted requests to the maintaining teams and, consequently, got updates prioritized that greatly helped my team.
Second, coding (sometimes for the first time in weeks or even months) means you’re going to need to ask your teammates for help. Recently, I was trying to solve a data wrangling problem that ended up with not one, not two, but three nested for loops. My teammates joked that it put the “OH NO” in Big O Notation. I humbly asked for help and together we figured out a way to solve the same problem with much less complexity (and had a good laugh). In my experience, people like feeling helpful, and there’s something special about helping your boss when they’re struggling. We want our teammates to ask others for help. Being vulnerable and asking for help as a leader helps you model that behavior for your teammates, too.
Finally, and most important to your mental health as a manager: shipping code can make you feel good. Management rarely lends itself to that feeling of “doneness” and is often riddled with self-doubt. Doing IC work, by contrast, is a usually discrete task. You can build something, point at it, and say, “Look! I built that. Sweet.”
How to code as a manager
Broadly speaking, doing IC work as a manager looks something like this:
- Make sure nothing is on fire.
- Find a narrowly-scoped “unicorn” project.
- Block off time for deep work.
- Start with delegation in mind.
I’ll walk through each of these in the sections below.
Make sure nothing is on fire.
Coding while one of your team is struggling with something urgent is like fiddling while Rome burns. It also means that you’re not doing the core functions of your job (i.e. helping your teammates). So, before you even think about scoping an IC project, make sure things feel relatively stable on your team.
Find a narrowly-scoped “unicorn” project.
Let me show you what scoping the right projects doesn’t look like.
In my eagerness to help a new product team once, I picked up running several A/B tests that we wanted to roll out by the end of the quarter. The A/B tests were simple enough to run and keep an eye on until I needed to spin other managerial plates. Meanwhile, my Product Manager had to start picking up the slack. In the end, we ended up delegating the tests to someone else who ran them to completion, but it wasn’t a good feeling knowing I was letting my PM down.
By contrast, a well scoped IC project for managers:
- is not time-sensitive
- is fairly small
- does not have any dependencies
- is a “nice-to-have” or quality of life improvement that won’t get prioritized by your teammates and might have some nice impact
- plays to one’s strengths
i.e. a unicorn. Unicorn IC projects are not going to come up all the time. You can’t find them at all if you don’t know what to look for, though.
For instance, I was in a design jam a few years back where some UX teammates said to one another, “Yeah, we don’t always know X about Y queries. It would be nice if we had a tool that could do that.” What they were asking for fairly small. Before they even knew it, a couple hours later I had built a dashboard that they still use to help them understand user behaviors on the site. Alas, ye have yeself a unicorn!
It’s also important you find an IC project that plays to your strengths. It’s already going to be easy to fall into the trap of feeling bad about your coding skills because they will likely be rusty and you’ll code more slowly than you used to. Consequently, you probably won’t keep feeling motivated to do more IC work and this blog post and I will have failed you.
When I code, then, it usually is some kind of analysis of survey bias, helping A/B testing, or building well-designed graphs. Why? Because I like these things, I’m good at them, and they give me energy. You’ll also be able to get your IC projects done more quickly and of a higher quality.
Block off time for deep work.
Half an hour here and there is usually not enough to get meaningful deep work done. Since becoming a manager, I have blocked off several hours in the morning to do some kind of deep work every week, whether that’s coding or reading the latest in my field. This encourages others to message me first before booking over my deep work block. Sometimes I would have to take the meeting anyway, but more often than not, I likely avoided meeting during my peak coding hours. Google Calendar’s new Out of Office feature makes this even more aggressive, by auto-turning down meetings booked over your block.
Some weeks, I can’t prioritize deep work as much, other weeks I have more time than usual. I’ve seen managers beat themselves up about not having time to do IC work every week. Stop. It’s not a realistic goal. In his discussion of coding as a manager, Ben Edmunds writes, “Redefine what success looks like for yourself […] understand that day-to-day tasks aren’t set in stone. As a manager you need to be fluid.” Amen.
Start with delegation in mind.
Coding as a manager means that you’re going to need to spin your other managerial plates again fairly quickly. You won’t have a ton of time to code projects, so whatever you build will likely need to be a prototype of some kind. When coding an IC project as a manager, figure out what a delegatable MVP might look like (hint: it likely includes well-commented code and some pair-programming) and keep that as your end goal.
One of the tools I built as a manager helped my team run multivariate A/B tests more rigorously. I knew it was janky (heck, it pulled in data from a Google spreadsheet) but it could get the job done for the team and was better than nothing. I was then able to delegate it to my teammate.
This was great for two reasons. First, it gave my teammate the chance to learn from my expertise. She got to deepen her understanding of measuring statistical significance in multivariate A/B tests. Second, she took what I had originally built and made it way better. While my prototype effectively shipped with comic sans as its font, her version had these beautiful, easily digestible graphs and an even more rigorous statistical approach. Her V.1 of the tool is a much better finished project that’s still in use today.
To Sum Up
Engineering managers get a lot of conflicting messages about whether or not they should code. Coding can help you build empathy and trust with your teammates, thereby making you a more effective leader; but you set yourself up for failure if you take on the same kinds of projects you took on as an IC and try to stuff coding in between meetings. Instead, reframe the kinds of code you ship. Carve out dedicated time for deep work and keep an eye out for small, non-urgent delegatable “unicorn” projects that play to your strengths and can bring value to the team.
Notes
* By the way, when I refer to “engineering”, I don’t just mean Software Engineers: I also include Data Scientists, QA, i.e those whose IC work involves some degree of coding. [Jump Back]
* Probably. The field of “Engineering Management” is still in its infancy — up until recently there were very few books published on the subject. A lot of the evidence presented here is anecdotal, so your mileage may vary. For instance, one of the hypotheses I’ve heard about doing coding as a manager is that it helps you build “street cred”. I honestly don’t know if I’ve helped my cred or I just made an ass of myself in the Git repository at work, so I chose not to touch on this point in this article, but I’m curious about others’ experiences with this. The scientist in me wants more rigorously collected qualitative and quantitative data around the benefits and drawbacks of doing IC work in the fields of Software Engineering and Data Science (so reach out to me if you’re interested, I have some ideas). [Jump Back]
Robyn Rap 
