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 enough technical context to understand what the team is building, 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 a few steps back and see what people working directly on the problem may not see. Over time, I have started to think about this as a problem of depth. There are really two questions: How deeply do I need to understand this problem? And 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, pull request, and technical discussion to maintain the same context as the developers working there every day.
That is not realistic, and I don’t think it would be 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 could mean that I am spending time in the wrong place instead of focusing on people, product, strategy, and the wider organization.
So I don’t think the goal is to prevent technical context from decaying. The more useful skill is being able to recover the right context when I need it.
For me, the fastest way to do that is usually to talk to 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 while asking questions: What happens first? How is the work divided? Where does the data come from? Which external systems are involved? Where do we batch work? What happens before we send the result 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 build the model in my own head.
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 rather than start by looking at individual classes.
We talked through the flow. I wrote down the important configuration values and constraints, then 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 coding agents have made this kind of context recovery easier as well. If nobody is immediately available, I can point an agent at a repository and ask where a process starts, which components participate, where batching happens, which configuration controls concurrency, or which code paths call an external service.
I don’t see this as a replacement for talking to the team. It is another source of information and sometimes a useful 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. That gives me a useful middle ground between reading an unfamiliar repository manually and relying only on somebody else’s explanation.
Being technical does not mean owning the problem
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 some of the same friction that developers experience.
But when I take development work, I try to answer two questions first: do I actually have time for it, and will I block the team if it takes longer than expected?
The second question matters more.
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 I prefer independent tasks, small improvements, experiments, or work where the team can continue without waiting for me.
There is also a less obvious risk. The biggest danger for me is not losing technical context. It is enjoying technical problems too much. I like diving deep, debugging complicated issues, and finding a solution when something is not working. But solving these problems is no longer necessarily my responsibility.
Even when I think I could solve something faster than someone on the team, that does not mean I should.
This is where the second question about depth becomes important. Understanding a problem deeply and intervening deeply are two different decisions.
When I see someone struggling with a problem, my first instinct is usually to help. But helping can mean different things. Sometimes I step in directly. Sometimes I suggest a direction. Sometimes I only ask questions. And sometimes the most useful thing I can do is give the person more time to think.
I try to use the lightest intervention that is likely to work.
For larger problems, I often use checkpoints. During an urgent incident, that might mean working independently for another hour and then regrouping. For something less urgent, it might be half a day or a day. This avoids two extremes: leaving someone alone with a difficult problem for too long, or immediately pulling several people into it and removing the space needed to think.
When we regroup, we can compare ideas and decide whether the current direction still makes sense. If it does, the engineer continues. If it does not, I can go deeper. We can investigate together, I can suggest another direction, or, if urgency and risk require it, I can step in directly.
The goal is not to avoid intervention. It is to choose the right depth.
The same applies during technical discussions. I try not to be the first person speaking. If I immediately propose a solution, there is a good chance the discussion becomes a discussion of my solution. Sometimes staying quiet for another minute produces better ideas and gives someone else the opportunity to take ownership of the decision.
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.
Sometimes I need to step closer because I don’t have enough technical context to understand what is happening. I may need to talk through the architecture, inspect metrics, look at the code, or work through the constraints myself. But once I have enough context, I need to step back again before I become part of the problem I was 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. Stay too close for too long and you lose the wider perspective.
The team might be focused on a performance problem. I need to understand that problem, but I also need to notice whether the engineer working on it has been fighting it for three days and is exhausted.
The team might be designing the best architecture for a feature. I still need to ask whether we are solving the right product problem.
Everyone might be focused on delivering this sprint. Someone still 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 when you are deep inside a debugger.
I don’t think an Engineering Manager needs to maintain all the technical context the team has. I need to be able to recover the context that matters when the situation requires it: by talking to engineers, drawing the flow, looking at metrics, inspecting the code, or using an AI agent when that helps.
Then I need to decide what to do with that context. Sometimes the right response is a decision. Sometimes it is a question, a suggestion, or another hour of space for somebody else to work through the problem.
That is the balance I am still trying to get better at: going deep enough to understand what is happening, but not automatically going deep enough to take ownership of solving it.
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.