What makes a good engineering leader

Originally published on lavkesh.com

I've seen plenty of brilliant coders who can't take a team anywhere. And I've seen solid engineers who became great leads because they understood how to make other people better. Being a good engineer is not the same as being a good leader.

Having a point of view about where you're going is key. That doesn't mean you always know the answer, but you have to see beyond the ticket you're working on right now. You understand how the code connects to the business, how the project fits into something larger.

You communicate that clearly, especially when talking to people who don't live in the codebase every day. You make it safe for people to suggest ideas and disagree. Good leaders don't work alone. They pull from the whole team and get better results because of it.

For example, I worked on a project where we were using a combination of AWS Lambda and Azure Functions for serverless computing. The team was struggling to understand the cost implications of using these services. I had to break down the costs and explain them in terms of the business goals. We ended up saving 30% on costs by optimizing our usage and choosing the right services for the right tasks.

You have to be adaptable. Tech changes constantly. The frameworks you know now won't be what you're using in five years. Leaders who stay current and encourage their teams to do the same build cultures where people actually want to work.

When things break, which they do, you stay calm, think methodically, and help your team solve it together. You don't panic and you don't blame. Empathy matters. You need to understand what your team members are dealing with, what's hard about their work, where they want to grow. I've seen teams that use postmortem analysis tools like Blameless or Rootly to identify the root cause of failures and implement changes to prevent them in the future.

You celebrate when things go right. You build enough trust that people will tell you when something is wrong before it becomes a crisis. And you do what you say you'll do. You work alongside them, not above them. You set the bar by meeting it yourself. For instance, I use tools like GitHub or GitLab to track progress and show the team what I'm working on, so they can see I'm committed to the same goals.

Good leaders anticipate what's coming, not just react to what's here. They take ownership when something goes wrong instead of finding someone to blame. They invest in people, mentoring and coaching, helping team members become better. I've found that using agile methodologies like Scrum or Kanban helps teams stay focused on priorities and adapt to changing requirements.

They notice when someone's good at something and delegate to them, letting people own parts of the system. They navigate disagreements without letting them fester. They build diverse teams because you solve harder problems that way. They give feedback regularly, not once a year in a formal review. Tools like 15Five or Lattice help facilitate regular check-ins and feedback.

They lead with honesty, and people respect that. Leadership as an engineer isn't about a title. It's about making your team better and moving things forward.