When an engineer experiences career success, they are often steered in the direction of management. There is a natural push to spread the influence of our best people via management opportunities. The dream is to transform our most capable engineers into effective leaders.
Despite these well-intentioned efforts, in my experience with a variety of tech companies, it’s quite challenging to make the role of an engineering manager coherent and equally accessible across various teams and to potential young leaders.
There are several common problems that crop up. And they’re worth highlighting due to their prevalence in the industry and the sometimes-unrecognized degree of complexity involved in attempting to solve them.
Yes, engineering management is a full-time job
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 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 less 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 of the job away from having immediate and tangible gratification.
Management roles force a wide range of focus
I highlight effectiveness, in contrast to competence and intelligence, because it is a different phenomenon. It is common for competent people to fail as leaders due to an unwillingness to acknowledge the shift from a depth-focused expertise to a breadth-focused expertise. Part of why management is necessary at all is the need to have people with accountability and decision-making capability across a range of areas that is too large to allow for complete depth of expertise.
Expertise for many engineers is focused and limited in scope, even to a single system. An engineer is expected to know in great depth the workings of key system components to the point of being able to do things like spot root causes of issues based on obscure but familiar symptoms. A manager gains little or no value from this level of knowledge and instead needs to make decisions based on a broader scope.
This situation can be frustrating. After transitioning into management, some find they cannot achieve much without depending on other people and leveraging the knowledge of others. At the same time, they are asked to make more important decisions with less knowledge of the finer details.
Incidentally, thinking about this distinction can help a person figure out if they should be pursuing management in the first place. Some people enjoy management; some don’t. One can ask, “What are moments that make me feel proud in my work?” Is it learning an intricate detail that nobody else knows? Or is it seeing a connection between two separate areas that was previously unrecognized. The former example speaks to depth, the latter breadth.
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 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, only with new titles.
One of the satisfying aspects of managing, which occurs when owning multiple products and systems, is being able to simplify problems by virtue of maintaining a zoomed-out view. For example, a conversation of the following form:
- Engineer: “While I’m building B as a piece of A, I’m not sure if I should rebuild C from scratch or maybe fork D and try to make that work with B.”
- Manager: “What if we don’t build A at all and instead use this thing over here in a new way?”
The flip side of the frustration from constantly depending on others is the leverage you get in being able to connect people and systems to find simple paths to impactful results.
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 key 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 well 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.
Adam Waksman is Senior Director of Engineering at Foursquare.
The audio problem: Learn how new cloud-based API solutions are solving imperfect, frustrating audio in video conferences. Access here