When the best leader's work is done, the people say, "We did it ourselves".
It's a powerful sentiment, but it's so often weaponized as an excuse for passivity, especially in tech. Leaders hear it and think "A-ha! I should be invisible!", when what it actually means is: great leadership is felt, not flaunted. The invisibility comes after the hard work of structure, standards, accountability, and alignment.
If your engineers like you because you never push them, because you "Stay out of all the technical decisions", or because you "give everyone autonomy"—cool. But also: yikes! You may be liked, but you're not helping them grow. You're not helping the business succeed. You're not doing the hard, necessary work of leadership. You're just keeping things pleasant, mistaking harmony for health.
It might feel harmless to just "stay out of their way" and let them do their thing, but over time, that behavior sends a dangerous message about what leadership is supposed to look like. And it's not one that your team benefits from.
When you coast on good vibes, when you avoid the real work, you're not just phoning it in; you're misrepresenting the role entirely. You're giving those you lead a warped sense of what good leadership looks like. You're reinforcing the worst stereotypes: that managers are either top-down authoritarians or useless vibe dispensers. This work, leadership, is a profession. Treat it like one. Have some respect for it. Hone your craft. Don't just aim to be liked. Strive to be effective.
I once inherited a team from a manager who had strong cheerleader energy. They were hands-off to a fault. The team remembered them fondly, though. "We had total autonomy". "They trusted us". "They stayed out of the technical stuff". But the deeper I dug in, the more it became clear. There was no structure, no planning cadence, no ownership, no clear goals, no real accountability. It was energy rather than execution.
When I began introducing basic expectations—lightweight planning, ownership of outcomes, tying work back to actual impact—the team recoiled. They visibly flinched when I used the word "accountable"—like I had broken some sacred, unspoken contract. That was a rude awakening. They weren't lazy. They weren't bad engineers. They had just never had a manager who expected more than participation.
Here's the thing: when you follow a performance like that, you present like an alien landing on their planet. They scream "micromanagement!" when you're adding guardrails. They cry "you're in the weeds!" when all you're doing is clarifying priorities. They feel caged in when all you've really done is ask them to row the boat in the same direction.
The whiplash is real. I remember a similar situation where we had parted ways with our CTO and it took us 10 months to bring in someone new. The entire leadership team felt adrift. There were pockets of alignment, but mostly people were doing what they thought was important rather than rallying around a strategic and unified cause. When someone finally assumed the position, it was a "back to reality" moment for a lot of us.
Sometimes this whiplash brings casualties. I've had to let people go on multiple occasions, not because they weren't smart or talented, but because they couldn't (or wouldn't) adapt to new expectations. To being held responsible for delivering positive outcomes. They thought it was bonkers that they were now expected to actually perform against a standard because no one had ever asked them to before.
You can't just be all positivity. You have to hold your team accountable. You must push them to grow. It's your job to help them achieve things they otherwise wouldn't without you.
If that isn't your goal, what are you even doing there?
Let's get real for a second here: if your team would be doing exactly the same work in exactly the same way if you didn't exist, then what, exactly, are you doing here?
Seriously. What are they paying you for?
If your management style is rooted in handing out autonomy, staying out of the way, and hoping things turn out fine, that's not leadership. That's abdication. That's you letting your role happen around you rather than truly stepping into it.
You are not paid to be a cheerleader. You are not paid to simply "support", "trust", and "believe" in your team without challenge or direction. You're paid to make your team better than the sum of its parts. To help them accomplish more than they could without you. To clarify goals, set direction, create and fuel momentum, and enforce accountability.
If you're giving your team so much autonomy that they'd be doing the same thing whether you were there or not? That's objectively bad. That's not scaled leadership. It's well-compensated absence and—my god—stop it!
When you operate like this, you're not just underperforming, you're creating a distorted view of what leadership is supposed to be. You're screwing it up for the rest of us who understand the job: to advocate and deliver. To hold that tension. To represent the business and protect the team. To help your engineers succeed and hold them to a high standard of performance.
Sound hard? It is. The balance is delicate.
Autonomy is essential. Don't get me wrong. Engineering is a creative pursuit and you need space to exercise your inner artist. But without guardrails, without direction, without accountability, it's not autonomy anymore; it's drift.
Freedom goes too far when your team can't connect the work they're doing to real business outcomes. If they can't tell you why it matters, who it's for, or how it moves the needle, that's not self-management, it's a disconnect.
Disconnected teams build beautiful, irrelevant things.
This is the hard truth that some technical leaders never learn: the job inevitably stops being about the tech. Especially at mid- to later-stage startups, your role becomes about context. About business alignment. About defining success and backing into technical solutions rather than leading with the shiniest, most modern architectural approach you can dream up.
I once worked with a VP who missed that memo entirely. They came in saying we needed more "modern" engineering approaches, pointing to our SQL Server database as tired, outdated, and no longer hip. They spun up a pilot on PostgreSQL. Not to solve a real problem. Not to validate a performance case. Just because it felt "better". The result: Slower performance and no measurable upside.
If you can't connect your technical priorities to business outcomes, you're not an engineering executive. You're playing in the sandbox. You're chasing fun problems, building what excites you, and pretending that it's leadership. No one is paying you to play pretend. You don't need to trade in your hoodie for a suit, but you do need to develop some business sense. Learn to connect the dots between architecture and outcomes.
Good leaders don't need a blank check for engineering-driven work. They don't need to negotiate silly product:engineering quotas to justify their fun. They make the case, they speak fluently about impact, and they build systems that matter. They do it all by leading. Not with control, but with clarity.
The real damage of chasing approval, of wanting to be liked, is that you reshape what your team believes leadership is. You teach them that management is passive. It's cheerleading. It's vibes. It's staying out of the way. Structure is control. Accountability is confrontation. The next person who comes in and tries to do the job properly looks like the problem to them.
That's not just poor leadership, it's irresponsible.
Leadership isn't about keeping everyone happy. It's not being avoidant. It's driving impact. Growth. Direction. It's about being the reason your team succeeds rather than aiming to be someone they remember fondly.
Leadership is a profession. Respect it, practice it, and live up to it.