What a Lead Engineer Actually Does (and What They Spend Too Much Time Thinking They Should)

I became a lead engineer thinking the job would be a nicer version of the job I had been doing. More autonomy. More say in the direction. More interesting problems.

What the job actually is: unblocking other people and making sure the system does not catch fire when they are not paying attention.

That is 80% of it. The other 20% is split between code review, architecture conversations, and meetings about meetings. Some days it is 90% meetings about meetings.

What You Stop Doing

You stop shipping code at the rate you used to. You still write code. But not the main path. You write code to unblock someone else, or to fix the thing that broke because the system is complex and nobody had time to think about the whole picture. You write code when you have decided it is more efficient than explaining it. That is a smaller set than you expect.

You stop having uninterrupted focus time. A junior engineer is stuck on a database query. The infrastructure broke in a weird way. Someone needs advice on how to approach a refactor. These are all small conversations, but they are also all constant. You get really good at context switching or you go crazy. I see a lot of leads go crazy.

You stop being the expert at the thing. You have to know enough to have opinions about the thing. You have to know enough to spot when someone is going down a path that will hurt them. You do not have to know as much as the person who is spending 8 hours a day on that thing. This is disorienting. You have been the expert at things for years. It is weird to not be.

What You Actually Do

You figure out what is blocking people and you remove the block. Sometimes that is a technical problem and you help solve it. Sometimes it is a resource problem and you advocate for more people or better tooling. Sometimes it is a clarity problem and you write down the decision in a way that makes sense. Sometimes it is just that someone is demoralized and you remind them that the work is going well.

You maintain the system. Not the code. The system. The fact that when someone ships something, it actually works. The fact that when something breaks, people know it broke and they fix it. The fact that nobody is working in the dark or starting from zero on a problem someone else has already solved. You are the person whose job is to make sure all of that stays intact even as the team grows and the codebase gets more complex.

You say no to things. You say no in a way that explains why but sounds like you are not being difficult. You say no to scope creep and to people trying to do work that the team is not equipped to do yet and to ideas that sound good until someone has to actually build them. The yes answers are cheaper to give. The no answers are what actually protect the team's velocity.

You run interference between the team and everything else. The roadmap. The business. The other teams. The person panicking about a customer issue that is not actually critical. Your team should not hear all of this noise. Your job is to hear the noise, figure out what is signal, and pass the signal on in a way that does not destroy focus.

The Mental Shift

The hard part is that you do not get to do the job you became good at and got promoted for. You got promoted because you were great at building things. Now your job is making sure other people can build things. That is a different job. It requires different skills. You are a novice at it.

The thing that kills a lot of leads is trying to do both. They still want to write the interesting code and solve the hard problems. So they try to be hands-on on the code and also be available for people and also sit in the meetings that are required. They burn out because you cannot do three full-time jobs at the same time. You have to pick one.

The better leads I have known pick the job that matters most: making the team effective. They step back from being the best coder and they become the person who makes sure good code gets written. They are not writing it. They are making sure the conditions exist for it to be written well.

That is a smaller thing and a bigger thing at the same time. Smaller because you are shipping less code. Bigger because you are making it possible for more code to be shipped by more people and you are making it better because you are thinking about the whole system instead of your piece of it.

Nobody warns you about this. There is a moment when you realize you are not really an engineer anymore. You are something else that used to be an engineer. It is disorienting. It took me a while to make peace with that. The code is still mine in a way, just not the way I thought it would be.