Staying technical without taking ownership back from your team
How engineering managers can keep their technical judgment current without becoming the team's main engineer.
Moving into engineering management changes your relationship with technical work. It does not remove it.
I still care about how systems are designed, where risk is building, and whether a technical choice will make the product easier or harder to change. I also know that the engineers on my team need room to own those choices. If I step back too far, my judgment can slowly lose touch with the work. If I step in too often, I can become the team’s main engineer again.
That balance is not fixed. It changes with the team, the company, and the kind of problems in front of us. My preference is to stay technical, but with a different goal than I had as an individual contributor.
I do not need to produce the most code or have the final answer. I need enough current knowledge to ask useful questions, understand trade-offs, and help the team make sound decisions without depending on me.
Staying technical is not the same as staying hands-on
When managers worry about losing their technical skills, the first answer is often to take a coding task. Code is familiar, and a finished pull request gives clear proof that we can still do the work.
Being hands-on can help, but it is only one way to stay technical. It may not even be the best way for every management role.
A manager can write code every week and still miss the larger technical picture. They may know one part of the system deeply while losing track of the choices, risks, and links across the rest of it. Another manager may write little production code but stay close through design reviews, incident follow-ups, technical plans, code reading, and regular talks with engineers.
The useful question is not, “How much code did I write?” It is, “Is my technical judgment based on how the system and team work today?”
The answer will depend on the role. A manager leading a small team may have a clear hands-on part of the job. A manager leading several teams may create more value by connecting technical choices across a wider area. A new team or a serious incident may need closer support for a while. A stable team with strong technical leadership may need much less.
Staying technical matters to me because it helps me understand what the team is carrying. It helps me see when a delivery concern is really a system concern, when short-term pressure is creating long-term cost, and when an engineer needs context rather than an answer.
That is a different kind of technical contribution. It should make the team’s work clearer, not move the work back to me.
Let the team guide you into the details
An engineering manager sees a broad set of concerns, but the engineers doing the work hold more of its daily technical context.
They know which part of the code is difficult to change, which test fails for reasons nobody has fixed yet, where a simple request hides a hard edge case, and which earlier decision is shaping the current one. A manager can miss these details quickly because attention is divided across people, delivery, hiring, planning, and work outside the team.
The answer is not to pretend that the gap does not exist. It is to ask the team to guide you.
I find it useful to start with questions such as:
- What part of this problem is easy to misunderstand from the outside?
- Which limits are shaping the options?
- What have you already tried or ruled out?
- Where do you feel least sure?
- What decision or help do you need from me?
These questions help me rebuild enough context without asking the team to teach me the whole system every time. They also show where my broader view may be useful. I might know about a product change, another team’s plan, or a company limit that changes the trade-off.
This works best as a two-way exchange. The team brings depth from the work. I bring context from outside it. We should be able to improve the decision together without acting as if either view is complete on its own.
There is also a healthy amount of trust in saying, “You have more context than I do. Walk me through your thinking.” A manager does not lose credibility by learning from the team. Trying to hide a context gap is more likely to weaken it.
Remember that your opinion arrives with extra weight
A manager can enter a technical discussion with good intent and still close it too early.
The title changes how people hear an idea. A manager may say, “This is only a suggestion,” while the team hears a decision. An engineer may have a better approach but decide that disagreeing is not worth the risk. Nobody has been told to stop talking, yet the role has created quiet pressure.
This is easy to miss because the meeting may look calm and the team may move quickly. The cost appears later, when people bring fewer ideas, wait for the manager’s view, or stop feeling full ownership of the result.
I try to reduce that pressure in a few ways. I ask for other views before giving mine. I make it clear whether I am asking a question, sharing an option, or making a decision that belongs to my role. When an engineer owns the decision, I say so. If I have a strong concern, I explain the risk I see instead of turning my preferred solution into an order.
Speaking last can help, but it is not enough on its own. The team also needs to see that a different idea can win. If every discussion still ends with the manager’s first preference, people will learn that the invitation to disagree is only polite wording.
Technical knowledge is most useful when it raises the quality of the discussion. It becomes harmful when the team’s job is to confirm what the manager already believes.
Create a safer way to make decisions
Good technical judgment should not live only in one person’s head, including the manager’s.
The team needs simple ways to make the reasoning behind a choice visible. A short technical plan can state the problem, the limits, the options considered, and the risks. An architecture decision record can capture a choice and why it was made. Clear review steps can show who should give input and who owns the final call.
The value is not the document itself. The value is the shared thinking it supports.
Without that shared record, a technical discussion can depend on who remembers the most history or speaks with the most confidence. With it, the team has something concrete to question. Assumptions are easier to find. New facts can be compared with the reasons behind the old choice. People who were not in the meeting can still understand what happened.
These tools also give a manager a better place to contribute. Instead of reviewing every line of code or giving an answer in a meeting, I can look at the shape of the decision:
- Is the problem clear?
- Are the product and system limits visible?
- Have we named the main risks and trade-offs?
- Is the choice easy to change if our assumptions are wrong?
- Who owns the decision and the follow-through?
This turns judgment into a team habit. It also makes it easier for the team to make good choices when I am not present, which is a better sign of leadership than being included in every choice.
Keep practice close and the critical path clear
Technical skill needs practice. Reading and discussion help, but I still want time to build things.
The safest place for much of that practice is away from the team’s critical path. I can use a side project to try a new tool, build a small prototype to test an idea, or explore a part of the stack without making delivery depend on my calendar. This keeps the feedback loop of building, failing, and learning while leaving the team’s ownership clear.
There can still be good reasons for a manager to work in the team’s code. A small fix can help us understand the developer experience. Pairing with an engineer can teach us both something. A short investigation can answer a question that would otherwise block a plan.
The task matters less than the boundaries around it. Work is safer when it is small, easy to stop, visible to the team, and owned through the team’s normal review process. It becomes risky when the manager quietly takes the hardest task, owns a core area, or becomes the only person who can finish a release.
A manager’s calendar is often broken into small pieces and can change without warning. Work that looked helpful on Monday can become a bottleneck after two days of interviews, planning, and urgent people work. The team should not have to wait for a manager to find coding time before it can move.
If I take on a task, I need a clear answer to a basic question: can the team continue if I am pulled away tomorrow?
If the answer is no, the task probably belongs with someone whose main job gives it the attention it needs. If an urgent situation leaves no other choice, I should pair, write down the context, and plan the handoff from the start.
Make time for the responsibility you actually have
It is possible to overthink this balance until staying technical becomes another source of guilt.
Managers do not need to follow every new tool, join every design review, or prove that they could still do each engineer’s job. The goal is to keep the level of judgment the role really needs.
If technical judgment is part of the role, it needs real time. That could mean a regular block for reading code, joining one design discussion each week, reviewing incident notes, following a change from idea to release, or building outside the main product. Small and steady practice is more useful than taking a large task every few months to prove a point.
If there is never time for any of this, the first step is not to push it into evenings or take ownership from the team. It is to make the expectation clear. What technical responsibility does the role have? Which other work should move to leave room for it? What level of detail does the team need from its manager?
Sometimes the honest answer is that the role no longer needs regular hands-on work. That does not have to mean losing all technical depth. It means choosing practices that fit the scope instead of holding on to an older version of the job.
The simple approach I keep returning to
My own approach is basic: I still build things, I join technical discussions with care, I listen, and I read a lot of code.
Building keeps me close to the real work of turning an idea into a working product. Selective discussions help me follow the decisions with the largest effect without placing myself in the middle of every one. Listening lets the team’s context lead. Reading code shows me what the system has become, not only what a plan said it would become.
I expect this approach to change as my role changes. The useful balance for one team may be wrong for another. What I want to keep is the line between staying connected and taking control.
I should be close enough to understand the questions, but I do not need to be the person who answers all of them. I should be able to challenge a risky choice, but the team should not wait for my approval by default. I should keep practicing, but the product should not depend on the small gaps in my calendar.
The goal is not to be known as the most technical person on the team. The goal is to help build a team that can make strong technical decisions, explain them clearly, and carry them forward without needing the manager at the center.