Six months into leading a team of four engineers, I realized I’d been optimizing for the wrong things. I was still trying to be the best individual contributor on the team instead of making everyone else better.
The Context-Switching Tax
As an IC, deep work is your primary output. As a lead, interruptions are your job. The sooner you accept this, the better. I tried to maintain 4-hour coding blocks while being a lead and produced mediocre work in both modes. The fix: time-block your calendar intentionally. Mornings for focused work, afternoons for async reviews and 1:1s.
Code Review as Teaching
The biggest leverage point for a lead is code review. Not as a gatekeeping mechanism, but as a teaching tool. I started writing longer, more educational review comments — not just “this should be extracted into a helper” but “here’s why, here’s the pattern, here’s a resource.” The quality of PRs coming in improved over 6 weeks.
One rule I enforce: no “fix this” comments without an explanation. If you can’t articulate why something should change, you shouldn’t be asking for the change.
1:1s Are Your Most Important Meeting
Most leads treat 1:1s as status updates. They’re not. Status belongs in async standup. 1:1s are for career development, unblocking, and building the trust that makes feedback land. I start every 1:1 with: “What’s blocking you that I don’t know about?”
The answers are always more interesting than I expect.
The Uncomfortable Truth
You will write less code. Your output becomes the team’s output. The metric isn’t “how many features did I ship?” but “how much faster is the team shipping because of how I work?”
That shift took me longer than it should have.