Shift from a leader-follower to a leader-leader approach
practicalengineering.management
practicalengineering.management
But overall I agree with at least enough of the points to find it is a decent post worth a read.
> 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.
These questions condition people to think ahead, and eventually present the information unprompted.
This ultimately is part of Intent-Based Leadership, where "followers" present the "leader" with their intentions, information and reasoning - and the "leader" just agrees usually. This in essence transforms "followers" into leaders, since they are the ones deciding what happens, when and why.
Marquet goes so far as to even avoid giving orders, instead just approving or questioning the intentions of his team. It took him a long time to get to that point in reality, but it's a really interesting take on leading highly intelligent, skilled teams.
The article already starts with a strong assumption that I would challenge.
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/
> 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.
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.
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).
Or, for that matter, a massive upset where top leadership did not truly contribute significantly.
The "fog of war", AFAIK, tends to refer to general breakdown of communication (as you noted), but even fully localized control (terrorist cells, I suppose) are not highly effectual without coordination and informed assessment of the overall picture. The horrific triple (almost quadruple) attacks of 9/11/2001 would have been greatly diminished, probably by 2/3, if the attacks weren't centrally coordinated.
Wartime is exactly when centralized control is most needed.
A great illustration of this idea in context is Andrew Gordon's book on the Battle of Jutland, The Rules of the Game[1]. He mostly contrasts the leadership philosophies in the British Navy shortly before and during the Battle of Jutland. The British Navy became very top-down and procedure-oriented during peacetime, which did not generalize well to operating in battle.
[1]: https://www.goodreads.com/book/show/354137.Rules_of_the_Game
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.
Yes, this, precisely.
Most people want to be trusted and given autonomy, and they want to live up to your expectations.
There will always be a few who are looking for ways to cheat the system, but they are the exception, not the rule—and the earlier in life you can get to them with a policy of trust and lifting them up, rather than suspicion and tearing them down, the more likely they will be to turn out well.
Also checkout his other books.
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!!
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.
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.
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.
By the very definition of the word, not everyone can be a leader, except maybe in management literature.
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).
> "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.
I think what they're trying to describe is the concept of a person being assigned responsibilities as a follower, and owning that responsibility to the fullest, which is a something I agree with strongly. But that isn't them "leading". Ultimately you can have only one #1 priority, if everyone is leading whose #1 priority do you follow? that's where the informal power structure forms. it has the opposite effect of no one really leading, and everyone just saying they are.