Out of bounds

Most engineering leaders start as technical experts who took on people responsibilities. Because software engineering is very broad, at some point, every one of them will lead teams in domains they don't deeply understand.

I was a web engineer most of my career. I still remember the first ML team I had to lead. It came with a lot of learning and a lot of self-doubt.

The self-doubt made sense: engineering leaders aren't just accountable for people. They're functional leaders, accountable for technology — even in domains where they lack confidence. The more senior you get, the more domains you span.

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

Strong strategic alignment

When playing to your strengths, you can rely on granular controls — reviewing code, discussing task details, pair programming. When you're out of bounds, you can't. Instead, ensure you nail more abstract controls:

• A clear longer-term vision. Tunnel vision is even more harmful to teams without a strong technical leader. How systems are built impacts strategic alignment, so having a clear target condition for a longer timeframe (e.g. 2-3 years) and communicating it well helps the team make future-proof decisions.
• North-star and guardrail metrics. A well-defined set of indicators showing what good looks like helps assess outcomes and drives prioritisation. For instance, choosing between 1% more availability or 10% fewer false positives is easier when both map to the same business outcome, like "operating expense savings ($)". A dip in a metric that matters tells you something is wrong and prompts the right discussions.
• Outcome-focused goals. Quantifiable outcomes or clear ship goals tied to business outcomes matter in any context, but become essential when leaders are out of bounds. Without them, you risk mistaking outputs for outcomes.

These abstract controls require understanding the business more than the internals of the systems. Your technical gaps matter less that way.

Situational technical leadership

Engineering leaders should share technical leadership duties even when highly competent — if only to avoid becoming a bottleneck. It becomes imperative when you can't make sound technical decisions yourself.

One approach is the TL + EM two-in-a-box model, where the leader hands most technical leadership to a senior/staff engineer and keeps only people management. I'm not a fan. It doesn't remove the bottleneck — it splits it into two bottlenecks with added alignment overhead.

A better approach: identify decoupled challenges and delegate each to the most competent person. This solves what two-in-a-box doesn't:

• Removes bottlenecks. No single person reviews everything.
• Educates you on the details. Forces you to learn who is good at what.
• Creates a level playing field. Gives people similar accountabilities and chances to grow.

To make this work, you may end up with an inverted triangle-shaped team (skewed towards senior+). That has its own challenges, but it uniquely fills the technical leadership gap.

Survey your people

When you delegate technical judgment, how do you build a cohesive picture of the team's quality state?

Don't assume alignment will emerge from people talking to each other. Cohesion requires intention. Left to form organically, it gets biased by a few vocal people — often the ones you gave the most responsibility.

Without the competence to verify and inspect, build mechanisms that gather unbiased data. Something as simple as an anonymous survey with 1-5 ratings on topics like on-call burden or productivity gives you a picture that accounts for everyone's perspective and starts the right discussions.

Learn the details along the way

Back to my ML team example. The first few months were 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.

I also developed an eye for identifying people who could explain the basics well. As it turns out, those were the same people I could count on to uplevel their peers.