21–30 of 54 posts
Is an interesting idea but don’t think it scales. Once a company gets beyond like 100 people you need some structure and past 1000 is chaos is everyone is a leader.
dunbar's number? https://en.wikipedia.org/wiki/Dunbar%27s_number >
If everyone is a leader, who is doing the work?
Earlier quoted context omitted.
Great article, people mix commanders with leaders, leaders main job is influencing while others do it their approach, their style, but still align with the goals you influenced. > People tend to rise to your level of trust. One of the companies that I almost worked for, had all the “we trust we empower our employees etc”, good promises, and later they were requiring full uninterrupted camera access while you do the w…
We're the employees taking advantage of that trust? Seems a strange thing to mandate unless that trust has been severely broken.
Part of being a good manager is knowing when to step in and have a private conversation with people before things get too bad. If the bad behavior continues then you follow the process of formal write up’s and eventually termination.
Collective punishment is the sign of a manager who doesn’t know what they are doing and will kill a team.
It's not a framework, and it requires no diagram. It's just trusting and empowering people to do the job, then getting out of their way. People tend to rise to your level of trust. I wrote about this, because after a long career I've come to see that most people have no idea what leadership is, or how it works: https://thinkhuman.com/the-leader-ship/
I can't recall what prompted it, but he said he'd learned early on that the best thing he could do was to ensure us devs were happy and otherwise stay out of our way as much as possible.
I think that's at least part of the reason for the success of the company, which has gone from a small player to dominating our niche in the time I've been here.
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 mana…
By the very definition of the word, not everyone can be a leader, except maybe in management literature.
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 mana…
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).
It's not a framework, and it requires no diagram. It's just trusting and empowering people to do the job, then getting out of their way. People tend to rise to your level of trust. I wrote about this, because after a long career I've come to see that most people have no idea what leadership is, or how it works: https://thinkhuman.com/the-leader-ship/
These two situations require different techniques. Applying peacetime techniques during wartime does not work: you'll rapidly accumulate debt from unsolved organizational problems, politics you've lost control of, competitive pressure you failed to respond to decisively enough, or an underperforming team you've failed to correct enough. Or all of the above.
But, similarly, applying wartime techniques during peacetime also does not work. You'll alienate your high-performing team and suffocate critical innovation that will grow the business.
Confusing the two situations is a major category error that managers often make. It often happens because they've only experienced one of the two categories before, they were successful previously, they don't fully appreciate the extent of the existence of the other category, and when they encounter it for the first time they rely too much on their prior experience and have slowed down their own learning too much (because of said prior success).
The foundation of this approach is non-controversial: Don’t micromanage, be a good coach, don’t force work to go through the manager, and other simple truths. When I get to the recommendations to “ban” words and force engineers to speak in certain phrases I start having flashbacks to all of the bad managers from the past who read a few management books and thought those tricks were going to make them a good manager.…
When managing teams these days, the only part I keep is the “so that Z” — what beneficial change in the world does this ticket make?
If the ticket name is just “fix this bug” then I’m not certain the engineer knows why it’s important, and knowing the importance of your work is itself important.
The foundation of this approach is non-controversial: Don’t micromanage, be a good coach, don’t force work to go through the manager, and other simple truths. When I get to the recommendations to “ban” words and force engineers to speak in certain phrases I start having flashbacks to all of the bad managers from the past who read a few management books and thought those tricks were going to make them a good manager.…
The article talks about just a few such terms that are a symptom of the mindset of the leader-follower approach. Weak Saphir-Worff applies imo.
For example, I got way better as a dance teacher when I stopped using phrases like "do this", "this is correct", "that is wrong", etc and instead put all that effort into "try this", and "if you do that, this happens". Students were more open, less confused, saw possibilities instead of problems to fix.
But I get it, if I hadn't seen this change myself and heard others talk about it I would also be skeptical. It sounds a bit too good to be true.