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 an 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 engineering managers to conduct IC work as part of their culture, even codifying this behavior in 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 manager1, the benefits, and the ways to identify well-scoped unicorn projects to work on.
Ruby star rainbow sparkle via SVG SILH
While there is no I in Team, there is both a U and an IC in unicorn, just sayin’.
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 in yet 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-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 this
As 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 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 anyway2
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 firsthand about several services around Indeed and their challenges. 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’ll 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 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 usually a 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 someone on 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 on your team feel relatively stable.
Find a narrowly scoped unicorn project
Let me show you what scoping the right projects doesn’t look like.
One time, in my eagerness to help a new product team, I took on 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 keep an eye on until I needed to spin other managerial plates. Meanwhile, my product manager had to pick up the slack. In the end, we delegated the tests to someone else who ran them to completion. 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 your strengths
That is, 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 was fairly small. Before they even knew it, a couple hours later I had built an Ishbook that they still use to help them understand user behaviors on the site.
Alas, ye have yeself a unicorn!
It’s also important that your IC project 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.
My IC projects usually are some kind of analysis of survey or measurement 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. When you choose an IC project that feels the same way, you’ll be able to get it done more quickly and at 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 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 need to join the meeting anyway, but more often than not, I avoid meeting during my peak coding hours. Google Calendar’s new Out of Office feature makes this even more aggressive, by auto-declining 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 minimum viable product (MVP) might look like. Hint: it likely includes well-commented code and pair programming. Keep that MVP as your end goal.
One of the tools I built as a manager helped our job search product 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 they should code. Coding can help you build empathy and trust with your teammates, thereby making you a more effective leader. You set yourself up for failure, though, if you take on the same kinds of projects you had as an IC and try to stuff in coding 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.
- Probably. The field of engineering management is still in its infancy—up until recently, very few books (The Manager’s Path, Things Every Engineering Manager Should Know, An Elegant Puzzle: Systems of Engineering Management) were published on the subject. A lot of the evidence presented here is anecdotal, so your mileage may vary. For instance, one hypothesis I’ve heard about 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 myself look foolish in the Git repository here 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.