I thought becoming a lead would mean making more technical decisions.
That part happened. But it was not the real shift. The real shift was that my job stopped being mostly about the quality of my own output and started being much more about the clarity, confidence, and output of the people around me. The skills that got me the role were not the same skills I needed to be good at it.
What I assumed the job was
My mental model going in was “developer with more scope.” More architecture decisions, more complex debugging, more responsibility for technical direction. All of that turned out to be true. What I massively underestimated was how much of the role is about reducing ambiguity for other people.
A lead spends a lot of time translating: between business asks and engineering work, between project pressure and technical judgment, between individual contributor questions and shared standards. None of that translation is incidental to the work — it is the work. The team’s output depends on how well they understand what they are building, why it matters, and what tradeoffs are being made. When those things are unclear, the team slows down in ways that do not show up as blocked tickets. They show up as implementation decisions that have to be revisited, integration problems that should have been anticipated, wasted work that could have been avoided with one clearer conversation.
I used to think leadership was a more advanced version of individual contribution. It is not. It is a different shape of contribution.
Communication is technical work
The biggest surprise of the first six months: communication is not overhead around the engineering work. At the lead level, it often is the engineering work.
A team loses time not only because code problems are hard. It also loses time because expectations are unclear — who owns which decision, what quality bar applies here, what tradeoff we are making and why, what is blocked and what it is blocked on. Every hour of ambiguity that compresses into one clear conversation at the right moment is an hour that would otherwise compound into days of misaligned work.
Before becoming a lead, I treated communication as something that happened between the real work. Now I track it as seriously as I track technical decisions. A poorly communicated technical direction causes technical waste just as surely as a poorly designed system does. The mechanism is different but the cost is comparable.
This changed what I pay attention to. I am now much more alert to situations where people seem to be proceeding with different assumptions, where the definition of done is ambiguous, or where business context for a piece of work has not been communicated down from the conversation I had with product. Those are places where I can create real leverage by being clear rather than by writing code.
Code reviews changed completely
My early instinct in code review was too narrow. I was still thinking like an individual contributor — trying to protect the codebase from mistakes, catch problems before they got in. That is part of what reviews are for. But it leaves the most valuable part on the table.
Code review at the team level is teaching at scale. The comments I leave in a review are not just quality control on one piece of code. They shape how the reviewer approaches the next ten pieces of code they write without my involvement. A comment that says “this should use a transformer layer” and nothing else passes the immediate gate. A comment that explains why the transformer layer exists, what separation of concerns it enforces, and what breaks down when that pattern is skipped — that is the comment that actually improves the team.
I became less interested in sounding sharp in reviews and more interested in leaving comments that help someone think better. It takes more time per comment and produces better engineers over time.
The performance conversations I was not ready for
No one prepares you well for performance conversations. You can be told what they involve, but the first time you sit down with a person on your team to have an honest conversation about their trajectory, their growth, their gaps, what they need to do differently — you discover that the emotional weight is real and that you cannot improvise your way through it.
Code is concrete. Performance conversations are about progress, confidence, trust, and expectation. They require evidence gathered over time, clarity about what specifically needs to change, and enough care to be honest without becoming vague. Vague feedback sounds kind and accomplishes nothing. Someone leaves the conversation feeling heard but not knowing what to do differently.
The first few of these I did badly — not destructively, but not helpfully either. Too general when I needed to be specific, confusing being supportive with avoiding the hard part of the message. Getting better at them required being more deliberate: having concrete examples, knowing what I was going to say before walking in, and being willing to sit with the discomfort of delivering feedback that was not easy to hear.
Staying close to the code
The risk I felt earliest and most viscerally was drifting too far above the implementation.
If I lose real contact with the codebase — stop reading code carefully, stop maintaining a mental model of the system’s shape, stop understanding how things actually work at the implementation level — then my technical judgment becomes secondhand. I become dependent on what people tell me rather than what I can see. That is dangerous in ways that are hard to detect until something goes wrong.
So even in the first six months I formed a rule: I may write less code than before, but I should not become technically absent. I still do real code review. I still follow significant architectural changes closely enough to have opinions. I still build things when the scope allows. Not to demonstrate that I can still code — that is not the point — but because technical credibility in a lead role requires ongoing contact with the actual work.
What the first six months actually taught me
The role felt slower at first, not because I was doing less, but because the output is less immediately visible. A piece of code ships and you can point to it. Better team judgment, clearer standards, faster onboarding, fewer wasted decisions — those accumulate invisibly and you only see them in aggregate.
What I wish I had known clearly on day one: communication quality is one of the biggest force multipliers in the job. More than code review process or architecture decisions, the biggest leverage you have as a lead is how clearly you reduce uncertainty for the people around you.
Leadership is not a reward for being a strong engineer. It is a new craft that still depends on engineering judgment, but asks you to apply that judgment through people, process, and clarity rather than primarily through your own code.