The question I get asked most often is: how do you stay technical while managing a team of twenty people?
It comes from two groups. Engineers who want to move into management but are afraid of losing their technical edge. And managers who already made the transition and can feel the distance growing between themselves and the codebase. Both groups are right to worry, because the concern is real and the timeline is shorter than most people expect.
Technical leaders do not stop being technical overnight. The drift is much more subtle than that. It happens one calendar invite at a time, one architecture review delegated, one pull request skipped, one quarter spent reading status updates instead of reading code. Then one day you realize that your understanding of the system comes mostly from what other people tell you rather than what you have observed yourself. You are still called a technical leader. Your judgment is increasingly based on historical knowledge rather than current reality.
That possibility worries me more than almost anything else in leadership.
The legitimate competition for technical time
As responsibilities grow, the demands on your time become genuinely important. Hiring, performance reviews, career conversations, roadmap planning, stakeholder management, incident escalations, cross-team coordination, none of those are distractions. They are part of the job. The challenge is that every one of them competes directly with technical depth, and unlike meetings, technical understanding does not show up on your calendar automatically. If you do not deliberately protect it, it disappears slowly enough that you do not notice until the degradation is already significant.
At around twenty engineers, the previous model, reviewing most changes, knowing nearly every technical decision being made, being present for almost every major discussion, stops working. There is simply too much happening simultaneously. Multiple projects in parallel, different teams making decisions independently, architectural conversations in different domains at the same time. Trying to stay involved in everything turns the leader into a bottleneck and slows down the team for entirely the wrong reasons.
The answer is not to stay involved in every decision. The answer is to stay close to the right decisions. That distinction took me real time to learn.
What staying technical actually means
One of the bigger misconceptions about technical leadership is that staying technical means continuing to contribute large amounts of production code. I do not think that is what matters. My goal is not to be the highest-output engineer on the team. My goal is to maintain enough direct contact with engineering work that my judgment remains grounded in current reality rather than historical experience.
For me that means architecture reviews where boundary decisions are being made, design discussions where coupling and ownership are being set, reading pull requests in areas where complexity is increasing, exploring technical proposals before they harden into consensus, and spending hands-on time building actual systems. The emphasis is on direct observation rather than summaries, dashboards, or secondhand explanations.
Reality lives in implementation details. A technical leader who only sees the presentation version of engineering eventually starts leading the presentation version of engineering. Strategy starts sounding clean while landing badly. Estimates look reasonable until the system has to actually run. Architecture makes sense in the diagram until the operational edge cases accumulate. The compressed version strips away exactly what judgment depends on.
Why I still build things
Over the last several years I have kept building outside of normal management work, Algo-000, Bloat, various AI-oriented experiments, trading system infrastructure. These are not hobbies in the casual sense. They are one of the primary ways I keep engineering instincts current.
Bloat forces me to deal with systems problems that do not care about titles: daemon lifecycle, local DNS, certificates, routing, state persistence, process supervision, and update safety on macOS. Algo-000 forces a different discipline, failure handling, graceful shutdown, async boundaries, observability, risk around automation, and what it means for a system to be correct when it is doing real work continuously. AI systems force something else again: they expose how often “works in a demo” collapses under consistency requirements, fallback behavior, prompt drift, tool contracts, and the cost of trusting outputs that are only partially reliable.
Nothing exposes stale opinions faster than direct implementation work. You discover where abstractions break down, which tools are actually productive under pressure, where developer experience still hurts in ways that conference talks do not show, which patterns are still durable and which ones you have been carrying around untested. Leadership creates opinions. Building validates them or destroys them. Both outcomes are useful. I never want to become someone whose technical instincts come entirely from experience that is five years old.
Architecture reviews and risk detection
Architecture reviews are where staying technical pays for itself most visibly. A technical leader who is not grounded in current implementation reality does not add value in architecture review by approving diagrams. Most designs can be made to work. That is rarely the real question.
The useful questions are about what coupling is being introduced, what gets harder six months from now, where operational complexity will show up, what assumptions are hidden inside the design, what the rollback strategy is, and who owns this when the original implementer moves on. Those questions come from concrete experience of watching systems fail in ways the original design did not anticipate. If you are still reading code, debugging systems, and building things, you start to see patterns earlier. If you are no longer close to the work, architecture review becomes performative. You ask safe questions, reward confidence, and approve things that sound organized but are expensive to live with.
Risk detection is what technical judgment actually provides in a review. And risk detection depends on current pattern recognition, not just accumulated experience from several years ago.
Second-hand understanding is dangerous
There is a point in leadership where summaries become seductive. A lead tells you the design is fine. A dashboard shows delivery is healthy. A status update says the migration is on track. A well-spoken engineer explains the tradeoff clearly. All of that is useful. None of it is sufficient by itself.
The danger is not that people are lying. Most of the time they are not. The danger is that summaries compress away exactly the things technical judgment depends on: awkward implementation details, hidden coupling, operational edge cases, fragile sequencing, unclear ownership, complexity disguised as flexibility. When I say I want direct contact with engineering work, that is what I mean, enough first-hand exposure that I am not leading only through translated versions of reality. That does not require micromanagement. It requires not becoming fully dependent on interpretation.
Hiring gets worse when you stop building
One of the most important responsibilities in this role is identifying strong engineers accurately. That requires more than evaluating communication. It requires enough technical depth to distinguish depth from confidence, judgment from memorization, ownership from storytelling, and real experience from well-rehearsed interview language.
The best scorecard is only as good as the technical judgment behind it. If I stop building, stop reading real systems, and stop engaging with current tradeoffs, my follow-up questions get weaker, my calibration drifts, and I start mistaking polished explanations for engineering depth. The fastest way to become a weak technical interviewer is to stop engaging with technology yourself, because then you are testing whether someone can narrate building, not whether they can do it.
Pattern recognition and the smell test
There is a benefit to staying technical that is harder to quantify but that I trust considerably. Sometimes a design review, estimate, or proposal feels wrong before I have found the specific issue. The sequencing feels too clean. The estimate assumes an ideal world. The architecture hides too many responsibilities. The migration plan has no real rollback path. The delivery story ignores what it takes to operate the system after the team moves on.
That feeling comes from pattern recognition developed through years of building systems and observing how they fail. And pattern recognition fades when it is not exercised. Keeping direct technical contact in my week keeps that instinct alive. In leadership roles, those instincts often matter before hard evidence is available.
The cost and the tradeoff
Protecting technical depth means saying no to things. Declining meetings, pushing decisions down to trusted leads rather than joining everything, resisting the temptation to add another coordination sync, accepting that I cannot be equally deep in every domain simultaneously. The goal is not total technical coverage. The goal is not to remain the best engineer in the room. The goal is to remain technical enough that leadership stays grounded in reality.
Some weeks that protected technical time feels expensive. There are always more organizational needs waiting to consume it. But losing technical credibility is more expensive. Teams can tell when leaders are operating from outdated mental models, and the effects compound, architecture quality, hiring quality, and technical strategy all degrade in ways that are not immediately visible but that build up over time.
Earlier in my management path, I thought staying technical would happen automatically if I just cared enough. I do not believe that anymore. At a certain scope it becomes an active discipline. You have to design for it, protect it, and notice when your knowledge is becoming mostly inherited rather than observed. You also have to accept that the form changes. It is no longer primarily direct implementation by default. It is a broader mix of selective hands-on building, close architecture review, technical pattern recognition, and enough implementation contact that decisions stay honest.
That is a different shape of technical depth. But it is still technical depth, and it is the thing that makes leadership real rather than ceremonial.