How I Balance Technical Work and Management

As a senior engineer, my calendar was a consequence of the work. As a manager, my calendar is the work. If I fill it with implementation, the team loses the only person whose job is to create space, make decisions, and develop people. If I fill it only with meetings, I slowly lose the judgment that makes those decisions good.

I used to treat that as a personal time-management problem. It is not. It is a role-design problem. The question is not “how do I still ship as much code?” It is “what technical work still belongs to me, and what belongs to the team?”

When people say an engineering manager should “stay technical,” they often mean “keep coding.” That is the version that quietly turns managers into part-time senior engineers with worse availability. I want a different meaning: I can still read the architecture, smell risk in a design, and hold a real conversation with the tech lead about trade-offs.

I use a simple test before I pick up technical work. Does this make the team faster after I put it down, or only while I am holding it? A spike that unblocks three people is leverage. A pull request that I am faster at writing than anyone else is usually ego wearing a productivity costume.

I stopped hoping for leftover hours. If technical context is part of the job, it has to appear on the calendar the same way 1:1s do. Two protected blocks a week beat a romantic plan to code after 6pm, which mostly produces tired code and a team that learns not to interrupt me until I am already overloaded.

The cleanest rule I have found is an exit condition. I will write a spike this week. I will pair on the first production change. I will not be the long-term owner. Saying that out loud to the team matters more than writing it in a personal note, because it prevents the silent transfer of ownership that happens whenever a manager merges first.

I also refuse to be the merge bottleneck. If every risky change waits for my review, I have not stayed technical. I have centralized risk in the least available person. Tech leads, staff engineers, and a written review bar scale. My calendar does not.

My highest-value technical time is early: problem framing, constraints, and the few choices that are expensive to reverse. The last 20% of implementation is where I am most tempted to “just help,” and where I do the most damage. I steal learning from the people who should own it, and I insert my taste into a design I will not maintain.

I try to enter design reviews with questions, not a pre-written solution. “What happens if this doubles?” “Where is the rollback?” “Who is on the hook at 2am?” Those questions keep me technical without making me the architect of record. The tech lead should win implementation arguments unless the issue is people, risk, or a constraint they cannot see.

Ambiguous availability is how managers become bottlenecks. If people cannot tell whether I want to be in the design, they either over-include me or hide risk until it is expensive. I would rather publish a boring rule.

I still write code. I would not trust a manager who cannot. The difference is purpose. During an incident I will take a well-scoped action if I am the fastest safe pair of hands, then hand ownership back. For a spike, I will explore a risky unknown so the team does not spend a sprint guessing. For teaching, I will pair, not vanish into a branch of my own.

What I no longer do is pick a product story because I miss the dopamine of a green build. That craving is real. It is also how I used to steal the most interesting work from the people I was supposed to grow. If I need a craft hit, I take it on a throwaway prototype or on notes for a talk, not on the roadmap.