When an engineer in the tech industry experiences career success and demonstrates significant value, a common question one asks themself is, "should I become a manager?" We try to determine what our paths should be through internal dialogues, trial periods, and engineering ladders. For example, companies will identify "technical track" vs. "management track" based on perceived aptitude. Other common paths include becoming technical leads, mentors, managers-in-training, and so on. While the “tracks” differ by company, we see many of the same steps taken across various organizations to transform capable engineers into effective leaders.

Despite these well-intentioned efforts, in my experiences with a variety of tech companies, the same challenges are present in making the role of an engineering manager coherent and equally accessible across various teams and to potential young leaders.

I highlight these problems not because they are easy, but because they are hard. And I believe they are exacerbated by a hesitance to engage wholeheartedly with the practice and discipline of management.

Yes, engineering management is a full-time job

The reality is that many engineers, including those in management roles, aren't sure what management is supposed to be. There's a respect and simplicity that comes along with being a principal engineer that is more challenging to recognize in management roles. 

In an engineering environment, you'll hear phrases like:

• “Oh yeah, she's a Haskell wizard!”
• “Nobody knows Kafka better than him.”
• “She's definitely your go-to person if you need to do some ZooKeeper magic.”

You are less likely to hear things like:

• “He prioritizes our roadmap so well; our work is so on strategy.”
• “She increases team retention rates like you wouldn't believe.”
• “That guy really recognizes gaps and foresees risks like a champ.”

Much of the job of an effective engineering manager is non-technical in nature: prioritization, communication, risk-awareness, connecting silos, inspiring teams, growing new leaders, and so forth. This makes success less visible, or at least less obvious, and pushes the day-to-day further from the world of instant gratification.

Operating without Instant Gratification

A non-technical, C-level executive I used to work with told me he was jealous of engineers, because, as he claimed, "Your whole world is instant gratification." Engineers expect to know in real time whether their code compiles, if their unit tests pass, how many lines of code they're going to commit, which tickets will be closed, which features will be visible, and what the server's uptime is. So much of an engineer's job is measurable and visible. 

But these situations change. For example, one day a successful, principal engineer transitions and becomes a manager. She has a long one-on-one a week later with an employee who feels uncertain about his career path. They talk for 90 minutes and come to no definitive conclusion. Did the new manager do a good job? Was that an effective use of her time? It's often neither obvious nor highly visible. It's a different way of thinking, and it can be unsettling.

It's not about coding anymore

A helpful transition for me occurred when I accepted that management is a full-time job. I've since adopted the opinion that in common cases, senior management should not write code at all. For some managers, coding can be a crutch. It's a way to earn the respect of their team that is relatable and familiar, and it helps them avoid imposter syndrome. But a manager’s time is usually required (and more valuable) elsewhere.

In my interactions with the world outside of Foursquare, I frequently encounter and notice cases of engineering leaders who garner respect for their technical expertise while being ineffective as managers. You see the disconnect when you talk to executive leadership. Their engineering leaders are (for instance) "awesome," "super-smart," "world-class talent," while their departments are "disappointing their clients," "letting roadmaps slip," "doing the wrong work," "losing people," and "stagnating." It's because their leaders are acting like principal engineers with only new titles.

Accepting that management is a skill set

One of the more unusual pieces of feedback I've received (which I suppose is why I remember it) was, “You actually treat management like it's a thing.”

I believe one of the best steps an engineering manager can take is to recognize that management itself is a skill set that needs to be learned and practiced. Just as a highly-experienced principal engineer will continue to learn the latest intricacies of Java 10, a highly-experienced leader needs to put effort into their skills.

The most practical advice I have to offer on this front is to be thoughtful. If you are a manager or becoming one soon, your calendar is probably littered with meetings and events with qualitative goals. If you walk out of a one-on-one, a product planning session, a client interaction, a design review or some other engagement, feeling like you “wasted your time” or "didn't get to do the real work," take some time to think about what was unsettling about that interaction. Perhaps you performed just fine and your imposter syndrome is kicking in; or perhaps there's something specific you wanted to achieve that you should focus on next time. Either way it's worth reflecting on, and it's a good use of your time to do so.

The skill set of management itself is distinct from the quantitative and technical domains of engineering. Recognizing and appreciating the importance and the subtleties of how leadership skills make and break organizations from the inside can energize and embolden leaders in new situations.