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/
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).
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"!
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.
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.
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 :)
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.
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.
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.
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.
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.
> 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.
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.
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.
> 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.
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.
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).
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/
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).
Yeah I get this. And it goes both ways too, I find that I am a much better wartime employee than peacetime.
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"!
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.
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.
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 :)
We're the employees taking advantage of that trust? Seems a strange thing to mandate unless that trust has been severely broken.
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.
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.
> 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.
The difference here is with a win-win-win approach, we all win.
Do we all win the same equity vesting schedule?
If everyone is a leader, who is doing the work?
Claude
Really?
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>
Makes sense, think we will see companies stay smaller for longer, where everyone knows everyone. Is clearly superior for motivation / ownership
I think everyone can be their own leader.
Leaders lead.
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.
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.
> 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.
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.
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.
> 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.
what the hell are we even doing
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.
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).
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.
Read the book. Then if you want go check the sources. See if this nuclear submarine captain is lying or telling the truth.