Out of bounds

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.

Unavoidably, at some point that manager will have to manage a team with a different skill set than they had as an engineer. I was a web engineer most of my career, and still remember the first ML team I had to manage. The opportunity came with a lot of learning, it may also came loaded with self-doubt.

I think the self-doubt was easily justifiable: engineering managers are accountable for people, but also are functional leaders – ultimately accountable for technology, even when they're not as confident with their technical skills.

When you feel "out of bounds", a few things can help:

Safeguard strategic alignment

As a TLM or a manager playing in your strengths, you can introduce granular controls. Reviewing code, discussing details of a task or project, or even pair programming can inform your perspective to provide advice and give feedback. A manager "out of bounds" can't. My strategy for such situations is to overcompensate on slightly more abstract controls, for instance:

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.

A set of topline and guardrail metrics. Having a well-defined set of indicators that tell you what good looks like helps assess the team's outcomes and can play 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 "operating expense savings ($)". A dip in a metric that matters helps you know something is wrong and prompts discussions into the implementation details you may not understand.

A clear set of goals which are outcome-focused. Quantifiable outcomes or clear ship goals attached to a business outcome are important to any context, but become prohibitive for teams with leaders that are "out of bounds". Context and communication matters even more in such circumstances so you don't mistake outputs for outcomes.

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 highly competent technically. 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 fully moves technical leadership to a senior/staff engineer in the team while only 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 decoupled challenges in the team and delegating them to the most competent person to solve each challenge instead. This approach solves for a few things the two-in-a-box model doesn't:

• Removes bottlenes from the team. There's no one person looking at everything.
• Educates you on the details. Acts as a forcing function to identify who is good at what.
• Creates a level playing field. Gives people similar accountabilities and chances to grow.

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 skewedd towards senior+) which comes with its own set of challenges, but solves uniquely well the technical leadership gap in the team.

Stay grounded in unbiased data

When you believe you are not the best person to judge on whether a technical decision is good or bad for the long run, you delegate – to one or multiple people. But how do you build a cohesive picture of the whole team's state?

It's easy to assume alignment will come from people speaking with each other, especially in a senior-heavy team. However, cohesion only happens with intention. 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, I've seen folks have a lot of success building mechanisms where you gather unbiased data to reach their conclusions. Something as simple as running an anonymous employee survey with linear scale ratings ranging from 1-5 on different topics (e.g. on-call, productivity, etc) can give you a cohesive picture accounting for everyone's opinions and help start the right discussions.

Learn the basics along the way

Going back to the example I gave when I was "out of bounds", managing a ML team when I would undoubtedly fail Statistics 101. The first few months were very intense, but I learned the basics along the way. People hold pride in their craft and will gladly help you understand what they do and why it matters. 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, these were the people who I could count on to uplevel their peers whenever needed.