The first surprise of becoming a lead was not that I had less time to code.
It was that I could work all day, solve problems nonstop, and still struggle to explain what I had actually produced.
As a senior individual contributor, my work had a clear center of gravity. I picked up technical problems, made decisions, wrote code, debugged issues, shipped features, and moved on. Even when the work was messy, the feedback loop was immediate. I could point to the output.
Moving into a lead role changed that almost overnight.
At this stage of an engineering career, the question is often not just whether to grow, but in which direction. Many experienced engineers start weighing paths like principal, staff, tech lead, or people management. In my case, stepping into a lead role with direct reports forced me to rethink not only my responsibilities, but my definition of impact.
The hard part was not coding less. It was accepting that my job was no longer to maximize my own output. It was to increase the quality, confidence, and effectiveness of other engineers without taking away their ownership.
Before leading, output was personal
Before taking on direct reports, I worked in a very independent setup. I was the only frontend and mobile developer on the team. That gave me a lot of ownership, but very little support structure around my own work. There was no natural peer review in my immediate environment, so most of the time I had to figure things out through experimentation, reading, and personal study.
In practice, around 95% of my time went into coding. My regular meetings were mostly limited to scrum ceremonies. Outside of that, my calendar was dominated by maker time. I could disappear into a problem for hours, make progress, and come back with something concrete.
That setup had its own difficulty: visibility. Because my work lived in a domain others around me did not directly share, it was not always easy for the team to judge the complexity or quality of what I was doing. But even with that challenge, the structure of the role was clear. I was measured mostly by direct output.
That changed the moment I became responsible for other people’s work too.
The job became indirect
There was a stretch early in the transition where the new reality became impossible to ignore.
My days no longer belonged to one problem at a time. They were split across reviews, questions, meetings, mentoring, and my own delivery. I was busy from start to finish, but it was a different kind of busy than I was used to. The work felt fragmented, indirect, and harder to measure with the old IC lens.
The moment that captured this best for me happened during code review.
There were times when I looked at a task from a junior engineer and thought: if I started this from scratch, it would be faster than reviewing it carefully.
And honestly, sometimes that was true.
I could see the problem quickly. I knew how I would structure the feature, which abstractions I would avoid, and what I would test. From a short-term perspective, rewriting it myself might have saved time.
But that was exactly where my old instincts stopped being enough.
If I solved the problem myself every time it was faster, then I was optimizing for my own speed, not for the team’s long-term strength. I would get the local win and lose the bigger one. The junior engineer would lose the chance to build judgment. Ownership would quietly drift back to me. Over time, I would train the team to depend on my acceleration.
That was the first real shift. Being the fastest engineer in the room was no longer the point.
The second shift was more psychological. Before I stepped into the role, I thought the hardest part would be protecting the team from external pressure. That matters, and it is real work. But for me, the harder part turned out to be motivating other people and trusting them long before they had fully proven themselves.
That was the real mind shift for me: my success would now be counted through the success of other people, not only through my own accomplishments.
What changed in practice
Time
The most visible change was my calendar. Before leading, most of my time was uninterrupted coding time. After taking on direct reports, I had far less maker time and far more coordination, mentoring, and review work.
Even estimation changed. As an IC, I mostly estimated based on my own pace. As a lead, I had to estimate based on the pace of junior developers, not mine. That meant evaluating not only technical scope, but also current experience, likely guidance needed, review cycles, and how much ambiguity someone could absorb without getting stuck.
Decisions
One thing I did not expect was how much the role would sharpen my need to think two or three steps ahead.
Over time, I noticed that my decision-making improved in a different direction than before. I started reading situations more carefully. Not just the technical details, but the room itself. I paid more attention to whether someone was blocked in a technical sense or in a confidence sense, whether a problem was local or a symptom of something bigger, and whether I should answer directly or ask a better question first.
I still used technical judgment all the time. Product knowledge and the instinct to simplify remained valuable. But the job increasingly required different decisions: when to intervene, when to wait, when to protect someone from pressure, and when to let them feel the weight of ownership.
A lot of the role lives in that tension. Intervene too early and you weaken learning. Intervene too late and you create frustration. Protect people from every mistake and they do not build resilience. Leave them alone too much and they can lose confidence.
Emotional load
My stress definitely increased. As an IC, the scope of what I carried was narrower, even when the problems were hard. As a lead, I had to think not only about my own work, but about other people’s work, their trajectory, their confidence, their delivery, and how external pressure affected them.
At the same time, my energy was high because the role was new and meaningful. It stretched me in ways I had not experienced before. There was something motivating in realizing that my work could have a multiplying effect.
The hardest thing to evaluate was accomplishment. Leading does not give the same immediate reward loop as building software directly. You can spend a full day removing friction, clarifying decisions, coaching someone, and setting better direction, and still feel like you have nothing concrete to show for it.
If you keep judging your value only by direct output, the role will feel unsatisfying even when you are doing the right work.
The mistakes I made early
Most of my early mistakes came from trying to solve leadership problems with senior-IC reflexes.
The first was that I did not protect my own time. I let my day become too reactive. I tried to help anyone the moment they asked for help, which meant constant interruptions, too much context switching, and lower-quality focus. I wanted to be supportive, but I was quietly turning myself into a bottleneck.
The second was that I did not ask the right questions in mentoring moments. I often knew the answer too quickly. The problem was that fast answers do not automatically create understanding. In some cases, I would explain what should change in the code, but the junior developer still would not fully understand the deeper reason behind the decision. The “what” got transferred, but not the “why.”
The third was that I sometimes tried to hide the mistakes of junior developers by fixing bugs myself because I thought it would be faster. Locally, that sometimes worked. Systemically, it was a bad habit. It reduced ownership, weakened the learning loop, and kept too much of the team’s problem-solving gravity centered on me.
What started working better
Things improved when I stopped treating code review and pair programming as pure quality control and started using them more intentionally as teaching tools.
Instead of focusing only on what was wrong in the current implementation, I started trying to shape how people approached the work in the first place: how they thought about a feature, how they structured the design, how they chose an implementation path, and how carefully they tested it.
That required more patience from me, but it also produced better results.
There was a point where I could clearly see that the time spent reviewing and pairing was paying back. Junior developers were not only submitting better code. They were approaching problems with a better mindset. They were simplifying more naturally. They were thinking more carefully about tradeoffs and testing. The improvement was not only in output, but in judgment.
Another important shift came from the non-technical side of the role. I had the experience of helping a junior developer through a difficult period, making that person feel stronger about their abilities, and giving them enough safety to make mistakes without feeling crushed by them. That changed more than I expected. Confidence improved. The way that person showed up improved too.
That taught me something I knew intellectually but had not fully felt before: a lead does not only influence how work gets done. A manager also influences the emotional conditions under which people are willing to grow.
Code review is harder in the AI era
There is one part of this role that feels especially difficult right now: code review in the age of AI.
AI makes it much easier for someone to produce code that looks plausible, structured, and polished without fully understanding what it does or why it is written that way. That makes review harder, because the challenge is no longer only about syntax, style, or whether the happy path works. The deeper question is whether the engineer behind the code actually understands the tradeoffs, the design decisions, the edge cases, and the testing strategy.
One of the clearest moments for me came during a code review on a refactor that was technically working. The PR passed, the behavior looked fine, and nothing was obviously broken. But once I looked beyond the surface, I could see that some dirty solutions had been used to force the result instead of improving the design. When I started asking basic questions about the reasoning behind the choices, the discussion became more revealing than the code itself. The issue was not whether the refactor worked. It was whether the engineer really understood why it worked, and whether they could defend the tradeoffs behind it.
That changed how I think about code review, especially now. In many cases, the better move is not only to comment on the PR, but to pair earlier and shape the thinking before the code hardens into place.
That is where the challenge becomes real. It is hard to make someone care about fundamentals when AI can generate something that looks like progress. But without fundamentals, it is very difficult for an engineer to truly evaluate AI-generated solutions or review them critically.
To me, that means fundamentals matter more, not less.
The goal is not to reject AI. The goal is to help engineers build enough judgment to use it critically, to see when generated code is weak, overcomplicated, fragile, or simply wrong.
I have also noticed the asymmetry this creates in review itself. My own PRs often receive very few comments, or none at all, from junior engineers. I do not take that as proof that the code is flawless. I see it more as a sign that review confidence and technical depth are not evenly distributed yet. That is exactly why mentorship still matters so much, even as tooling gets more powerful.
What I would tell someone making the same switch
If I had to give practical advice to a senior engineer about to become a first-time manager, I would keep it simple.
Keep a personal journal. Once the context switching becomes intense, your work can start feeling bizarrely scattered. Writing things down helps you stay grounded and helps you avoid passing your own internal chaos onto the team.
Protect your time deliberately. Some availability is part of the role. Infinite availability is not.
Do not value your own work over good mentorship. It is tempting to keep prioritizing your own tasks because they still feel clear and satisfying. But strong mentorship is a multiplier. A well-spent hour helping someone improve their judgment can create much more value later than an hour spent polishing something yourself.
Ask more questions before giving answers. A quick answer may solve the immediate issue, but a good question can help someone build reasoning they can reuse many times.
And finally, be careful with your old strengths. Your technical skills, product knowledge, and instinct to simplify still matter. But perfectionism, and sometimes a dogmatic way of thinking, can become counterproductive if they make it harder for others to grow.
I did not stop being an engineer
That is probably the cleanest summary I can give of the transition.
I did not stop being an engineer when I became a lead. I just changed what I was engineering.
Before, I was mostly engineering software directly. Now I spend more time engineering clarity, habits, confidence, quality, ownership, and decision-making across other people. That system is much less predictable than code. It is also more ambiguous, more personal, and harder to measure in the short term.
Some days, I still miss the cleaner feedback loop of IC work. And I also understand more clearly now why the choice between the IC path and the manager path is not just a career-ladder decision. It is a decision about how you want to create impact. Do you want your work to stay centered mainly on your own technical output, or do you want part of your work to become the growth, judgment, and effectiveness of other engineers?
Neither path is more important by default. They are simply different jobs with different reward loops.
For me, that has been the biggest lesson of becoming a first-time manager through a lead role. The job is not about being the engineer who can do everyone’s work faster. It is about helping other engineers become capable enough, confident enough, and accountable enough to do strong work themselves.
That has been the biggest change in my day-to-day work.
And, slowly, it is becoming the biggest change in how I understand impact.