For Me, Leading Well Means Hitting the Goal and Growing the Team at the Same Time

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 a stretch working there as a senior engineer. 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 genuinely understanding their team at the same time. 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 that comes free with 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.
• Delegating without explaining why only hands off a task. Delegating while explaining why hands off judgment.
• 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

With every person on my team I build a development plan with concrete, measurable areas, not a vague intention to "improve." 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 every 1:1 starts, I say the same thing: this time is yours, we're not reviewing status here. Status has its own space, in a different meeting, with the whole team. If I let status creep into the 1:1, the person ends up reporting tasks to me instead of thinking out loud about where they want to grow, and that conversation never happens anywhere else.

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

Because saying what to do solves one task. Explaining why that's the right call gives the person the same judgment for the next similar decisions, without having to ask me again. It costs more time upfront, but it's the only thing that makes delegation actually scale with the team.

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, gives them the same judgment for the next time they have to choose on their own, without me there to tell them.

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, my first move isn't pointing out that it's wrong. It's asking: what do you think about trying it this other way instead? Did you notice this could fail if that case happens? 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. And if the person still doesn't get there on their own, I explain it, no drama at all. It's never about making them feel bad for not getting there. It's about them having more to work with next time they try on their own.

I don't give them the answer. I guide them with questions until they find it themselves.

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 standing over it. I'm still learning to do that well. Thanks for reading this far. 🙂