logoalt Hacker News

notepad0x90today at 4:04 AM3 repliesview on HN

i clicked thinking he was mocking this! I hate it so much. no, dude, not everyone can be a leader. no we're not all "leaders"?!?!?

come on. this is such a dilution. it screams refusal to take responsibility for anything. diversifying responsibility so that no one is held accountable. Or a massive lack of understanding why and how naturally humans organize using a hierarchical structure.

This is a cowardly way of managing people, a leader blaming those under him/her for not also being "leaders" when they fail, that's what it seems like to me, and how I've seen this mindset abused.

I don't care if you're a two person team, one follows and the other leads. the problem is actually the opposite of what this guy describes usually. A refusal to accept hierarchy, and an immaturity resulting from not being able to understand, that leadership comes with responsibility, not just rights, as does following.

There is this massive ideological disease in corporate america that I won't rant about here, but what is needed is managers with balls (regardless of their sex) and gumption, who can say "they buck stops with me, I'm responsible for the outcome". Not everyone else because "we're all leaders" not hired consultants you hired to c.y.a., not the "lack of talent",etc..

If you're in a team where someone says "all reviews and prs go through me" and they have they seniority and experience to back that up, count yourself fortunate!

It's not secret for example that most successful open source projects are run by a BDFL (not the least of which is the Linux Kernel).

Everyone in the car can't be responsible for driving it, same as they can't for navigation. With the approach in this post, my guess is instead of driving the car, proponents will be back-seat drivers.

Two more things: everyone in a team must trust each other to do their part, that includes the leader when they lead, and team members when they fulfill their tasks. In order to lead, you have to know where and how to lead others, the problem is people are put into leadership positions in corporate america using the system of "promotion until incompetency", where if a person is competent at all they are promoted, and they end up in positions where they have the least amount of competency, earn the most, and thus are at the highest risk of elimination, and this breeds: the modern middle manager that strives to spread responsibility that comes with their position so that they can take credit for success of their team, but have plenty of blame they can throw around for failures. Even when they want to do the opposite of that in earnest, it becomes impractical.

For everyone to be a leader, the way human psychology works needs to change. what you end up with is informal hierarchy immune from accountability, transparency and scrutiny by outsiders. Good people getting frustrated and leaving your team, and those who can manipulate the informal power structure well and help with the blame spreading, succeeding and staying

Failing upwards as some call it. And then enshittification. I haven't solved the part where things are actually working in a repeating cycle and will all be good some day.


Replies

noitpmedertoday at 4:27 AM

I think this is largely off the mark for most engineering teams built around roughly-aligned peers.

Sure, if your team is extremely lopsided or unfocused, and e.x. has one person from every discipline, you don't want to cross train everyone into everything else. This is a sign to reorg. Youre not asking your department heads to cross-train to other departments, your PMs/devs to cross train/...

But when you have a 1-to-2-pizza engineering team of e.g. C++ engineers and a tech lead, the lead should absolutely be encouraging this "everyone is a leader" mentality. Anything else means that your tech lead is irreplaceable and if they e.g. get hit by a bus or resign tomorrow you are SCREWED. You essentially are promoting learned helplessness as soon as the subject matter leaves your narrow areas of expertise and the "leaders" are not available to offload decisions to. The best thing a tech lead can do is encourage his workers to make him redundant -- no regular process/decision/... should ideally be blocked by their absence.

As an IC, your manager dreams of you approaching him not like "I have a problem, solve it for me", but instead "I have a problem, here is my recommended fix, how does that sound?". This would be AMAZING. You can then sync on goals/reasoning/approach/... and catch out fundamental misunderstandings on both ends. If one truly is at a fork and someone NEEDS to make a decision (really only if there is conflict as to the preferred approach) then the buck stops at the designated leader. However in most situations your engineers should be empowered to make decisions when they are confident, with review/reflection helping improve/align these decision making skills with their leads/peers over time.

Defaulting to "youre the lead, I cannot-or-willnot walk down the path unless you proceed me" is shit. Sure, when starting off it's great to have an example to follow, but eventually you gotta learn to walk the path yourself (or get off my team).

I want to be promoted one day, and the only way that's going to happen is if I can ensure I have a team of reports who prove they can survive without me (and one of whom hopefully is able to step up and fill the hole).

steve1977today at 4:21 AM

Yeah I think in reality the article describes a Non-Leader-Non-Leader approach.

By the very definition of the word, not everyone can be a leader, except maybe in management literature.

boxedtoday at 4:32 AM

Read the book. Then if you want go check the sources. See if this nuclear submarine captain is lying or telling the truth.