Leading from inside the codebase

I became a team lead this spring, and the advice came from everywhere: now you stop coding. I didn't, and six months in I know which tickets are still mine.

I became a team lead this spring. The congratulations came with the same piece of advice, from more people than I expected: now you stop coding. Your job is the team, the plan and the meetings, and the code is for the developers.

I understood what they meant. I also kept my editor open. Six months in, this is what that looks like.

What the advice gets right

The lead's time is the thing the team waits on. Someone needs a decision, someone needs a review, someone from the business side needs an answer by lunch. If I'm two hours deep in a feature when those arrive, either the feature waits or they wait, and they wait.

So the advice isn't wrong, it's aimed at the wrong thing. Writing code was never the problem. Being on the critical path is, with a deadline and a head full of state that doesn't survive interruptions.

What I still write

I pick my tickets by one rule now: can this be interrupted ten times a day and still get done?

  • The plumbing. The build config, the CI pipeline, the lint rules, the upgrade of a library nobody wants to touch. Nobody is waiting for it and nobody fights me for it.
  • The spike. Before we plan a feature I don't understand yet, I spend a day finding out how it would go. The result is a throwaway branch and a page of notes, and the plan is better for it.
  • The first one of a pattern. When we introduce something new, a data fetching layer, a form library, a way to structure a module, I write the first one. Not because mine is the best, but because the second, third and tenth will be copied from it, and I'd rather they copied something I'm willing to defend in review.
  • The bug nobody can reproduce. Those need patience and context more than hours, and I have the context.

What I don't take: anything with a date on it that a feature depends on. That goes to someone who can close the door.

Reading more than writing

Most of my time in the codebase now is reading. Pull requests, obviously, but also the code around the thing we're about to plan, the module someone is stuck in, the commit that broke the thing on Thursday. I read the codebase the way I used to read the news, a bit every morning, to know what's going on.

That reading is the part I'd fight for if someone tried to take it away. A lead who stops reading the code can still run a team, for a while, on what they remember. Then the codebase moves on and the plans don't.

Why I keep the editor open

It doesn't hurt when the person reviewing your pull request has merged one this week, but that's not the main reason. The plans, the estimates and the specifications I write are only as good as my picture of the code, and the picture fades fast. You can't plan work you can no longer imagine doing.

I don't want to be the lead who says "that should be a small change" about a module I last opened two years ago. Keeping a hand in is how I stay honest about what small means.

Ask me again in a year, I'll tell you what I got wrong.