Nobody sits you down and explains it.
One sprint you are an engineer with a ticket list. The next, your title has changed, the same ticket list is still there, and now you are also expected to plan the work, unblock four other people, answer the client, and somehow still ship.
The trap is obvious in hindsight: you keep doing the old job at full intensity and try to add the new one on top. That works for about three weeks. Then something gives — usually your evenings, and shortly afterwards the quality of your reviews.
Here is what actually changes, written as I wish someone had written it for me.
Your output stops being the code you wrote
This is the shift everything else depends on, and it is genuinely uncomfortable.
As an engineer, a good week is measurable. Features merged, bugs closed, a refactor landed. As a lead, your best week might contain almost no commits from you, and be enormously valuable — because you caught a bad data model in a design review on Monday that would have cost the team six weeks in March.
You are no longer paid for what you produce. You are paid for what the team produces, and for what they do not have to redo.
Practically, this means you have to stop assigning yourself the interesting work by default. If you take the hard problem every time, you are the bottleneck on every hard problem, and nobody else on the team ever gets better at them.
Keeping a full ticket load so you still “feel productive”, then doing the lead work at 9pm. Your reviews get shallower, your planning gets rushed, and the team quietly learns that you are not available. Cut your own delivery commitment deliberately — it is a decision, not a failure.
Planning becomes about sequencing, not estimating
As an engineer you estimate your own work. As a lead you have to sequence everyone's, and the hard part is not the estimates — it is the dependencies.
The questions that matter at planning are rarely “how long will this take?”. They are:
What blocks what? If the API contract is not agreed by Tuesday, two people are idle on Wednesday.
What is genuinely unknown? Unknowns are not estimated, they are time-boxed. “Two days to investigate, then we decide” is honest. “Five points” is a guess wearing a costume.
Who is this stretching? Every sprint should have at least one person doing something slightly beyond what they have done before, with you close enough to catch them.
What happens when production breaks? If the sprint is 100% allocated, it is already late.
That last one is the most common mistake I see in new leads. Something urgent always arrives. Plan for it explicitly, or the sprint fails every time and the team slowly learns that sprint commitments are fiction.
Delegation is a specification problem
Everyone tells you to delegate. Almost nobody tells you that most delegation fails for the same reason: the handover was underspecified, so the person either made assumptions you disagreed with or came back to ask so many questions that you may as well have done it yourself.
A good handover answers four things:
| Say | Because otherwise |
|---|---|
| What outcome counts as done | They build something technically correct that does not solve the problem |
| What is fixed and what is theirs to decide | They either ask about everything or change something you needed stable |
| What you already know is tricky | They rediscover a landmine you stepped on last year |
| When to come back to you | They stay stuck for two days out of politeness |
Notice that none of those is “how to implement it”. If you hand over the approach as well as the outcome, you have not delegated — you have dictated, and you will get exactly what you would have written, minus the learning.
Delegate the decision, not just the typing. Otherwise you have made yourself a bottleneck with extra steps.
Technical decisions get a new criterion
As an engineer, the best solution is usually the technically strongest one. As a lead you have to add a second axis: can this team maintain it?
A clever architecture that only you fully understand is a liability, not an asset. If you are on holiday and something breaks, the question is whether anyone else can reason about it. Frequently the right call is the slightly less elegant option that the whole team can debug at midnight.
This is also where you learn to distinguish the decisions that matter. Some are cheap to reverse — a component structure, a library choice in one module. Let people make those and be wrong occasionally; that is how they learn. Others are expensive — the data model, the tenancy strategy, the API contract other teams build against. Those deserve your time, a written rationale, and a real discussion.
A short decision record — what we chose, what we rejected, why, and what would make us revisit it — takes fifteen minutes and saves the same argument being had three times over two years. It also means when someone questions the choice later, you are not defending it from memory.
Code review changes character
Your review is no longer just a quality gate. It is the main channel through which standards spread, and people read far more into your comments than you intend.
Two things I had to consciously change:
Separate the mandatory from the preference. If everything you write sounds equally important, people either rewrite everything or start ignoring you. I label them: a blocking comment says so, a suggestion says “optional”, and a genuine question is phrased as a question rather than a veiled instruction.
Explain the why, once. “Move this to a custom hook” fixes one file. “Move this to a custom hook — the component is now doing data fetching and rendering, so it cannot be tested without a network mock” changes how that person writes the next fifty components. The second comment costs twenty extra seconds.
This should use useMemo.Reads as a correction. Teaches nothing. Invites compliance without understanding.
This recalculates on every keystroke and the list is ~2k rows — worth a useMemo here. Not needed on the smaller lists.Gives the reason and the boundary, so they can judge next time.
Communication becomes a first-class skill
You now sit between people who speak in acceptance criteria and people who speak in stack traces, and part of your job is translation in both directions.
The lesson that took me longest: stakeholders do not want detail, they want certainty about impact. “The vendor eligibility feed arrived malformed so the reconciliation job failed” is accurate and unhelpful. “About 200 members will not see their updated benefits until tomorrow morning. Nobody has lost data, and we have told the vendor” is the same fact, in the form the other person needs.
And in the other direction: when the business says something is urgent, find out what “urgent” means before you move the team. Sometimes it means a client is on the phone. Sometimes it means someone would prefer it this week. Those deserve very different responses.
Mentoring is mostly restraint
The hardest habit to break is answering. Someone gets stuck, you know the answer, and telling them takes eight seconds.
But if you always answer, they learn to ask rather than to investigate. What has worked better for me is to ask what they have already checked, then point at the next place to look rather than at the answer. It takes longer today and considerably less time over a year.
The exception is when something is genuinely blocking delivery. Teaching has a time and place, and 4pm on release day is neither.
What nobody warns you about
You will feel less competent for a while. That is not a sign you were promoted wrongly — it is that your feedback loop got longer. Code tells you within seconds whether it works. A planning decision, a delegation call, a piece of mentoring: those take weeks or months to show whether you got them right.
Sit with that. The instinct to retreat into the codebase because it is the one place you still feel fast is very strong, and it is the main way new leads quietly stop leading.
The short version
Cut your own delivery load on purpose. Do not absorb the new job on top of the old one.
Plan sequences and dependencies, not just estimates. Leave room for the emergency that always comes.
Delegate outcomes and decisions, not instructions.
Prefer the solution the team can maintain over the one that impresses you.
In review, say why, and say which comments are blocking.
Translate impact for stakeholders, not mechanism.
Answer with the next question rather than the answer, except when it is on fire.
You will still write code. You will just stop measuring yourself by it — and the day you notice the team shipping something well without you in the room, that is the actual promotion.
