The hardest part isn’t the architecture decisions — it’s the shift from being measured on your own output to being measured on the team’s. For years, “did well this quarter” meant “shipped a lot.” Then one day it means “the team shipped a lot.” That’s a different reflex, and rewiring it takes longer than anyone tells you.
The math changes
As a senior engineer, an hour of your time produces roughly an hour of output. As a lead, it produces zero — unless you multiply someone else’s hour. A code review that unblocks a junior. A design discussion that prevents a wrong turn. A one-on-one that catches a burnout before it costs a departure. None of it shows up in a commit log.
The instinct is to keep shipping because it feels productive. Fight it. If you’re the one writing all the code, you have a small team of yourself, plus some expensive spectators.
Writing things down
Half of leading is writing. Design docs. Meeting notes. Decisions and the reasons behind them. Not because someone asked for the document, but because your team will build the same thing three different ways if you don’t tell them which one you meant.
The document doesn’t have to be long. Two paragraphs and a rough diagram is usually enough. The point is that it’s written down — a shared reference you can point at instead of re-explaining every time someone joins the project.
Protecting focus
Being a lead means being interruptible. You are, by role, the person who takes the unclear question, the escalation, the vendor call. But everyone else on the team needs stretches of uninterrupted time to do the actual work.
The trade you make: your calendar looks like Swiss cheese so everyone else’s doesn’t have to. That’s the job. If you notice yourself resenting the interruptions, that’s a sign to move some of them to async — not to stop taking them.
When to stay hands-on
There’s no universal rule, but a rough one: stay technical enough to review other people’s work seriously. That usually means writing some code, but not being on the critical path for any feature. Take the tricky bug, the migration nobody wants to think about, the small tool that unblocks the team. Don’t take the six-week greenfield build — someone else needs that experience.
If you stop coding entirely, the reviews get shallow within a year. That’s the actual test.