Good engineers can become good leaders

When an engineer knows a professional success, he is often directed to management. There is a natural impulse to spread the influence of our best people through management opportunities. The dream is to turn our most competent engineers into effective leaders.

Despite these well-intentioned efforts, in my experience with various technology companies, it is very difficult to make the role of engineering manager consistent and equally accessible to all teams and potential young leaders.

Several common problems arise. And they deserve to be highlighted because of their prevalence in the sector and the degree of complexity sometimes misunderstood involved in the attempt to solve them.

Yes, technical management is a full-time job

Many engineers, including those with management roles, do not really know what management is supposed to be. The respect and simplicity of being a senior engineer is more difficult to recognize in leadership roles. In an engineering environment, you will hear phrases such as:

• "Oh yes, it's a Haskell witch!"
• "No one knows Kafka better than him."
• "She's definitely your reference person if you need the magic of ZooKeeper."

You are less likely to hear things like:

• "He prioritizes our roadmap so well; our job is so much about strategy. "
• "It increases team retention rates like you do not believe it."
• "This guy really recognizes the shortcomings and foresees risks as a champion."

Most of the tasks of an effective technical manager are less technical in nature: prioritization, communication, risk awareness, linking silos, inspiring teams, developing new leaders, and so on. This makes success less visible, or at least less obvious, and keeps everyday work from immediate and tangible satisfaction.

Management roles force a wide range of priorities

I stress efficiency, unlike skill and intelligence, because it's a different phenomenon. It is common for competent people to fail as leaders because of their reluctance to recognize the shift from depth-based expertise to extensive expertise. Part of the reason why management is needed is the need for people with empowerment and decision-making skills in a range of areas that are too broad to allow for full expertise.

The expertise of many engineers is targeted and limited even to one system. An engineer is expected to have a thorough understanding of how essential system components function to the point of being able to perform tasks such as finding root causes of problems, based on obscure but familiar symptoms. A manager derives little or no value from this level of knowledge and must instead make decisions based on a broader scope.

This situation can be frustrating. After the transition to management, some find that they can not accomplish much without relying on others and leveraging the knowledge of others. At the same time, they are asked to make larger decisions with less knowledge of the finer details.

Incidentally, thinking about this distinction can help a person determine if they should be looking for management in the first place. Some people like management; some no. One can ask, "What are the moments that make me proud of my work?" Is this learning a complex detail that no one knows? Or does he see a connection between two distinct areas that was not recognized before? The first example speaks of depth, the second of width.

There is no question of coding

A helpful transition for me occurred when I accepted the fact that management is a full-time job. Since then, I have adopted the view that, in current cases, senior management should not write code. For some managers, coding can be a crutch. It's a way to gain the respect of their team, which is relatable and familiar, and it helps them avoid the impostor syndrome. But the manager's time is usually required (and more valuable) elsewhere.

In my interactions with the outside world at Foursquare, I meet and notice cases of engineering leaders who appreciate their technical expertise while being ineffective as managers. You see the lag when you talk to management. Their technical managers are, for example, "brilliant", "super intelligent", "world-clbad talent", while their departments "disappoint their customers", "leave roadmaps slip", "do the wrong job", "Lose people" and "stagnant." It's because their leaders act as senior engineers, only with new titles.

One of the satisfying aspects of management, which occurs when one has several products and systems, is to be able to simplify problems by maintaining an enlarged view. For example, a conversation of the following form:

• Engineer: "While I'm building B as a piece of A, I'm not sure I have to rebuild C from scratch or maybe fork off D and try to make it work with B."
• Manager: "What if we did not build A at all but use this thing here in a new way?"

The negative side of frustration with constant dependence on others is that you are able to connect people and systems to find simple solutions to achieve meaningful results.

Accept that management is a skill set

One of the most unusual comments I received (and I guess that's why I remember it) was: "In reality, you treat the direction as if it were one thing. "

I think one of the best steps that a technical manager can take is to recognize that management itself is a skill set that needs to be learned and put into practice. Just as a highly experienced senior engineer will continue to learn the latest subtleties of Java 10, a highly experienced leader needs to make an effort to develop his key skills.

The most practical advice I have to offer in this regard is to be thoughtful. If you are a manager or if you become one soon, your agenda is probably littered with meetings and events with qualitative objectives. If you leave an individual meeting, product planning session, customer interaction, design review, or other engagement, you feel like you are "wasting your time" or "not doing the real work." take the time to think about what was disturbing about this interaction. Maybe you played well and the impostor syndrome goes off; or maybe you want to do something specific that you should focus on next time. Anyway, it's worth thinking about, and it's a good job of your time.

Adam Waksman is Senior Director of Engineering at Foursquare.