You've probably worked with one. The engineering manager who gets it. The one you don't have to educate on how long something takes, or what refactoring really means, or why that tiny visual bug is actually hiding a gnarly architectural issue.

These managers can smell tech debt like a bloodhound. They know that a simple one-line fix might actually require rethinking a core abstraction. They ask the right questions without overstepping. They care about the quality of the work, not just the output.

When you're dealing with a technically proficient manager, you're often more productive. Not because they micromanage, but because they understand the terrain. There's no friction in explaining why something matters. They advocate for good engineering practices because they've seen what happens when you don't. They know that rushed work comes back to bite you.

But being technically proficient doesn't mean they're always hands-on. In fact, the best ones know when to step back. They resist the urge to jump into the codebase unless it truly makes sense. Their technical background informs their leadership, but doesn't dominate it.

And they tend to earn the respect of their teams more quickly. Not just because of their previous experience, but because they can participate in technical discussions meaningfully, and they don't waste your time. You trust their judgment.

On the flip side, managers without technical depth face real challenges. They might rely heavily on metrics like story points or PR counts, which can miss the bigger picture. Context becomes harder to provide when technical nuance isn't part of their toolkit.

The gap shows up in different ways. Communication requires more translation. Technical decisions take longer to explain and approve. There's often a mismatch between what seems simple on the surface and what's actually complex underneath.

These managers might focus on velocity and burndown charts as their primary tools for understanding progress. While metrics matter, they tell an incomplete story. Software development is more like creative problem-solving than manufacturing – it's iterative, full of unknowns, and requires constant trade-offs.

When the technical context is missing, teams often find themselves over-explaining rather than building. Estimates get padded for safety. Important technical concerns might get lost in translation or simplified away.

The result is often well-intentioned but misaligned priorities. Teams learn to work around the gaps rather than through them. Innovation slows down when every technical decision requires extensive justification.

I have a strong believe that all managers in a technical area must be technically excellent. You don't need to be the top contributor on the repo, but you need to write/wrote great software and have the experience to back up your decisions. Otherwise, it's like being a cavalry captain who can't ride a horse, you might wear the uniform, but no one's going to follow you into battle.

You don't need a manager to be the best coder on the team. But if they have the technical experience to understand what good work looks like, and the humility to let their team shine, you're in good hands.

Here is Steve Jobs saying something like this 40 years (!!) ago: youtube.com/watch?v=QplyFXgIx7Q.