The Manager Who Still Writes Code

A week from now I'll hit one year as an engineering manager. If you'd told me six months ago that the second half of that year would involve writing more code than the first, I would have assumed something had gone wrong. It didn't. AI happened.

The first few months of management were what you'd expect. I stepped back from the codebase, focused on people, process, rituals. Sprint planning, 1:1s, hiring. Hard conversations too, including letting people go. The terminal gathered dust. That felt like the right thing to do.

Then I started experimenting with AI tools. First for small things: drafting retro summaries, scaffolding docs. But the more I used them, the more I realized I could build things again. Not on the critical path (my team owns that), but side projects. Internal tooling. Experiments. Things that would have taken me weeks before, shipped in a few days.

That's when the merge conflict started.

The Tension

My calendar says I'm a manager. My terminal history says otherwise. On any given day I'm switching between a 1:1 about someone's career growth and a Claude Code session where I'm prototyping something nobody asked for. Both feel productive. Both feel important. Fitting them in the same day is the hard part.

I've also been pushing AI adoption with my team. Not forcing it, but making space for it. Sharing what I've learned. Encouraging experiments. I believe this matters, even when the results are messy and the ROI isn't obvious yet.

The Resolution (There Isn't One)

I don't think you resolve this conflict. You just get better at managing the context switches. Some days the manager branch wins. Some days the engineer branch wins. The trick is not feeling guilty about either one.

One year in, I'm writing more code than I expected, reading more about leadership than I ever did as an engineer, and spending an unreasonable amount of time talking to an AI. I still don't know if I'm doing this right. But the merge conflict is what keeps it interesting.