Hacker News new | ask | show | jobs
by tptacek 854 days ago
Leadership is a seductive concept, but in the main, leadership = management - work. In a healthy engineering culture, a management goal should be enabling the maximum number of people to exercise their own leadership. Even the newfangled concept of "servant leadership" is premised on a separation of agency between those who "serve/lead" and those who "are served/led".

Effective management --- do not groan before I finish this sentence --- tends to look a lot more like adminship on Wikipedia than it does, like, war leadership. It's about picking up a mop and a bucket and making the way clear for people to do their best work. And, in our field, doing one's best work often means making and communicating big decisions, which is what leadership is.

There's also a distinction between the kind of leadership the whole company needs --- hard decisions about where to allocate resources and what bets to make --- and the day-to-day "leadership" involved in getting things done as a team. I term I hear a lot is "vibes based management", which is a recognition that somebody (probably not engineering management!) is making these kinds of decisions and communicating them just well enough for line engineers to make good choices.

If you're looking for management advice because you're running a whole company, that kind of leadership is in scope! But if you're looking to learn how to be a good engineering manager, I'm not sure how much "leadership" has to do with doing a good job.

1 comments

> But if you're looking to learn how to be a good engineering manager, I'm not sure how much "leadership" has to do with doing a good job.

Your whole comment is spot on, but I think there's a trap here. Yes, an EM should be empowering as many IC leaders as possible, but that can't be done if the EM does not recognize true leadership. While it's theoretically possible to succeed as a manager leveraging others without having your own true tech lead chops, the majority of managers like this end up either putting too much trust in the wrong ICs or (worse) devolve into cover-your-ass "agile" process bullshit.