The Hands-On Engineering Manager: Staying Technical While Leading

There's a persistent debate in engineering management: should managers stay technical or focus purely on people and process? I've landed firmly in the "stay technical" camp, but with important caveats about how to do it without causing problems.

After managing ML platform teams for several years, I've developed a framework for staying hands-on that actually helps rather than hinders the team.

The Problem with Non-Technical Managers in AI

In traditional software engineering, a manager can sometimes get by without deep technical knowledge. The work is more predictable, the patterns are well-established, and senior engineers can self-organize around solutions.

AI and ML teams are different. The technology moves fast - what was state-of-the-art 18 months ago might be obsolete today. LLMs have completely changed what's possible. Vector databases went from niche to essential. New orchestration frameworks appear constantly.

A manager who isn't tracking these changes can't:

Make informed prioritization decisions
Recognize when the team is over-engineering or under-engineering
Have credible technical conversations with stakeholders
Provide meaningful code review feedback
Identify when someone is struggling vs. when a problem is genuinely hard

This doesn't mean you need to be the best engineer on the team. But you need enough depth to earn technical credibility.

The Anti-Patterns to Avoid

Before talking about what works, let me describe what doesn't:

The Bottleneck Manager: Reviews every PR personally, insists on being in every design discussion, can't delegate technical decisions. The team can't move without their approval.

The Weekend Warrior: Does all their coding on nights and weekends, burns out, and ends up resentful of the "management overhead" that prevents them from coding during work hours.

The Architect-in-Exile: Only engages with high-level architecture, has opinions about everything but context about nothing, frustrates engineers with drive-by feedback.

The LGTM Machine: Rubber-stamps everything to seem hands-on while actually contributing nothing.

I've been guilty of all of these at various points. They all stem from the same mistake: treating technical work as competing with management rather than complementing it.

A Framework for Staying Technical

Here's what actually works for me:

1. Own Something Small and Non-Critical

I maintain ownership of specific tools or components that are useful but not on the critical path. Things like:

Developer experience tooling
Monitoring dashboards
Documentation generation
Internal utilities

This gives me real coding time without blocking the team if my management duties take priority for a week.

2. Time-Box Technical Work

I allocate specific blocks for technical work, typically early mornings before meetings start:

6:00 AM - 8:00 AM: Technical work (code, architecture review, learning)
8:00 AM - 12:00 PM: Meetings, 1:1s, cross-functional work
1:00 PM - 3:00 PM: Deep work (could be technical or strategic)
3:00 PM - 5:00 PM: Team support, async communication

The key is treating technical time as sacred as your 1:1s. It's not optional overflow - it's scheduled.

3. Learn Through Code Review

Code review is an underrated way to stay technical. I review PRs regularly, but I focus on:

Understanding new patterns the team is adopting
Catching architectural drift before it becomes debt
Learning about parts of the codebase I don't touch

I'm explicit that my reviews are advisory, not blocking. Senior engineers can merge without waiting for my approval.

4. Pair on Complex Problems

When an engineer is stuck on something genuinely hard, I'll pair with them. This serves multiple purposes:

I learn about the problem space
They get an extra perspective
We build relationship through shared struggle
I can identify if they need more support or resources

The key word is "genuinely hard." I'm not pairing on routine work - that would be micromanaging.

5. Stay Current Through Building

I maintain side projects that use technologies relevant to our work. If the team is evaluating a new LLM framework, I'll build something small with it on my own time first. This gives me informed opinions without slowing down the team's evaluation.

These projects don't need to be complex. A weekend prototype using a new tool teaches you 80% of what you need to know about its tradeoffs.

The Critical Balance: When to Step Back

Staying technical doesn't mean staying involved in everything technical. I've learned to ask myself:

Will my involvement speed things up or slow them down? If the team is already aligned and moving fast, don't insert yourself.
Am I adding perspective or adding noise? Sometimes I have useful context from other teams or past experience. Sometimes I'm just bikeshedding.
Is this a learning opportunity for someone else? If a senior engineer could own this decision, let them - even if you have opinions.
Am I motivated by helpfulness or by FOMO? Be honest. If you're jumping in because you miss coding, that's fine - but own it and find appropriate outlets.

The Payoff

When this balance works, you get:

Technical credibility that makes your management more effective
Better intuition about timelines and complexity
Ability to recognize and develop technical talent
More engaging work that prevents burnout
Stronger relationships with engineers who respect your depth

The engineers I respect most as leaders are the ones who can go deep on technical problems when needed but know when to stay out of the way. It's not about proving you can still code - it's about being a more effective leader because you understand what your team is building.