Managing engineering teams outside your technical expertise

The most common path to engineering management is through a technical leadership position with people responsibilities, also referred to as tech lead manager (TLM). In such roles, besides holding people responsibilities, the engineering manager also is a technical expert within the team.

As one furthers out in their management career path, they may be posed with situations where they manage a team with a different skill set than they had as an engineer. While this type of opportunity comes with a lot of learning, it may also come loaded with self-doubt.

There's no absolute answer to how technical an engineering manager should be, given the answer is bound to the context they are inserted in. Still, one fact is that engineering managers are functional leaders. They should support their team in making strategically aligned decisions for the business, even when they're not as confident with their technical skills.

§Safeguard strategic alignment

As a TLM, you have an increased ability to introduce granular controls. Reviewing code, discussing how to implement a change, or a simple deep dive with an engineer are examples of these granular controls that inform your perspective to provide advice and give feedback. A less technical manager who needs to assure that the investment of time and effort goes to the most impactful opportunities can only exclusively resort to slightly more abstract controls, including:

  1. A clear longer-term vision. This is particularly important as tunnel vision is even more harmful to teams without a strong technical leader. How systems are built can heavily impact your ability to stay aligned to the strategy, so having a clear understanding of what is the target condition for a longer timeframe (e.g. 2-3 years) and communicating it well helps the team to make decisions that are future-proof to the most significant extent possible;
  2. A set of topline metrics and guardrail metrics. Having a well-defined set of indicators that tell you what good looks like helps assess the team's outcomes and plays a considerable role in prioritisation. For instance, making a prioritisation call between increasing availability by 1% or reducing false positives by 10% is easier when you can attribute both to the same business outcome, such as "OPEX savings". It also helps you stay away from the implementation details you don't understand;
  3. A planning cycle with a clear set of outcomes. While you may not understand the internals of how something will be achieved, understanding what and why it needs to be achieved is essential, and so is communicating that clearly with the team. Clear, quantifiable outcomes or clear ship goals attached to a business outcome are essential to any context, but it is prohibitive for teams with not-so-technical leaders, as trying to align the team through the detail will be counter-intuitive at best and disastrous in the worst-case scenario.

While you may find that your technical skills may hinder your ability to do the above, defining good abstract controls requires much more understanding of the business than the internals of the systems that achieve the outcomes.

§Decentralise technical leadership duties

For many reasons, including avoiding becoming a bottleneck, engineering managers should share technical leadership duties, even when they're relatively technical. It becomes imperative when you think you are not competent to make sound technical decisions. One approach to solve the situation, which I'm particularly not a fan of, is the TL + EM two-in-a-box approach, where the EM moves technical leadership to a senior/staff engineer in the team while keeping people management responsibilities. I believe it doesn't solve the bottleneck aspect but, instead, it fragments it into two different bottlenecks with the added alignment overhead.

What I believe to be a better approach is identifying the different challenges in the team and delegating entire problems to the most competent person to solve the challenge at hand instead. Doing so prevents merging all problems into a single problem and serves as a forcing function to identify the best people in your team to drive each problem area to clarity. To be able to trust and delegate different types of challenges to different people, you may end up with an inverted triangle-shaped team – a team with a more significant senior presence – which comes with its own set of challenges, but usually solves well the technical leadership gap in the team.

§Gather unbiased information to draw conclusions

If you have top-level alignment and shared leadership for different subjects, how do you build a cohesive picture of the whole team's state? By trusting multiple senior or staff engineers with different challenges, you may solve individual problem areas well, but you don't enable cohesion. It's easy to deflect accountability by thinking that alignment will come from people speaking with each other, especially in a senior-heavy team. Cohesion only happens intentionally, and if you leave it to be established organically, it can be highly biased by a few more vocal people, with a high propensity of being the ones you trusted the most responsibility.

With the lack of competence to verify and inspect, and not being comfortable with just trusting, I've seen folks have a lot of success build mechanisms where you gather unbiased information to reach their conclusions. Something as simple as running an anonymous survey with only linear scale answers ranging from 1-5 can give you a cohesive picture accounting for everyone's opinions and help start the right discussions.

§Learn the basics along the way

I found myself in this situation in the past, managing teams that worked closely with machine learning when I would undoubtedly fail Statistics 101. Nonetheless, more commonly than not, people hold pride in their craft and will gladly help you understand what they do. Besides learning along the way, I developed a good appreciation for identifying people who could successfully help me understand the basics. As it turns out, this is also a strong signal of competence of who would be able to uplevel others in the team whenever needed.

Liked reading this post? Share it: email/linkedin/twitter/whatsapp