So you were just promoted and aren't sure what to do? Let's talk about it.
How did you get here?
You woke up and... surprise! You're a lead engineer now, congrats! Before the panic sets in, you need to know: you were chosen for a reason.
Chances are you report to someone that oversees a bunch of teams and they need to scale, so they need someone they can trust, to be their eyes and ears. Your manager only has so much time in a day and they don't want to stay awake until 1 AM, at least for work related reasons.
You are most likely an influencer, a hard worker, reliable, transparent, and need little guidance. Maybe you don't realize these things, but you have been a leader long before you knew it. Your boss feels like you will let them know when you need help or guidance, with only having to meet once a week or so.
What it isn't
A lead is a description, not a role, but it's your title now. It's a bit confusing, but you are still a senior or principle engineer, that hasn't changed. Simply put: you are an engineer, with some additional responsibilities. So yeah, you still code.
You're not a manager. You do not handle payroll or promote people, but your manager is going to come to you when people ask about those things. It doesn't mean you shouldn't care about others advancements, on the contrary, but you don't call the shots.
The code doesn't belong to you, you share it. It's not a good idea to bring out the gavel -- you're gonna have a bad time. Your job isn't to control others.
Being in the know
Now that we've got what it doesn't mean out of the way, here's the first what it is.
There's a lot going on. Most likely there are other teams working on different areas, of the same project, you want to know what's going on. Even if other teams are working on other projects, you want to know.
You don't need to know every detail, but you will find it extremely valuable to know what practices other teams are following, what they are working on, it's like a puzzle. You can learn where the company is headed, just by looking at pull requests.
Since you won't always interact with other leads, it's invaluable to know when you might step on each others toes. It will help you de-risk future work, avoid roadblocks, and know what you can leverage.
First responder
The product owner and designer are going to be meeting with stakeholders and customers to figure out the next set(s) of work, and you need to be there. When that happens varies for each company, but the earlier the better. A lead engineer knows what is possible with the current infrastructure, what's a reasonable solution, and what shortcuts can be taken.
Likewise, when things go south, you have to be there. Since you're in the know, you probably will know what's wrong. And even if you didn't write the code that took down production over the weekend, you're responsible for it.
Keeper of all things code
You should see every pull request your team puts up. Again, it's not your code, but you want to guide people in the right direction, but trust they will do the right thing.
The biggest thing here is to make people aware of what could break, what practices they aren't following. It's not personal, so you don't want to make people feel bad; so tell them what should change and why. Slap an approval on it and move on, unless it's really off base. Trust.
Creator of surface area
This is one of my favorite and most important points. We do a lot of green field work here, but this applies to a new set of features in an application as well.
If you are starting a new project, setup the structure, the router, and a few placeholder pages. Or setup the express server, a few routes, and the structure that demonstrates the flow of a request.
Giving people room to spread out, ahead of time, prevents people from bumping their heads into others. If two developers are trying to make that routes file you're going to end up with merge conflicts. Gross.
Keeper of peace
Everyone has an opinion, and that's okay. There are a million ways to solve a problem, but how does your engineering department solve a problem? Do that. Then do that again. There's no reason to reinvent the wheel, and some people will want to.
There will be disagreements, so people will look to you to solve them. There might not always be the perfect answer, and that's okay, too. You're going to have to weigh everything out and choose. At the end of the day, it's just code. The beautiful thing about that is: you can always change it later.
Lastly, don't throw people under the bus. If something breaks, everything will be okay. Stay calm and be responsible; focus on the fix, then after, how to not find yourself in this situation again.
The most productive person in the room
Honestly, it's going to be hard for people to respect you as a leader, if you sit on your high throne. This is a short one, but if you get the most done, people will look up to you.
The sherpa
Every company is different. There are different coding standards, practices, and politics. It's your job to guide the new dev on their journey. Who do they ask when they need a Jira account? Who do they talk to when their locked out of their email? Maybe they need to find the person who knows the most about writing SQL joins or the person who created the architure. You might not always know the answers, but if you know who does, you can point them in the right direction.