The Engineering Manager's Depth Problem

One of the hardest transitions from Senior Engineer to Engineering Manager is not learning how to manage people. It is learning how to step back.

As a developer, being close to the problem is usually a strength. You dive deep, understand the details, find the bottleneck, and solve it.

As an Engineering Manager, that same instinct can become a problem.

You still need technical context. You still need to understand what the team is building. You still need to be able to challenge decisions and help when something goes wrong.

But your job is no longer to be on the front line all the time.

You need to move two steps back and see what people working directly on the problem cannot see.

Over time, I have started to think about this as a problem of depth.

There are two questions:

• How deeply do I need to understand this problem?
• How deeply should I get involved in solving it?

Those are not the same thing.

Context is supposed to decay

As a manager, I gradually lose implementation-level knowledge. I think that is normal.

The alternative would be spending enough time in every codebase, every pull request, and every technical discussion to maintain exactly the same context as the developers working on it every day.

That is not realistic, and I don’t think it is a good use of an Engineering Manager’s time.

I would probably be worried if I knew every implementation detail in every system my team owns. It might mean I am spending time in the wrong place.

Losing detailed technical context is a natural consequence of taking responsibility for people, product, strategy, and organization.

The goal is not to prevent it.

The important skill is different:

How quickly can I get the context I need?

I don’t need every detail. I need the ability to recover context.

For me, the fastest tool is usually to ask another engineer. A fifteen-minute conversation can be more valuable than an hour spent reading documentation.

I normally grab a piece of paper or stand at a whiteboard and start drawing the process myself.

I ask questions.

• What happens first?
• How many items do we process?
• How is the work divided?
• Do we get additional information from external systems?
• Do we run one job or multiple jobs?
• Where do we load the data?
• What happens before we send events to the next system?

I don’t ask the developer to prepare a perfect architecture diagram for me. The act of drawing it myself forces me to understand it.

Recently, we had performance problems in one of our systems. The team had already been working on the problem for some time, and one of the engineers was clearly getting tired of it.

We knew Event Hub was involved in the bottleneck, but I wanted to understand the process around it.

We talked through the flow. I wrote down the configuration values and constraints. Then I spent some time checking Event Hub limitations and thinking through the problem independently.

The important part turned out not to be a particular class or implementation detail. It was a configuration constraint that had become outdated.

We had made the whole process faster over time, but some of the configuration had not changed with it. Once we adjusted those values to match the new processing pace, the throttling on Event Hub went away.

I didn’t need to know every class or method in the application. I needed the right model of the system.

AI makes context recovery much cheaper

There is also a new tool available to managers that did not exist a few years ago.

AI coding agents.

If nobody is immediately available, I can point an agent at the repository and ask it to explain the flow.

I can ask:

• where a process starts,
• which components participate,
• where batching happens,
• which configuration controls concurrency,
• which components call external services,
• which code paths can create a bottleneck.

This does not replace talking to the team. It gives me another source of information.

In fact, I find it useful as a cross-check.

I have my own model of the system. I have what the team tells me. And I can independently inspect the codebase with an agent.

Agents can also do this asynchronously. I can prepare for an architecture discussion or incident without spending the first hour manually navigating an unfamiliar repository.

That changes the context problem significantly.

An Engineering Manager no longer needs to choose only between “read all the code” and “trust whatever someone tells me.”

There is now a useful middle ground.

Staying technical does not mean owning the implementation

I still code. I enjoy building things, and I think coding regularly is useful for an Engineering Manager with a technical background.

It keeps my skills fresh, helps me understand the development process, and exposes me to the same friction that developers experience.

But I have one important rule when taking development work:

• Do I actually have time for this?
• Will I block the team if it takes longer than expected?

The second question is especially important.

Managerial work is unpredictable. A production incident happens. Someone needs help. A stakeholder meeting appears. A people-related topic suddenly becomes more important.

If my development task is on the critical path, my interruptions become the team’s interruptions.

That is a bad trade.

So if I code, I prefer independent tasks, small improvements, experiments, or things where the team can continue without waiting for me.

Being able to recover technical context makes it easier to step into problems when needed.

But it also creates another risk.

Just because I can get involved does not mean I should.

The dangerous part of being technical

The biggest risk for me is not losing technical context. It is enjoying technical problems too much.

I like diving deep. I like debugging complicated issues. I like finding a solution when something is not working.

The problem is that solving these problems is no longer necessarily my responsibility.

And even when I can solve something faster than someone on the team, it does not mean I should.

This is where the second question about depth becomes important.

It is not only:

How deeply do I need to understand the problem?

It is also:

How deeply should I intervene?

Sometimes helping means not solving the problem

This is probably one of the least intuitive parts of technical leadership.

You see someone struggling with a problem that you think you can solve.

Your instinct says: help.

But helping can mean different things.

Sometimes I step in. Sometimes I suggest an idea. Sometimes I only ask questions. And sometimes the best thing I can do is give the person more time.

I try to use the lightest intervention that is likely to work.

For larger problems, I like to introduce checkpoints.

For an urgent incident, I might set the checkpoint one or two hours out. For something less urgent, it might be half a day or a day.

The idea is simple:

Work on the problem independently, then we regroup.

This avoids two extremes.

The first is leaving someone alone with a difficult problem for too long.

The second is pulling five people into the problem immediately and preventing the person from actually thinking.

When we regroup, we can compare ideas and decide whether the current direction still makes sense.

If that is not enough, I can go deeper.

I can suggest a direction. We can investigate the problem together. And if urgency or risk requires it, I can step in directly.

The job is not to avoid intervening.

It is to choose the right depth.

I also try not to be the first person speaking during technical discussions.

If I immediately propose a solution, there is a good chance the conversation becomes a discussion of my solution.

Sometimes being quiet for another minute creates much better ideas.

The real shift is from solving to seeing

Jocko Willink describes a similar leadership skill as detachment: stepping away from the immediate problem far enough to see the wider situation.

I think the same principle applies to Engineering Management, with one important addition.

You need to be able to move in both directions.

You need to step closer when the situation requires more technical context. And then you need to step back again before you become part of the problem you were supposed to observe.

Detachment does not mean becoming disconnected from the work. Step too far away and you lose the context required to make useful decisions.

But stay too close for too long and you lose the wider perspective.

The team might be focused on a performance problem. I need to see the performance problem, but also whether the engineer working on it is exhausted.

The team might be designing the best architecture. I also need to see whether we are solving the right product problem.

Everyone might be focused on delivering this sprint. Someone needs to think about what happens three months from now.

That wider perspective is part of the job. And it is very easy to lose it when you are deep inside a debugger.

The goal is not to maintain all the context.

It is to become good at recovering the context that matters.

Ask good questions. Understand the important flows. Know where the boundaries are.

Use diagrams. Use metrics. Talk to engineers. Use AI agents to explore the code when it helps.

Dive deep enough to understand the problem.

Intervene only as deeply as the situation requires.

And then step back again.

Because the Engineering Manager’s job is not to know everything the team knows or solve every problem they face.

It is to get the right context quickly enough to make a good decision, ask a useful question, or help the team move forward — without taking the problem away from them.