alt.hn

6/1/2026 at 2:03:03 AM

Shift from a leader-follower to a leader-leader approach

 https://www.practicalengineering.management/p/shift-from-a-leader-follower-to-a

by Alupis

6/1/2026 at 2:30:50 AM

I thought I’d be annoyed reading this, as the blog seems to brazenly rip off name recognition from the significantly more popular and presumably preceding “Practical Engineering” channel/blog… and to some degree that feeling did cheapen the content.

But overall I agree with at least enough of the points to find it is a decent post worth a read.

by appplication

6/1/2026 at 7:00:27 AM

> Leader: "What do you think I'm wondering right now?" (This was D. Marquet's default question)

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

by xg15

6/1/2026 at 1:24:25 PM

In the book "Turn the Ship Around", these questions are only temporary, and are part of how the leader transforms the team from traditional Leader-Follower into Leader-Leader.

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.

by Alupis

6/1/2026 at 8:33:09 AM

Part of the idea—which requires non-trivial effort from the leaders to build up sufficient trust—is that people should believe that their proposals (for their own work) are accepted by default. People don't have to wait for their idea to be accepted, but they have to communicate enough so that leaders can surface specific issues or mismatches only if they have them.

by tikhonj

6/1/2026 at 4:17:38 AM

> Even though today we lead people, we've most likely climbed the engineering ladder through technical excellence.

The article already starts with a strong assumption that I would challenge.

by steve1977

6/1/2026 at 3:30:24 AM

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/

by jamesgill

6/1/2026 at 4:28:22 AM

This approach is great for peacetime and for when the team is already reasonably functional and performing. The really hard leadership problems occur during wartime (the business is in crisis, or shrinking, or responding to a serious competitive threat, or must aggressively cut costs, or must integrate an acquisition, or...) or when the team you have is routinely underperforming at scale.

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

by nilkn

6/1/2026 at 4:42:20 AM

Wartime is exactly when centralized control breaks down the hardest, because conditions start changing incredibly fast and communication breaks down. There's a reason the phrase is "fog of war" and not "fog of peace"!

by tikhonj

6/1/2026 at 4:46:58 AM

In management, what it means is having to repeatedly make decisions that are in the best interest of the company, but not necessarily in the best interest of the people on your team. This could mean needing to fire people, conduct layoffs, merge teams together and remove redundancies, strip a manager of their direct reports or reduce their scope, replace a leader, drive a major re-org that changes people's jobs in ways they may not like, shut down an entire project or team that isn't succeeding even though it's very popular or well-liked in the organization, own a technical decision that hurts one or two teams but helps the overall organization enough to offset it, etc.

by nilkn

6/1/2026 at 1:50:28 PM

Counterpoint: Name a great victory where top leadership mattered very little.

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.

by IAmBroom

6/1/2026 at 5:27:09 AM

Yeah I get this. And it goes both ways too, I find that I am a much better wartime employee than peacetime.

by protocolture

6/1/2026 at 4:21:10 AM

A year after starting my current job, I had a conversation with the CEO. We were just 15 people back then, 5 devs.

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.

by magicalhippo

6/1/2026 at 3:45:23 AM

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 work :)

by tamimio

6/1/2026 at 4:13:50 AM

We're the employees taking advantage of that trust? Seems a strange thing to mandate unless that trust has been severely broken.

by noitpmeder

6/1/2026 at 4:18:36 AM

Still the wrong response. Discipline the people abusing your trust.

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.

by alemanek

6/1/2026 at 6:00:28 AM

No argument there, id eject from any company that even started to consider such measures (unless they're adding a few zeroes to my paycheck)

by noitpmeder

6/1/2026 at 7:50:33 AM

> People tend to rise to your level of trust.

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.

by danaris

6/1/2026 at 7:12:33 AM

Sort of true. But then I've worked with people who seem totally unfazed when they mess up through utter carelessness, and for reasons, won't be replaced. Or people who asked to move a button set off redesigning the template engine to be more functional, time after time.

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.

by rich_sasha

6/1/2026 at 3:30:22 AM

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.

by mazinz

6/1/2026 at 3:41:00 AM

dunbar's number?

<https://en.wikipedia.org/wiki/Dunbar%27s_number>

by steanne

6/1/2026 at 4:17:49 AM

Makes sense, think we will see companies stay smaller for longer, where everyone knows everyone. Is clearly superior for motivation / ownership

by mazinz

6/1/2026 at 2:53:14 AM

The difference here is with a win-win-win approach, we all win.

by 866-RON-0-FEZ

6/1/2026 at 3:36:27 AM

Do we all win the same equity vesting schedule?

by orsorna

6/1/2026 at 1:53:59 PM

At my employee-owned company, yes.

by IAmBroom

6/1/2026 at 3:34:08 AM

I worked in an office last year. We had these “Wacky Shirt Wednesdays.” On the first Wednesday I was able to participate, I decided to wear the shirt my mom was wearing when I was born. Now there’s some leftover placenta and uterine lining, so it isn’t the cleanest shirt. BUT it’s the thought that counts. That what momma says.

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!!

by __s

6/1/2026 at 2:32:55 AM

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

by Aurornis

6/1/2026 at 4:28:29 AM

After a couple years I realized the key part of “As an X I want Y so that Z” is the “so that Z”.

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.

by Erem

6/1/2026 at 8:26:30 AM

Current workplace has cargo-culted this so hard the tickets look like "As a backend foo-server, I need to modify the baz function to create an interface for blargh requests."

by autumnstwilight

6/1/2026 at 4:31:28 AM

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

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.

by boxed

6/1/2026 at 3:20:54 AM

If everyone is a leader, who is doing the work?

by hyperhello

6/1/2026 at 4:18:13 AM

Claude

by steve1977

6/1/2026 at 3:22:00 AM

Really?

by mountainriver

6/1/2026 at 4:01:58 AM

I think everyone can be their own leader.

by doveyoung

6/1/2026 at 4:55:19 AM

Leaders lead.

by andsoitis

6/1/2026 at 4:42:54 AM

what the hell are we even doing

by ares623

6/1/2026 at 3:37:10 AM

It’s a flat management style, I love it and I appreciate people who are doing it, but throughout all the years I have only seen it done twice properly, of the already rare occasions of using it anyway. The vast majority are your typical corpo hierarchal BS, or even worse, a small early stage startup trying to pull the same corporate style, while mixing it with startup one resulting in the downside of both. In one company, the engineering manager wanted to have a daily standup with scrum style (apparently he wanted it because his wife was working in a remote silicon valley job and just knew about it..) for a team who none of them is working in the same product, and most aren’t even software, and got offended when get told it’s stupid and it’s better to use other approaches, of course he refused because it’s about power dynamics now, I left shortly with other 3 engineers in the same month due to bad management style.

by tamimio

6/1/2026 at 3:53:17 AM

Some styles may work better in a uniformed military environment than they would in the real world.

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.

by anonymousiam

6/1/2026 at 4:13:54 AM

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

by steve1977

6/1/2026 at 4:30:09 AM

[flagged]

by rohitsriram

6/1/2026 at 4:04:17 AM

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.

by notepad0x90

6/1/2026 at 4:27:52 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).

by noitpmeder

6/1/2026 at 12:15:32 PM

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.

by notepad0x90

6/1/2026 at 4:21:59 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.

by steve1977

6/1/2026 at 4:32:49 AM

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

by boxed

6/1/2026 at 12:00:25 PM

I am interested but don't have time to read a book. However, I don't think any text can change a person's opinion that is derived from experience.

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.

by notepad0x90

6/1/2026 at 1:11:22 PM

"Turn the Ship Around" is fantastic. It's a short audio book (about 6.5 hours), if that's more up your alley. Definitely worth a read/listen.

by Alupis

6/1/2026 at 1:38:33 PM

The audio book is read by the author. Well worth your time imo.

by boxed

6/1/2026 at 5:51:30 PM

Thanks, i'll have to check it out.

by notepad0x90