Why I think a tech lead should keep shipping

I think a technical lead who stops shipping code loses something within a year that is hard to get back, and it is not typing speed. It is the feel for how the system actually behaves, which is different from how the diagram says it behaves, and which is what every good technical decision depends on.

Why I believe this

A lead makes dozens of small calls a week. Is this estimate reasonable, is this abstraction worth it, is this flaky test a real problem. Those calls are made from a model of the codebase, and the model goes stale fast. Code that was clean last spring has a workaround in it now. The build that took two minutes takes nine. A lead who ships a small change every week or two refreshes the model for free. One who only reviews sees the code through the eyes of whoever wrote the pull request.

Shipping also keeps a lead honest about the cost of the standards they set. It is easy to ask for a test on everything when you have not written one in a year. It is harder, and more useful, when you felt how awkward the test harness is last Tuesday.

And there is a quieter reason. People believe a lead who can still do the work. Not because the lead is better at it than they are, which is often not true, but because advice from someone who has shared the same friction lands differently.

What shipping looks like at that level

Not the critical path. A lead who takes the hardest feature becomes the bottleneck and stops leading. I think the right work is small and real, such as the fix nobody has had time for, the tooling improvement, the first use of a new library so the team has a worked example, or the change that touches the part of the system the lead understands least. The point is contact with the codebase, not throughput.

AI coding tools make this easier than it used to be. A lead with two hours can now get a real change through review in that time, and using the tools on actual work is the only way I know to have an opinion about them that is worth anything.

The strongest objection

The time has to come from somewhere, and the honest answer is that it comes from meetings. I think a lead who cannot find two hours a week for the codebase has a calendar problem rather than a role problem, and the calendar is the thing to fix.

Where it stops being true

Above a certain size the job changes. Someone leading several teams through other leads should not be in the code much, and pretending otherwise takes a lane from someone who needs it. For them I think the equivalent is reading code, running the product, and sitting in on a design review as a listener. The feel for the system still matters, and it still has to come from contact rather than reports.

Photo source: https://photos.robertstowe.com/colorado