> Leader: "Exactly. Convince me it's the right move."
> Leader: "Is it the right thing to do?"
I think the general approach is the right one - but I can say, I personally find it extremely annoying if superiors talk like this. For me it comes across as wanting to play mind games or leaving me with an unclear state of responsibility.
By all means, give me more autonomy to choose tasks to work on and also expect a good justification from me. But at the end, I'd like at least clear feedback if my proposal was accepted and we should be moving in that direction (and I should be getting to work) or not.
But overall I agree with at least enough of the points to find it is a decent post worth a read.
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).
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.
You could say, and I wouldn't disagree, those people shouldn't be on the team. But equally it's often not that easy. Also good people are hard to find and the mediocre one might be the best you have.
It strikes me that the Google statistical results might be getting the wrong end of the stick. The teams where the leader is hands off and empowering are full of people who can be trusted which is basically the same as them doing the job themselves. The teams where the leader feels the urge to descend to micromanagement are the ones where people don't get things done.
> 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 work :)
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.
The article already starts with a strong assumption that I would challenge.
This f’n Karen decides to come over to my desk and tell me it’s “inappropriate” and “gross” and “ur mom’s placenta will get in my salmon salad”.
Win for me: keep wearing the shirt Win for Karen: stop having me wear the shirt Win Win Win: frame the shirt on my office wall so there’s never a chance of getting placenta in Karen’s salad.
Win Win Win!!
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. Like when the management book trend was to write user stories in the form of "As I user, I want to" and my manager would force us to write "As I user, I don't want to the app to crash when I" when filing bug reports because that's what their book said we should do. This type of management guidance is not good, and it doesn’t produce good results.
Yes, it’s good to direct teams to express intent. No, it’s not good to ban phrases and force your team to speak in prescribed sentence structures. This is how good advice turns into cargo cult rituals that everyone hates.
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 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.
In the military, there are strict guidelines on conduct, whereas in the private sector, it's almost anything goes, and workers are often pushing the limits of what they can get away with.
Also, in the military, rank and pecking order are clearly established. Regardless of whether or not the style is "Leader-Leader", everybody knows where they stand with regard to who they need to salute, and who they must obey.
So it's just bullshit then effectively.
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.
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).
By the very definition of the word, not everyone can be a leader, except maybe in management literature.