Leading Well Means Reaching the Goal and Helping the Team Grow

How do you know if you're leading a team well? Hitting the goal is the obvious part, the one nobody argues with. A while ago I started measuring something else: how much the people I lead grow while we work together to get there, even to the point of surpassing me.

I'm a tech lead now, after working as a senior engineer on the same team. On the way to that role, an advisor who helped me develop as a leader told me something that stuck with me: almost nobody manages to combine solid technical judgment with a real understanding of their team. And the second part isn't something you learn just by reading a manual. That was the first time I saw leadership as a skill you learn and practice, not something you automatically get by being good at coding.

Since then I changed how I do 3 things: my 1:1s, how I delegate, and how I review my team's code.

What I took away

• Hitting the goal is still the baseline. What I added was measuring how much the team grows on the way there.
• Explaining the reasoning behind a task helps someone make similar decisions on their own.
• My team eventually surpassing me isn't a threat to my leadership. It's proof it worked.

My 1:1s stopped being a status check

I work with each person on a development plan with specific, measurable goals. It can be something as practical as communicating a hard decision better in front of the team, or something more technical like going deeper into designing a whole system. What matters is that it can be measured, not just felt.

Before each 1:1, a meeting with just the two of us, I say the same thing: this time is yours. We cover project updates in a separate team meeting. If I let those updates take over the 1:1, the person ends up reporting tasks instead of thinking aloud about where they want to grow. That conversation needs its own space.

Why is explaining why more important than just saying what to do?

Because an instruction helps someone finish one task. Explaining the reasoning helps them make the next similar decision on their own. It takes more time at first, but I have found it makes the team less dependent on me.

For example, telling someone "use this library" solves that one task. Explaining that I picked it because the team already uses it in 3 other places, and I don't want a fourth way of solving the same thing, helps them weigh the same trade-off next time they need to choose.

I review code so the person finds the answer, not so I can hand it to them

When I review someone's code and see something that could be better, I usually start with a question: what do you think about trying this another way? What would happen in this situation? The idea is to guide them toward noticing it themselves, not tell them directly where the problem is.

With someone newer on the team, I'm sometimes more direct, but even then I avoid saying "this is wrong." I'd rather say something like "this isn't a good practice, for these reasons," and as soon as I can, I go back to asking questions. If they still need help, I explain. The aim is to give them more to work with next time, while keeping the conversation respectful.

When I review code, I use questions to help the person find the answer. If they need more help, I explain.

How I know if a year of leading was a good one

I keep coming back to what that advisor told me about combining the technical with understanding people. Over time it became my own definition of success.

To me, leading well is simple to say and hard to do: the team hits its goals, and the people grow, even to the point of surpassing me.

If you lead people, hitting the goal never stops mattering. But I learned to measure something else: how capable my team is of hitting the next goal without me guiding every step. I'm still learning to do that well. Thanks for reading this far. 🙂