How do you stay technical enough to be useful as a manager without taking decisions away from your team?

Technical for what, exactly

The question is really about purpose, so answer that first. A manager needs technical depth to do four things: judge whether a plan is credible, ask the question that exposes an unexamined assumption, translate between engineering and the business without losing the substance, and hire and calibrate engineers accurately. None of those require you to be the fastest person in the codebase. All of them decay quickly if you stop engaging with the actual system.

That points at what to keep and what to let go. Keep your grasp of the system's architecture, its failure modes, its data model, its cost drivers, and the shape of the current work. Keep reading design documents and pull requests, and keep attending design reviews. Let go of being the best implementer, the reviewer of record, and the owner of anything on the critical path.

The rule that makes this concrete is to stay one level of abstraction above where you used to work. Where you once knew the code, now know the boundaries and the contracts. Where you once knew the query, now know which datastore is the bottleneck and why. That is deep enough to be useful and not so deep that your involvement becomes a dependency.

Practically, a small amount of real work keeps you honest — a tool the team wants but will not prioritise, a spike, an investigation during an incident, a documentation pass through a subsystem you have not touched. The constraint is that nothing you take on may be needed by a date, because your week will be interrupted and it will be the team that pays. Being on the on-call rotation, where your role permits it, is the single highest-yield way to stay in contact with reality, because it exposes you to the operational cost of decisions rather than to their design.

Your opinion is not the same size as it used to be

The thing candidates most often miss is that this is not a question of self-restraint but of physics. When you were a senior engineer, "have we thought about the write amplification here" was a peer's question. As the manager, the same sentence arrives attached to the person who writes their performance review, and it is heard as a direction. You cannot opt out of that by being casual about it. "Just my two cents" from the manager is never two cents, and prefacing an opinion that way makes it worse, because it denies the engineer the chance to treat it as the instruction they suspect it is.

The remedy is to label the mode explicitly, every time, and to be consistent about what each label means.

Mode	What you say	What the team may do
Question	"What happens to this design if the queue backs up for an hour?"	Answer it; you have no position and are not implying one
Input	"My input, not a decision: I'd weight operational simplicity higher here. Your call."	Weigh it and proceed either way, without justifying themselves to you
Decision	"This one I'm going to decide, and here's why it's mine to decide."	Disagree on record, then execute

Two disciplines make the labels believable. Use the decision mode rarely and name the reason it belongs to you — usually because it commits budget, crosses teams, carries regulatory or contractual risk, or is difficult to reverse. And when you say input, mean it: if the team goes the other way and you relitigate the point next week, everyone learns that input was decision in disguise, and you will never get an honest design discussion again.

Disagreeing with a design as the manager

Start by making the disagreement about the property, not the choice. "I don't think this holds up under a regional failover, and I want to understand how it does" invites the team to demonstrate something. "I don't think we should use that queue" invites them to concede.

Do it in the open, in the design review or on the document, not in a one-to-one with the author. A private objection from the manager cannot be examined by anyone else, so the author has to carry it alone and the rest of the team never sees the reasoning. Public disagreement is more comfortable for you to avoid and much better for the team.

Make the disagreement testable rather than a matter of taste. Ask for the number, the spike, the load test, the failure injection. If you can convert "I think this is wrong" into "here is the experiment that would settle it", you have replaced authority with evidence, which is the whole trick.

Bring in someone whose weight is technical rather than positional — a principal engineer, another team's architect — when the disagreement persists. This is not passing the buck; it is deliberately removing rank from the argument so the technical merits can decide.

And be explicit about reversibility, because it decides how hard to push. If the choice can be undone in a week, let them proceed even when you think they are wrong; the learning is worth more than the rework and your credibility survives being right later. If the choice is expensive to unwind — a data model, a public contract, a vendor commitment, a security boundary — say that this is why you are pressing harder on it.

If after all of that you still have to override, do it once and do it visibly. State the decision, state your reasoning, state what would change your mind, and record it in the design document or an ADR so the reasoning outlives the conversation. Then support the outcome publicly without hedging. An override that is honest is survivable; an override delivered as a series of hints until the team gives up is what destroys trust, because the team knows exactly what happened and has learned that your questions are not questions.

The trap on both sides

There are two failure modes, and candidates usually see only one of them. The obvious one is the manager who cannot let go: reviewing everything, holding the interesting work, and answering technical questions in meetings before the owner can. That team stops making decisions and its senior engineers leave, because there is no room above them.

The less discussed one is the manager who abdicates. Having heard that they should empower the team, they stop reading designs, stop attending reviews, and stop asking hard questions, then discover six months later that the team shipped something operationally unsustainable and that they had no basis to have known. Delegating a decision does not delegate the outcome, and a manager who cannot describe the technical state of their own system is not being respectful, they are being absent. The position to defend is engaged and non-deciding, which is harder than either extreme and is precisely what the interviewer is probing for.