When you moved from engineer to manager, nobody took away your technical instincts. You still spot the same architecture problems. You still have opinions about the codebase. But now your days are full of one-to-ones, planning sessions, and status updates, and finding time to open a code editor feels almost impossible. Some managers pull back entirely. Others try to stay hands-on and end up micromanaging without realising it. Most sit somewhere in the middle, vaguely frustrated with both.
The question is not whether to stay technical. It is how to stay technical in a way that helps your team rather than slowing it down.
Why losing the technical thread is a real problem
When you stop engaging with technical work entirely, a few things happen. Your credibility with engineers erodes gradually. You start making decisions based on estimates and reports rather than your own understanding. When your team needs someone to push back on a risky architectural choice or cut through ambiguity, you are not well placed to help.
Fully disconnected manager
Knows the dashboard but not the system.
Technically connected manager
Understands both the people and the work.
This is not about ego or missing the craft. It is about being useful in a way only you can be - someone who understands both the people and the technical context. A manager who understands the work has better one-to-one conversations, spots risks earlier, and can help engineers grow in ways a purely administrative manager cannot. That said, staying technical does not mean writing the most code or sitting on the critical path. The goal is to stay connected in a way that makes you a better manager, not to compete with your team.
What staying technical actually looks like
Most managers assume staying technical means writing features. It does not. There are plenty of ways to stay connected to the work without becoming a bottleneck on delivery.
Ways to stay technically connected
Code review
One or two pull requests a week. See what is actually being built and where engineers get stuck.
Architecture discussions
Contribute a considered point of view, not just a question mark.
Own a small technical area
Docs, internal tooling, or a non-critical service. Something that is yours.
Write technical documents
Decision records, runbooks, technical specs. Keeps you thinking clearly about systems.
Take one sprint ticket
Small and non-critical. Keep the habit without blocking delivery.
Code review is one of the highest-value ways to stay engaged. You see what is actually being built, which patterns are emerging, and where engineers are getting stuck. Reviewing one or two pull requests a week keeps you close to the codebase without pulling you onto the delivery path.
Owning a small, non-critical technical area works particularly well. Maybe it is the team's documentation, internal tooling, or a single service that does not sit on the critical path. Having something that is yours keeps the habit alive and gives the team something useful in return. Writing technical documents - architectural decision records, runbooks, technical specifications - is underrated. It keeps you thinking clearly about systems and gives engineers something concrete to react to and build on.
How to protect time for technical work
Technical time does not appear by accident. If you want to stay connected to the work, you have to block time deliberately and defend that block when pressure builds.
A manager's protected week
Mondays and Thursdays: no recurring meetings before noon.
- Block focus morningsReserve at least one morning each week where no recurring meetings can go. Use it for code review, technical documents, or a small ticket. Treat it the same way you would protect a key stakeholder conversation.
- Take a sprint ticketPick something small and non-critical each sprint. If you are blocking another engineer waiting for your piece, the ticket is too big. The point is to stay in the habit, not to be on the critical path.
- Batch your PR reviewsReviewing pull requests ad hoc throughout the day fragments your attention. Set aside 20-30 minutes in the morning and another block in the afternoon. You review better and interrupt your team less.
- Track technical commitmentsIf you own a ticket or a review commitment, log it as an Action in Manager Toolkit so it does not slip when meetings pile up. Visible commitments are harder to forget.
The harder discipline is protecting that time when things get busy. Technical blocks are always the first to get offered up for an unplanned meeting. Guard them deliberately. Explore Manager Toolkit features for keeping your technical commitments alongside your team work in one place.
Knowing when to step back
The clearest sign that you are overdoing the technical involvement is when your team waits for you before moving forward. If engineers are pausing delivery because they want your code review, or deferring architectural decisions because they expect you to weigh in, you have become a bottleneck. That is the opposite of what you are trying to achieve.
Signs to recalibrate
Engineers wait for your review before merging
Remove yourself from required reviewer lists
Your ticket is on the sprint critical path
Swap for something smaller, or hand it over
You are present in every technical discussion
Delegate some to your senior engineers
Team members ask your approval for small decisions
Explicitly hand ownership back to them
When you notice that pattern, the right move is to reduce your footprint deliberately. Skip the review. Trust the decision. Let the team own it. That is not abandoning your technical identity - it is good delegation. Use your catchups to ask how the work went and what the team learned. That keeps you informed without creating a dependency on your presence at every decision point.
The balance also shifts as your team matures. Early on, when the team is junior or new to the domain, more hands-on technical involvement makes sense. As the team grows in experience, your job moves towards coaching and unblocking rather than contributing directly. Adjusting your technical footprint over time is not retreating - it is good management. The IC-to-manager transition never fully ends. You keep recalibrating as your team changes.
Frequently asked questions
Stay organised as a technical manager
Track your commitments, catchups, and team work in one place. Free to start.