Be the Leader(s) Your Team Needs, Not the One You Want to Be

Don’t let the marketing fool you, one size does not fit all.

Maybe it’s the algorithm, or perhaps it’s recency bias, and realistically, it’s probably a combination of the two, but I’ve increasingly seen more and more posts about what type of leader someone should be. And predominantly I’ve seen the advice to be written as absolutes, which you all know, only Siths deal in absolutes. Posts and advice of "as a manager, you should never micromanage", or "as a leader, you should not be hands-on", or even topics like "you should not be the smartest one in your team".

To be fair, the kernel behind those messages aren’t inherently wrong or disingenuous, but they are not universal truths, nor are they mutually exclusive to the leader you should be on your team.

And I mean this for all industries, not just engineering. When people in the industry make these general posts, it conveys a dangerous message to readers, especially those who haven’t had to lead a team, or are looking for a beacon to emulate. That dangerous message being that their advice can be applied to everyone on the team - which is just not true.

I’ll try to avoid the Sith trap of speaking in absolutes in this post, and avoid being too philosophical. But how can you not be romantic about baseball…I mean leadership.

Humans are dynamic, which makes teams dynamic, because teams are just a combination of people who have some similarities with varying degrees of differences. Even if you have a team that is more homogeneous than others - perhaps all senior or all from the same backgrounds, no two people are the same. They have different families, different memories, and are in different stages of life. And yes, all of this impacts them and the team. Take two engineers who are peers on your team. Same level, same performance, both people you trust. One will dive in and start building while they figure out the ambiguities on the way. The other needs to have everything mapped out before writing a single line. Lead them the same way, and you’ll either slow one down or let the other ship something that misses the mark.

So if teams are dynamic, and people are different, even have different t-shirt sizes, why would you try to be the same leader for everyone on your team? I’m not saying you shouldn’t have standards, or non-negotiables, but you shouldn’t close the door on what makes you be an effective leader.

Let’s take the micromanager topic as an example, since this is by far the one you can find so many opinions and publications about. "Don't be a micromanager", "Micromanagers are bad". Is that advice correct? Annoyingly, like a Senior Engineer will answer to any question, it actually depends. When you’re leading a Senior on your team who has a great cultural foundation (ownership, autonomy, drive), yes, you don’t and shouldn’t need micromanaging. But what about when you have interns? Or even as uncomfortable as the topic is, a Senior who isn’t living up to the bar? Micromanagement might actually be appropriate.

I recently hired 2 summer interns who haven’t had prior professional internships or work experience. I can’t be the leader I am to the rest of my team, and it wouldn’t be fair to either of us.

For them, my job is to teach them what professional work actually looks like before I can ask them to do any of it. They don’t know yet how to scope a task, communicate a blocker, or push back on a deadline. They don’t have the reps to break an ambiguous project into smaller deterministic units of work, figure out what needs to be parallelized, what needs abstracting, or what to defer while still making forward progress. So for them, I have to “micromanage” by setting the structure: what needs to get done, when, and in what order. That’s not a knock on them, it’s just where they are. My job is to meet them there.

To the LinkedIn crowd, this might seem like blasphemous micromanagement, and I’m committing a cardinal sin that reflects my ineffectiveness. But in reality, it’s just recognizing that autonomy is earned through context and experience, and it’s my job to help them build both. If I gave my interns the same latitude I give my senior engineers, I wouldn’t be a “good leader”, I’d just be setting them up to fail quietly.

Now flip it. If I applied that same level of oversight to a senior engineer who has been successfully executing, I’d be signaling that I don’t trust their judgment. Even beyond that, I would not be providing any value, or being the force multiplier on the team. Same behavior, completely different outcomes, depending on who it’s applied to.

This is what the absolute advice misses. The goal is always the same: help your people do their best work, but the method has to match the person.

Now take another one from the list: "as a leader, you should not be hands-on". There is a version of this that is true. If you are staying hands-on because you don’t trust your team, or because you can’t let go of the code, that’s a problem worth addressing. But if you are staying hands-on because your team is early-stage, staying scalably lean, or working in a domain where your direct contribution unblocks them, blindly stepping back isn’t leadership, it’s just absence.

Even if I’m a “manager” now, I still carry the experience and knowledge of a Staff Engineer, and sometimes that’s exactly what the team needs me to use.

One of my senior engineers hadn’t previously operated on concurrent systems in the Python ecosystem. Before I wrote a single line, I had a direct conversation with them: here’s where I think you need a guide, here’s why, and here’s how I want to help. It wasn’t a directive, it was a peer conversation, and they could have pushed back, and I would have listened. They understood, and we were aligned. I built the POC first, on a platform I knew would be safe and scale, so they weren’t spinning their wheels on foundational decisions that would have them land into a pitfall simply bouncing ideas off Claude in an echo chamber.

Then I handed it to them to own and grow. From there, I guided them on which libraries to dig into, in what order, and how the patterns mapped to things they’d already seen. Asking them what pros and cons they derived from each. Because they didn’t have to carry the cognitive overhead of figuring out an unknown domain from scratch, they could focus on what actually mattered: the product and the project. The technical onboarding happened at their pace, and now they iterate on it independently with a strong sense of ownership. That combination cut weeks off the ramp-up, and that only happens if you’re willing to have the honest conversation and not hide behind “I shouldn’t be hands-on.”

The reason I put the “s” in parentheses in the title is intentional. Based on the needs of my team, personnel and project wise, I am a different leader to each person on my team. Structured and directive with my interns. A thought partner with my seniors. A force multiplier for the team.

None of those are the leader I necessarily want to be on any given Tuesday. But it’s the type of leader the team needs.

The best leadership advice isn’t a persona to adopt. It’s a reminder to stay curious about your team, your roadmap, your architecture, and honest about what they need, and be willing to adjust. The leaders who get stuck on a fixed identity are often the ones who end up serving themselves, not their team.

Know your people. Lead accordingly. Live long, and prosper.