One question I’ve been grappling with lately as we’ve been interviewing manager candidates has been, how much programming do we expect an engineering manager to do? It’s an important question, because most engineering managers started out as engineers, and most engineers got into the profession to write code. In a recent post, Cate Huston gets at why it’s difficult letting go:

There’s something we all talk about in becoming a manager – and that’s the process of writing less code. We bemoan it because it’s hard to let go of that part of our identity. But also because it’s so quantifiable. Today I wrote X lines of code. Today I deleted Y lines of code. Today I implemented feature Z. Concrete achievements are reassuring. Today I left the codebase better than I found it. Good job.

Read the whole post, it’s really good.

One interesting part of being a manager of managers is that it’s part of your job to set the larger team’s expectations around managers writing code. When you’re hiring managers, it’s also really important to give candidates a proper sense of what will be expected of them on the job. Some candidates really want to keep writing code, and others may not have the coding skills to be hired as an individual contributor on the team any longer. It’s up to the hiring manager to figure out what will work for the team.

What individual contributors really want is someone who could probably do their job and who can help them solve hard technical problems one on one, but will embrace the role of facilitator and avoid creating situations where their desire to code is a blocker. Perhaps most importantly, they don’t want a micromanager who will second guess all of their decisions but they do want someone who can help them improve their craft.

It’s also true that understanding the stack is really useful for managers as well. It helps to be able to explain your team’s work effectively when working with other teams. It’s fun and useful to help individual contributors solve technical problems as well as people problems. As a manager, you also have the privilege of working really closely with excellent engineers. It would be unfortunate not to learn from them.

So I’ve been working out a rule of thumb that captures how a manager (or would-be manager) should think about programming as part of their job, if that job is managing one of the teams that ultimately reports to me. That rule is:

A manager actively avoids creating situations where their coding is necessary for the success of the project.

That leaves a lot of leeway for managers to pick up technical skills and do some coding within the confines of their schedule. There’s always a long list of things that would be nice to have or tasks that crop up that aren’t project work and if managers want to do some of this work, so much the better. It’s a great way to learn and it helps the team focus on the big stuff. At the same time, it establishes a clear line between a manager, even a “technical” manager, and a tech lead. It should also keep the manager out of the way of the individual contributors.

Regardless of your philosophy, as a manager of managers, if the teams that report to you don’t have a clear understanding of what’s expected of managers as technical contributors, it’s going to become your problem at some point, and will end with people being profoundly unhappy with their jobs.

I should also add that one skill really good managers have is knowing how to surf this wave – applying their technical skills when it really counts and keeping their distance when that’s what the team needs. If things are really working, maybe it’s best for you not to be a micromanager and to let the team work it out among themselves. Nobody ever said this job is easy.