Note: This post also appears on the blog of my employer, Enigma (enigma.io)

Earlier this year I made a career change: I decided to stop being an Individual Contributor (or "IC", i.e. someone who codes) and became the Engineering Manager of the team I was a member of. I call it a "career change" because it's important to recognize the move for what it is. All too often, such a change is viewed as the logical progression of an engineer's career. That's a shame.

It's a shame because being an engineer trains you to be a people manager about as well as it trains you to be a circus juggler. There are almost no transferable skills, save the domain knowledge you've acquired that will ostensibly help in managing projects. But (as every engineer will tell you), being a great engineer does not mean you'll be even a passable manager. Some companies (like my own) realize this and create parallel career paths for engineers that want to write code forever without mortgaging their advancement opportunities. Sadly, most companies are not so forward thinking.

But let's assume you're in the same position I was:

• You love to teach
• You see a person's potential and want to make your team members better than they thought they could be
• You care about your company and want to improve things at an organizational level
• Above all, you have empathy and care about the people you work with

Congratulations! At least you're making this career change for the right reasons. That's the good news. The bad news? The next few months will likely be the most overwhelming of your career. Actually, in my case it was more than overwhelming. For the first time in my life, work was hard. Most of my professional experience has been intellectually stimulating, but I wouldn't describe very much of it as "hard". I almost always had a sense of what needed to be done to solve a problem. If I didn't, I knew I could research the problem and a way forward would almost always present itself. I spent the first eight years of my career building high-frequency trading systems in C++ for major investment banks (Goldman Sachs and, later, Wells Fargo), so the work wasn't trivial, but it also wasn't particularly hard.

But managing people is different. I had (have) so much to learn, and my decisions now had a direct impact on people's livelihood. I was scared that my lack of knowledge would negatively affect my teams. "Screwing up" had taken on a whole new meaning.

And yet, despite all of the new responsibilities, fear of failure, and awareness of a severe knowledge gap, I wanted to do one thing above all else:

Write code.

Why Do Engineering Managers Desperately Want to Write Code?

Why was that the case? Why did I want to do the exact thing that I had just willingly left behind? Becoming a manager was a choice. Had I made the wrong one? In what other industry does management immediately yearn to do the jobs of those they manage?

(Note, when I refer to "writing code" in this article I specifically mean: a) during company time and b) on tasks that could (should) be completed by people you manage)

It was easy to convince myself that it was necessary (or at the very least, acceptable) to continue writing code. Here are some common justifications Engineering Managers give with regards to continuing to write code:

1. I need to keep my technical edge; I don't want to get left behind
2. My team won't respect me if they don't see how technical I am
3. I'm a very good programmer. Not writing code would be a waste of my talents
4. The team needs me to write code; they're not capable of solving the problem themselves

You will come up with all sorts of other rationalizations for why it's OK for you to continue to code. Why you must write code. How it would be negligent not to... It's OK. I've been there. Unfortunately, you're wrong.

OK, But Really...WHY?

After a bit of introspection, I realized that there were two reasons I wanted so badly to write code:

1. It was familiar and safe
2. It was a large part of how I determined my self-worth

When faced with new and challenging situations, humans naturally retreat to the familiar. I wanted to write code not because it would have been a productive use of my time, but because every part of my new position was unfamiliar and hard. Writing code was a safety blanket. I knew I could do it well, and while writing code I wouldn't feel so lost and frustrated.

New managers decide to write code because managing people is hard and new, while coding is safe and familiar.

In addition, I am a maker of things at heart. Even in the worst of times, I could usually point to something and say "I made that." Management has few such artifacts. In fact, evaluating my performance in general was maddeningly hard. Not only did I not know how to do the job, I didn't even know if I was doing it well. When I remove programming, which is intimately tied to my sense of self, and replace it with a skill I can't even judge my performance at, bad feelings are bound to follow.

An engineer-cum-manager doesn't magically stop caring about building cool things.

And believe me, I'm really invested in writing code. I wrote a book on Python, speak at conferences, and privately tutor individuals in Python. If anyone should have a "get out of not-programming free" card, I submit myself as a candidate. But I don't deserve one. No one does. It's harmful.

What's the Harm?

Many managers ask "What's the harm in continuing to write code along with the team? I'd only be helping them..." Believe it or not, there is actual harm in coding at this point. Here are a few things to consider:

1. You have a new job to master. That takes work. Every minute you spend coding is a minute you could have spent reading, talking to peers, etc. to become a better manager.
2. The balance of power is no longer the same on your team. People will treat you (and, by extension, your code) differently, and that's a problem. They'll be less critical in code reviews. They'll be frustrated if you assign a task they were interested in to yourself. They'll be less willing to collaborate with you for fear of messing up in front of "the boss". Realize and accept the fact that it would be an abuse of your power (or, at the very least, a conflict of interest) to assign yourself coding tasks.

So Now What?

The first point from the previous section is actually an opportunity in disguise. Try this: every time you feel the urge to write code, instead spend the time reading something related to management, even if only tangentially. Everyone who manages people will have favorite books, blogs, or speakers. Just ask a peer or two for some material to get started.

I know what you're thinking: "That sounds like a trite platitude. Does it even work?" Well, I hate to answer a question like that with an anecdote, but forgive me this one time. In the months that followed my initial move, I was asked to manage additional people and teams. As of a few weeks ago, I'm the Head of Engineering at Enigma, with about 30 engineers and engineering managers reporting to me. So, in my case, it worked, though I'll be the first to admit that probably 25% or less of my career advancement has been due to my own skills (and much more a factor of organizational needs and my genuine affection for and interest in the engineers at the company). But still, it didn't hurt...

Note:

I'd be remiss if I failed to mention that I only began thinking about this issue because it was chosen as a topic of conversation during EMP at Orbital. I was in the first cohort of a management training course run by Camille Fournier (@skamille, former CTO of Rent The Runway), Kellan Elliott-McCrea (@kellan, Former CTO of Etsy and Architect at Flickr) and Gary Chou (@garychou, founder of Orbital, formerly at Union Square Ventures). It was an awesome experience that brought together rising engineering leaders from startups in NYC to discuss the issues faced when becoming a manager. Every major NYC tech company I can think of was represented. It was also a wonderful networking opportunity, as many of the participants are still friends.

Posted on Aug 28, 2024 by Jeff Knupp