You Don't Need a Title to Lead
Some thoughts on leading without authority
I keep coming back to this idea that the people who actually steer the technical direction of a team are almost never the ones with “manager” or “director” in their title. I’ve seen it at every place I’ve worked. There’s some senior engineer who everyone just… listens to. Not because they have authority over anyone, but because they’ve been right enough times that when they say “I don’t think we should do it that way,” people pay attention.
That’s leadership. It doesn’t show up on an org chart, and most companies have no idea how to measure it, but it’s the thing that actually determines whether a team builds good systems or bad ones.
I should be clear – I’m not talking about being passive. This isn’t “lead by example” in the generic motivational poster sense. It’s more like… when you’ve built up enough trust and technical credibility, you can shape decisions without having to own them formally. You influence the architecture through code reviews. You influence the culture through how you handle your own mistakes. You pull the team in a direction by doing good work and making your reasoning visible.
So what does this look like day to day
The person who has the most influence on architecture and coding standards at most places I’ve worked has been a senior or staff IC, not the engineering manager. The EM is usually focused on process and people stuff (which matters, obviously) but the technical heartbeat comes from whoever has earned it.
Code review is a big part of this. Not the “you missed a semicolon” kind of review – the kind where you ask real questions. “What happens here if the upstream service is slow?” That kind of thing. You’re teaching without being condescending about it. There’s a huge difference between “this doesn’t meet our standards” and “have you thought about what happens under backpressure?” One of those starts a conversation. The other one starts a grudge.
The other piece is making your thinking visible. I used to believe that good work speaks for itself. It does not. Nobody is going to read your commit history and reverse-engineer your architectural reasoning. You have to write it down – design docs, RFCs, even just long-form Slack messages explaining why you made a particular choice. It feels like extra work, and I guess it is, but that’s how you spread your influence beyond the code you personally write. Otherwise your impact is limited to what you can personally touch, which doesn’t scale.
Tobi Lutke at Shopify talks about this “trust battery” idea, and I think about it a lot. Every interaction with a coworker either charges or drains the battery. You follow through on what you said you’d do – charged. You take credit for someone else’s idea – drained. You admit you were wrong about something – charged (and this one is worth more than people think). When the battery is full, you can push back on bad ideas from anyone in the org, even the VP who’s emotionally attached to a project that should be killed. When the battery is empty, nobody cares what you think, regardless of whether you’re right.
The trap I fell into
There’s a trap here and I’ve fallen into it. Some senior engineers end up in this ivory tower situation – the team comes to them for pronouncements but they’re not really collaborating. They’ve got opinions about everything but they haven’t actually looked at the code in question. They review designs from 30,000 feet and then go back to whatever they were doing.
That’s not leading from behind. That’s just being disconnected with a fancy title. You have to stay in the weeds enough to understand what the team is actually dealing with. I spent a few years earlier in my career thinking that being the smartest person in the room was the point. It’s not. The point is making everyone around you better at their jobs, and you can’t do that if you don’t understand their problems at a practical level.
This is where I get frustrated
Here’s where I get frustrated. Most companies are terrible at recognizing this kind of work. Promotions go to the person who shipped the big visible feature, not the person who quietly made the deployment pipeline 3x faster so that everyone ships more. Performance reviews reward individual output, not the diffuse, hard-to-attribute effect of raising the whole team’s game.
And then we wonder why senior ICs leave, or why they give up and go into management even when they don’t want to. If the only way to get a raise or a promotion is to stop doing the thing you’re best at, the incentive structure is broken. I don’t really have a fix for this – it’s a hard problem because the impact of this kind of leadership is genuinely difficult to quantify. But at minimum, organizations need to acknowledge that it exists and figure out how to value it. Otherwise you end up bleeding your best technical people and not understanding why.
The best teams I’ve been on all had one thing in common – there was an implicit understanding that leadership is something you do, not something you are. Anybody could lead. Everybody probably should, in their own way. Whether that actually happens depends on whether the organization makes room for it or whether they’ve built a system that only rewards people with direct reports.