[noitpmeder]

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).

[notepad0x90]

The problem is you have a very different understanding of what a leader is, than what i think is a more correct definition. a person hoarding information is not a leader. making decisions in a way no one else can reproduce how you made decisions, lacking transparency, making it about your ego is not leadership. matter of fact, that sort of mentality where you have an irreplacable tech lead usually results from poor leadership skills on their part, as were as their people manager's. i.e.: leaders are often actually highly replaceable. For tech lead roles, even in a 2 person team, it would be the one that has more experience, but ultimately they are responsible for their technical leadership, they own outcomes so long as their followers trust them to lead and actually follow their direction. They have to be able to for example reject PRs, but do it in a way that doesn't lost the teams' trust of their competence. If they resign tomorrow, the next guy in the line that is most experienced can take over and lead, perhaps with a different style, but they should spend much time making decisions and leading, and less time hoarding knowledge and doing actual work, making them more replaceable.

> "I have a problem, here is my recommended fix, how does that sound?"

Couldn't agree more, I've lived by this principle myself. leaders are not problem solvers though, a leader gets to reject the really good idea of someone that does come up with a seemingly great idea without letting them down harshly, and also encourage that atmosphere of continuing to suggest solutions. They also set the direction (tactically for technical leaders, and strategically for people leaders) of the team, so that the problems an IC does focus on is aligned with the leaders' priority.

If your engineers are making their own decisions, there is the problem of conflicting changes (even in Git the concept of conflict resolution exists, someone has to decide to merge the changes into main/master after resolving conflicts). There is also the problem of ultimately them spending a lot of time on something, only for that being low priority, or rejected outright because it doesn't make sense strategically, that demoralizes people and creates a terrible atmosphere. A very clear chain of command is important at work as it is on the battlefield. And just as in a battlefield, due to the clarity of that chain of command, a general being killed by the enemy does not decapitate a battalion, the person next in the chain of command takes over. Not only should leaders be replaceable by design, they're often rotated from team to team to ensure such an informal dependency on them never forms.

I think what you're describing to the most part is also the problem I outlined in my first post: The spreading of blame by supposed leaders creating an over dependency on them and credits for work they didn't contribute to much, and creation of actual leaders that end up being irreplaceable because their role wasn't formally designated or acknowledged, but assumed, they're not part of the planned structure of the chain of command.