An Engineering Team Where Everyone Is a Leader(blog.pragmaticengineer.com)
blog.pragmaticengineer.com
An Engineering Team Where Everyone Is a Leader
https://blog.pragmaticengineer.com/a-team-where-everyone-is-a-leader/
63 comments
I say this as an engineering director and someone who takes a lot of pride in my ability to do all the good things you describe: what's wrong with it is that bad management is hard to dislodge.
Bad managers will never admit they're bad; they have bad employees. It's really hard for upper management to tell the difference. The early signs of bad management look a lot like bad employee performance. It takes time for a pattern of behavior to emerge, and in the meantime projects and employees are getting ruined.
That said, traditional management, like democracy, is the worst form of management, except for all the others.
Bad managers will never admit they're bad; they have bad employees. It's really hard for upper management to tell the difference. The early signs of bad management look a lot like bad employee performance. It takes time for a pattern of behavior to emerge, and in the meantime projects and employees are getting ruined.
That said, traditional management, like democracy, is the worst form of management, except for all the others.
I have never seen a "bad" manager exist under a "good" manager/director. Every single "bad" manager was able to survive and thrive because the environment was set up to encourage and reward the "bad" behavior.
If you are hiring and managing bad people, then the problem is not with them. It is with you. If you are unable to identify bad people under you, then you are failing at your most basic responsibility.
If you are hiring and managing bad people, then the problem is not with them. It is with you. If you are unable to identify bad people under you, then you are failing at your most basic responsibility.
Taking your argument to its conclusion, if there's a bad manager, then the director is bad, then the VP is bad, all the way up to the CEO. A single bad employee means the CEO is bad. I think we can both agree that stretches the definition of bad so far as to be meaningless.
Personally, I've seen bad managers under good directors. It's complicated. Anyone can make a bad hiring decision. My point is that even if you are able to identity bad people under you, that identification process takes time. The higher you go in a hierarchy, the longer the time horizon you tend to be evaluated on. To say it should be obvious on a very short time horizon is disingenuous and only covers the most egregious cases.
Personally, I've seen bad managers under good directors. It's complicated. Anyone can make a bad hiring decision. My point is that even if you are able to identity bad people under you, that identification process takes time. The higher you go in a hierarchy, the longer the time horizon you tend to be evaluated on. To say it should be obvious on a very short time horizon is disingenuous and only covers the most egregious cases.
> Bad managers will never admit they're bad; they have bad employees. It's really hard for upper management to tell the difference.
Speaking from upper management, I don't care for managers who blame their employees when things go wrong. They should have replaced those bad employees before things went wrong. That manager is on the way out if he's working for me.
Speaking from upper management, I don't care for managers who blame their employees when things go wrong. They should have replaced those bad employees before things went wrong. That manager is on the way out if he's working for me.
>Team members don't need to be "heard," or need sympathy from managers, they need confidence that their leadership understands the environment they work in, takes responsibility for decisions, and gives them direction based shared competence.
This is 100% the worst advice. It's a sign that you are a bad leader.
There are two components of leadership. Managing up and managing down. In order to gain a leadership position all you need to know is how to manage up well.
Because there is little need to know how to manage down in order to gain a leadership position you see a lot of incompetent leaders everywhere.
The quote above is 100% a sign of someone who does not know how to manage down. Yes you need to take responsibility. This is called managing up.
But Team members do need to be heard this is the most critical aspect of leadership and managing down.
This is 100% the worst advice. It's a sign that you are a bad leader.
There are two components of leadership. Managing up and managing down. In order to gain a leadership position all you need to know is how to manage up well.
Because there is little need to know how to manage down in order to gain a leadership position you see a lot of incompetent leaders everywhere.
The quote above is 100% a sign of someone who does not know how to manage down. Yes you need to take responsibility. This is called managing up.
But Team members do need to be heard this is the most critical aspect of leadership and managing down.
Can appreciate the reaction, but management and leadership aren't therapy.
There is only one component of leadership, and it is the definition: it is the effect of being followed. You can't fake it because it is an effect, not a result. It only happens with willingness in others that is the result of trust, earned through establishing legitimate authority.
Management is literally the effect of compromise between competing factors, with feedback into influencing those factors, and %80 of your effort spent on maintaining the ability to influence them.
In this sense, the difference between management and leadership is like that of a thermostat and the weather.
There is only one component of leadership, and it is the definition: it is the effect of being followed. You can't fake it because it is an effect, not a result. It only happens with willingness in others that is the result of trust, earned through establishing legitimate authority.
Management is literally the effect of compromise between competing factors, with feedback into influencing those factors, and %80 of your effort spent on maintaining the ability to influence them.
In this sense, the difference between management and leadership is like that of a thermostat and the weather.
I'd argue that good managment can often be quite close to therapy (albeit a little less personal). Getting the best out of people starts with understanding where they are coming from, what their needs and desires are, and ensuring that as a group, they are meeting each others.
Leadership is a different thing.
Leadership is a different thing.
I am not sure on which part you are reacting. For instance from the article:
> The first thing I settled on was to have one publicly announced engineering lead per project. I did this to make ownership clear
It seems to be very close to what you are advocating, short of the leader being a manager.
If it's the leader not being a manager that you see as misguided, I'd raise two points:
- you need people to progressively get experience in leadership before becoming dedicated leaders. I am a proponent of people growing into a role before getting labelled with it. Taking ownership of a single specific project seems to be a good way to achieve this.
- a single manager overseeing a multitude of projects is good only if the projects don't matter or the manager doesn't do much on each of them. Otherwise a person focused on the subject will yield better results in my experience (and if the manager doesn't do much, they shouldn't take responsibility or ownership)
> The first thing I settled on was to have one publicly announced engineering lead per project. I did this to make ownership clear
It seems to be very close to what you are advocating, short of the leader being a manager.
If it's the leader not being a manager that you see as misguided, I'd raise two points:
- you need people to progressively get experience in leadership before becoming dedicated leaders. I am a proponent of people growing into a role before getting labelled with it. Taking ownership of a single specific project seems to be a good way to achieve this.
- a single manager overseeing a multitude of projects is good only if the projects don't matter or the manager doesn't do much on each of them. Otherwise a person focused on the subject will yield better results in my experience (and if the manager doesn't do much, they shouldn't take responsibility or ownership)
> Taking direction or orders from a manager is only ever stressful if that manager doesn't take accountability for their decisions and directions.
This right here.
I will lead if you want. But then stop second guessing my decisions, and stop taking credit for my successes.
If you want to lead, fine. But then stop blaming me for failures, and admit when you screw up.
I am sick of being micromanaged and then blamed for when things go wrong.
This right here.
I will lead if you want. But then stop second guessing my decisions, and stop taking credit for my successes.
If you want to lead, fine. But then stop blaming me for failures, and admit when you screw up.
I am sick of being micromanaged and then blamed for when things go wrong.
> Team members don't need to be "heard,"
For leadership, correct. For management, false.
In software engineering, the people who know are at the bottom, so you better listen to them when you need estimates, technical solutions, architectural insight, etc.
Throw away your 1-on-1's at your own peril. As a manager you should make sure your team members can do their job, and that includes listening to the problems they face.
As a leader you set the course, so day-to-day operational things are indeed less relevant.
For leadership, correct. For management, false.
In software engineering, the people who know are at the bottom, so you better listen to them when you need estimates, technical solutions, architectural insight, etc.
Throw away your 1-on-1's at your own peril. As a manager you should make sure your team members can do their job, and that includes listening to the problems they face.
As a leader you set the course, so day-to-day operational things are indeed less relevant.
Top down management doesn't work in software engineering unless you are in an industry that does not value creative solutions (which is possible, some industries want extreme reliability and this means less exploration for solutions). In other words, what is the point of giving instructions/directions to someone who is supposed to be a problem solver (a.k.a. engineer)? There is no point to hire problem solvers and then give them specific solutions to your problems.
The article doesn't suggest that.
The article suggests having a single lead per project. But each project is led by a different engineer.
You still have 1 leader per project, but everyone on the team gets the leadership opportunity and experience.
The article suggests having a single lead per project. But each project is led by a different engineer.
You still have 1 leader per project, but everyone on the team gets the leadership opportunity and experience.
There is a spectrum though between the leader taking all the accountability and team members taking all the accountability. The leader can be accountable for pointing in the right direction and providing sufficient resources while the team members can be accountable for the execution.
Reality is no single person is going to know enough to solely be responsible for everything. A manager of a sizable team is not going to know the details enough to know the right approach for everything.
I’m a big fan of providing context to team members and having a dialog instead of just delegating everything top down. But in this kind of environment accountability can still be made clear.
Reality is no single person is going to know enough to solely be responsible for everything. A manager of a sizable team is not going to know the details enough to know the right approach for everything.
I’m a big fan of providing context to team members and having a dialog instead of just delegating everything top down. But in this kind of environment accountability can still be made clear.
Aside from severe competency issues I would agree. But I don't think classical "leader" properties are important. I agree that a manager may need a certain distance, but that depends on the team. Engineering is a creative process and too much structure kills innovation.
A manager should be the slightly less annoying customer that ensures customer perspectives are not neglected and work is prioritized in a matter that ensures project viability and success. And can clearly tell what he needs. Granted, that is quite rare in the industry. Especially those that can organize and take responsibility.
A manager should be the slightly less annoying customer that ensures customer perspectives are not neglected and work is prioritized in a matter that ensures project viability and success. And can clearly tell what he needs. Granted, that is quite rare in the industry. Especially those that can organize and take responsibility.
> If you want to be liked, just be nice.
If only it worked that way.
If only it worked that way.
How about the counterargument that 10 heads are better than 1?
Not always. In many cases 10 heads = 9 people criticizing/undermining 1.
Effective teams are built on people who trust and respect each other. Leadership must be recognized by a majority of group members for any person to take the lead - and any person can lead at any time if they have the group's best interests in mind and are able to demonstrate that.
Effective teams are built on people who trust and respect each other. Leadership must be recognized by a majority of group members for any person to take the lead - and any person can lead at any time if they have the group's best interests in mind and are able to demonstrate that.
I'm thinking of the scenario where 10 people all help solve the problems, vs when 1 person does all the thinking, and then hands out orders to the other 9.
Scenario 1 is obviously better, at least if the people are reasonably smart.
That doesn't mean all 10 are coequal leaders, and how to organize things so responsibility dynamics work well is... outside the scope of this comment. Also, I don't have a complete answer :)
Scenario 1 is obviously better, at least if the people are reasonably smart.
That doesn't mean all 10 are coequal leaders, and how to organize things so responsibility dynamics work well is... outside the scope of this comment. Also, I don't have a complete answer :)
This is the basis of the book, The Five Dysfunctions of a Team. A dysfunctional team will tear itself apart given run of the place. There's a lot of ground work that has to go into getting a team to the point where they can even enact what's in the article.
https://en.wikipedia.org/wiki/The_Five_Dysfunctions_of_a_Tea...
There's also a lot of work that goes into maintaining delegations at this level. I really like this article, because this part is actually covered in relatively high detail. Normally it's not addressed at all... "Just delegate!"
https://en.wikipedia.org/wiki/The_Five_Dysfunctions_of_a_Tea...
There's also a lot of work that goes into maintaining delegations at this level. I really like this article, because this part is actually covered in relatively high detail. Normally it's not addressed at all... "Just delegate!"
I'm reminded of a quote from The Office:
> Look, it doesn't take a genius to know that any organization thrives when it has two leaders. Go ahead, name a country that doesn't have two presidents. A boat that set sail without two captains. Where would Catholicism be...without the Popes.
Notice that throughout the article, the author is still in charge of the overall strategy, granting each lead their authority, requiring status updates.
> Look, it doesn't take a genius to know that any organization thrives when it has two leaders. Go ahead, name a country that doesn't have two presidents. A boat that set sail without two captains. Where would Catholicism be...without the Popes.
Notice that throughout the article, the author is still in charge of the overall strategy, granting each lead their authority, requiring status updates.
"name a country that doesn't have two presidents". A lot of countries are run by a government with a cabinet of ministers. There's a lot of negotiation. Many decisions are collective. In fact many governments are an example of what the article is taking about.
The Catholic Church is an authoritarian organisation and that structure has caused it some extreme problems leading to its demise in many parts of the world.
That said, it is a good joke.
The Catholic Church is an authoritarian organisation and that structure has caused it some extreme problems leading to its demise in many parts of the world.
That said, it is a good joke.
However there is still a "Prime Minister" which picks the cabinet.
I would prefer less responsibility taken by now. Managers assigning all the work to themselves (im the only one competent) and then getting nothing done is the most widespread phenomena i currently see.
First, massive disaffection with typical management is what leads to schemes like this. Especially when it comes to non-technical management, they are not equipped to do any of what you wrote. Not that technical management would be great or something. I am not fan of "everyone is leader" organization, but I am aware that contemporary management is not capable of all that much.
> Team members don't need to be "heard," or need sympathy from managers
I do actually want my opinions, ideas and preferences to be heard. If I think that I am not being heard, I prefer to change the team so that I am heard. If I don't change team and I am not heard, I work in more checked-out mode - which is pretty normal. It is doing somebodies domain, I cant take full responsibility if all decisions are somebody elses. thinking more about them just frustrates, so it is natural adaptation to avoid doing that.
> Taking direction or orders from a manager is only ever stressful if that manager doesn't take accountability for their decisions and directions.
Not true. For me, I am actually more stressed when I cant make own decisions, cant influence what affects me or dont have autonomy. Even when management takes responsibility for decisions and directions, purely top down management or micromanagement is stresor and demotivator.
> they need confidence that their leadership understands the environment they work in, takes responsibility for decisions, and gives them direction based shared competence
Leadership that does not hear people who work on the projects, can not understand the environment those people work in. Nor I see space for "shared competence".
> Team members don't need to be "heard," or need sympathy from managers
I do actually want my opinions, ideas and preferences to be heard. If I think that I am not being heard, I prefer to change the team so that I am heard. If I don't change team and I am not heard, I work in more checked-out mode - which is pretty normal. It is doing somebodies domain, I cant take full responsibility if all decisions are somebody elses. thinking more about them just frustrates, so it is natural adaptation to avoid doing that.
> Taking direction or orders from a manager is only ever stressful if that manager doesn't take accountability for their decisions and directions.
Not true. For me, I am actually more stressed when I cant make own decisions, cant influence what affects me or dont have autonomy. Even when management takes responsibility for decisions and directions, purely top down management or micromanagement is stresor and demotivator.
> they need confidence that their leadership understands the environment they work in, takes responsibility for decisions, and gives them direction based shared competence
Leadership that does not hear people who work on the projects, can not understand the environment those people work in. Nor I see space for "shared competence".
> I do actually want my opinions, ideas and preferences to be heard. If I think that I am not being heard, I prefer to change the team so that I am heard.
I think this is a valid expectation. At the same time, it can lead to conflict and confusion if not itself managed effectively.
One thing we've done with our team that I think has addressed this pretty well is RFCs (Request for Comments). This is mainly for team practice stuff but also can address important technical questions.
We use a Trello board where anyone on the team can add a card and then team members can comment on cards. Team leads then review the board in a 30-min meeting every couple weeks to make sure cards get acted on or otherwise resolved to everyone's satisfaction.
Each RFC card is also assigned an owner from the team, a practical example I suppose of everyone being a leader.
I think this is a valid expectation. At the same time, it can lead to conflict and confusion if not itself managed effectively.
One thing we've done with our team that I think has addressed this pretty well is RFCs (Request for Comments). This is mainly for team practice stuff but also can address important technical questions.
We use a Trello board where anyone on the team can add a card and then team members can comment on cards. Team leads then review the board in a 30-min meeting every couple weeks to make sure cards get acted on or otherwise resolved to everyone's satisfaction.
Each RFC card is also assigned an owner from the team, a practical example I suppose of everyone being a leader.
The scheme described in the article does much more. It gives you not just ability to express yourself on card, but also ability to make decisions in limited area and have responsibility for them.
I don't think being assigned task or issue is same as "being leader". In article it is more about subprojects themselves having responsible people - and people having responsibility for subprojects. So there is not one team leader responsible for everything, but various people responsible for their smaller parts and changing teams.
It is not about everyone agreeing with everything and having all they want. It is much more about autonomy and accountability - which are the core motivators in normal people management theory and there is not reason to think IT people are so different that they don't need them.
I don't think being assigned task or issue is same as "being leader". In article it is more about subprojects themselves having responsible people - and people having responsibility for subprojects. So there is not one team leader responsible for everything, but various people responsible for their smaller parts and changing teams.
It is not about everyone agreeing with everything and having all they want. It is much more about autonomy and accountability - which are the core motivators in normal people management theory and there is not reason to think IT people are so different that they don't need them.
The person who knows you best is yourself. By that token, your manager will have less insight into you than you do. So defaulting to their judgement for everything will lead to decisions that are sub-optimal or upset you.
You make some good points about responsibility and accountability. But team members absolutely need to be, and feel, heard.
Also, there's a world of difference between "managing" and "leading". Conflating the two is a root cause of many problems.
Also, there's a world of difference between "managing" and "leading". Conflating the two is a root cause of many problems.
> Also, there's a world of difference between "managing" and "leading". Conflating the two is a root cause of many problems.
Exactly. I think the military distinction between command (leadership) and control (management) is very relevant here. One is setting overall enterprise goals and defining personal missions in this context. The other is checking resources, constraints, reporting, etc. These two are very different, hence the fundamental military distinction between the commander and his chief of staff.
Exactly. I think the military distinction between command (leadership) and control (management) is very relevant here. One is setting overall enterprise goals and defining personal missions in this context. The other is checking resources, constraints, reporting, etc. These two are very different, hence the fundamental military distinction between the commander and his chief of staff.
You could also say one is defining/policing parameters, and the other is being the designated representative of the team’s choices within those parameters.
The manager defines the “no” (boundaries of what’s acceptable) the leader defines the “yes” (what will the team do next given the demands).
People often try to do both, which means defining a very narrow “you do this now” which ends up feeling authoritarian.
The manager defines the “no” (boundaries of what’s acceptable) the leader defines the “yes” (what will the team do next given the demands).
People often try to do both, which means defining a very narrow “you do this now” which ends up feeling authoritarian.
> I suggested two options to them:
> 1. Either we have another person do the project management - and they have no say in how this will be done. Perhaps we even entertain the idea of an external hire - who is not an engineer. They won't have the engineering context, so they'll ask for more frequent updates, and have more regular check-in meetings. Also, anytime something seems to be delayed, they will have to come to the engineers to ask them how and what can be mitigated.
Not listing his "option 2" since the description for "option 1" is already so loaded that it's obvious the correct answer is "anything but option 1". I can't say I'm a fan of such manipulation.
> After this chat, everyone went with option #2.
Surprise, surprise.
Ultimately, the problem with these kinds of wisdom posts is that they suffer from the "everyone is the same, given the right chance or push" fallacy. We love it when the parts are all the same because it reduces our cognitive load, but that just doesn't happen in reality, especially with people. We can see from his "options" that he ran up against this problem, and solved it by forcing people to adopt the mold he'd set for them. Now everyone's a leader! Problem solved.
> 1. Either we have another person do the project management - and they have no say in how this will be done. Perhaps we even entertain the idea of an external hire - who is not an engineer. They won't have the engineering context, so they'll ask for more frequent updates, and have more regular check-in meetings. Also, anytime something seems to be delayed, they will have to come to the engineers to ask them how and what can be mitigated.
Not listing his "option 2" since the description for "option 1" is already so loaded that it's obvious the correct answer is "anything but option 1". I can't say I'm a fan of such manipulation.
> After this chat, everyone went with option #2.
Surprise, surprise.
Ultimately, the problem with these kinds of wisdom posts is that they suffer from the "everyone is the same, given the right chance or push" fallacy. We love it when the parts are all the same because it reduces our cognitive load, but that just doesn't happen in reality, especially with people. We can see from his "options" that he ran up against this problem, and solved it by forcing people to adopt the mold he'd set for them. Now everyone's a leader! Problem solved.
After thirty years in this industry, I've learned that in a good environment, almost any process or team organization will work, but in a bad environment, nothing will help. :/
Very true. In the end it comes down to respect, trust and honesty with each other. For some reason organizations always want to build a layer of processes on top of a rotten foundation.
A simple question to ask would be “do you trust your leadership and your colleagues “? And for leadership “do you trust your people?” If the answer is “no” you already have identified the problem and no process or organizational structure will help.
Obviously these questions will never be asked because the response will be inconvenient.
A simple question to ask would be “do you trust your leadership and your colleagues “? And for leadership “do you trust your people?” If the answer is “no” you already have identified the problem and no process or organizational structure will help.
Obviously these questions will never be asked because the response will be inconvenient.
The places I’ve worked at where “everyone is a leader” ends up with 1 person feeling adamant about something. And everyone else disagreeing, but then saying: sure whatever, we will do it that way.
Nobody wants to have conflict and nobody is in charge. Leads to a lot of very bad decisions imo.
Nobody wants to have conflict and nobody is in charge. Leads to a lot of very bad decisions imo.
"Flat" organizations I've worked at, the day-to-day works alright since we could actually be "Agile" and chop features off to deliver on time and make other decisions like that. Now big picture items like which projects we do - it was all decided by a small group of founders/early employees who had a lot of political and informal power which was very frustrating.
Agreed. In my one experience with "self-organizing" teams, there was one individual who always got his way because he was so unpleasant otherwise. IMHO that had a terrible impact on the resulting software.
Completely agree. And the product or project is typically super chaotic.
My first dev job saw this fad come through the department one season. It went from "Here's your feature for this week, please implement it" to "Here's your feature for this week, you're the leader for development on this! Please implement it.". I understand that middle management has basically nothing to actually do, so it invents shit like this, but it pisses us off that actually do something to have this weird changing layer of bullshit smeared over what is a feature factory job. You can't shine shit with buzz words.
Well if you're team lead now, then that comes with a title & pay bump right? If not, then management is just passing added responsibility to you without any additional risk to themselves.
Title is a bit bs
Their is a difference between ownership of a project and leadership. When they asked senior developers with experience to lead they had the vision granted by experience to do so. When they asked the juniors to lead they lead the project into trouble as they don't have the experience to see problems and judge risk well.
The success came from giving every one ownership, a stake in the project and work. But when making every one the lead they ran into the too many cooks spoil the broth problem, the solution was to give the juniors the same responsibility (ownership) but more leadership in how to achieve.
Their is a difference between ownership of a project and leadership. When they asked senior developers with experience to lead they had the vision granted by experience to do so. When they asked the juniors to lead they lead the project into trouble as they don't have the experience to see problems and judge risk well.
The success came from giving every one ownership, a stake in the project and work. But when making every one the lead they ran into the too many cooks spoil the broth problem, the solution was to give the juniors the same responsibility (ownership) but more leadership in how to achieve.
This is the type of article that new engineering managers should bookmark and re-read every few months. Is the advice perfect? No, but it will probably bring some new perspective to some problems you'll have along the way. There is no one size fits all management strategy that works in every situation, but every manager should be aware of the common pitfalls on the growth path of engineering managers.
In my personal experience as an engineering manager and in mentoring new engineering managers, this is the tipping point where managers either succeed or spiral into burnout:
> I found myself and our product manager becoming the bottleneck in planning out who will work on what project, next, and who will be the lead.
If you find yourself bottlenecking the team, you're either micromanaging or your team has grown too large for a single level of management. You need to take the time to develop a new system that removes you as the bottleneck. Don't try to push through the issue by putting in more hours. That's not sustainable. Find a new system.
The "everyone is a leader" strategy described in this article is a good perspective on what every manager should be doing: Clearly defining ownership boundaries and expectations, while avoiding micromanagement. It's a common mistake to assume that because the manager is responsible for the success and failure of a project, the manager should also micromanage the critical decision making. That's the first trait that needs to be trained out of almost every engineer promoted to manager in my experience.
Some engineers instinctively reject anything that feels like a management responsibility. Others will demand promotions or raises for taking on basic ownership tasks. Often, these engineers started their careers in toxic environments where accountability was synonymous with "you're going to be fired if this fails". It's important to show these engineers that your environment really is safe, and that good things come from taking ownership. You have to back up your words with your actions, of course. IME, most engineers truly enjoy autonomy, ownership, and leadership once they can reasonably expect that it won't be used against them.
And of course, it's important to screen for these traits during the hiring process. It's also important to filter out engineers who can't or won't learn to take ownership of their work.
In my personal experience as an engineering manager and in mentoring new engineering managers, this is the tipping point where managers either succeed or spiral into burnout:
> I found myself and our product manager becoming the bottleneck in planning out who will work on what project, next, and who will be the lead.
If you find yourself bottlenecking the team, you're either micromanaging or your team has grown too large for a single level of management. You need to take the time to develop a new system that removes you as the bottleneck. Don't try to push through the issue by putting in more hours. That's not sustainable. Find a new system.
The "everyone is a leader" strategy described in this article is a good perspective on what every manager should be doing: Clearly defining ownership boundaries and expectations, while avoiding micromanagement. It's a common mistake to assume that because the manager is responsible for the success and failure of a project, the manager should also micromanage the critical decision making. That's the first trait that needs to be trained out of almost every engineer promoted to manager in my experience.
Some engineers instinctively reject anything that feels like a management responsibility. Others will demand promotions or raises for taking on basic ownership tasks. Often, these engineers started their careers in toxic environments where accountability was synonymous with "you're going to be fired if this fails". It's important to show these engineers that your environment really is safe, and that good things come from taking ownership. You have to back up your words with your actions, of course. IME, most engineers truly enjoy autonomy, ownership, and leadership once they can reasonably expect that it won't be used against them.
And of course, it's important to screen for these traits during the hiring process. It's also important to filter out engineers who can't or won't learn to take ownership of their work.
The challenge with this is when you have a team with members that, by and large, wants to be led for various reasons (lacking motivation, does not want to lead, distracted with other priorities, etc.). In a team like this, there needs to be someone that “calls the shots,” as it were, while giving every team member enough of a voice to feel like they are heard and enough autonomy to do the right thing (provided they have the skills).
Speaking of skills, this leadership approach fails hard when you are handed a team of people that are low-skilled, for whatever reason. Some of these folks can’t be let go (too expensive to do so, usually). Micromanagement usually works in this instance, especially if you can’t train
Speaking of skills, this leadership approach fails hard when you are handed a team of people that are low-skilled, for whatever reason. Some of these folks can’t be let go (too expensive to do so, usually). Micromanagement usually works in this instance, especially if you can’t train
I don't know if someone like that (the follower) is really capable of significantly contributing.
I strongly disagree. What even is a company or a product where no one decides on a direction?
What if I don't know the industry? What if I don't know the customer expectations of this product? Ideally you'll learn all that eventually but it can take a few years.
There are many, many people that love solving problems, but have no desire to get mired down into politics and power struggles.
In my experience, high-performing teams arise when every member has expertise that is acknowledged and respected by the rest of the group. As soon as you add skill+experience redundancy, performance will be hindered by jockeying to "be better than the others." If there is little growth opportunity in this skill area, it will have a much greater effect on performance as internal politics take over.
Clearly defined hierarchies are underrated, at least in this space. I really do not want to have seven bosses, or to be responsible for being part of some amorphous Valve-like leadership blob.
Setting up a clear chain of command, and, most essentially, following it, would perhaps stifle a few, but it works, and it works well, and it is a considerably less anxious and stress-inducing arrangement for everyone involved.
Setting up a clear chain of command, and, most essentially, following it, would perhaps stifle a few, but it works, and it works well, and it is a considerably less anxious and stress-inducing arrangement for everyone involved.
> where everyone can be a leader - and everyone would act as an owner
I suspect these are different things.
Everybody can have a sense of ownership? Sure (e.g. common goals, employee owned companies, options, etc).
If everybody is leading (at the same time), nobody is. It's good if anyone can assume leadership at any given moment, though.
Tacit leaders are more important (and respected) than explicit ones. Appointing a leader rarely works.
I suspect these are different things.
Everybody can have a sense of ownership? Sure (e.g. common goals, employee owned companies, options, etc).
If everybody is leading (at the same time), nobody is. It's good if anyone can assume leadership at any given moment, though.
Tacit leaders are more important (and respected) than explicit ones. Appointing a leader rarely works.
> Tacit leaders are more important (and respected) than explicit ones. Appointing a leader rarely works.
There are different use-cases for intrinsic and extrinsic leadership. Some actions work better when executed by one or the other.
There are different use-cases for intrinsic and extrinsic leadership. Some actions work better when executed by one or the other.
I am being in such a team and I tell you this is great. We are pretty flat, you can pick whatever title you want on your resume but here we are all engineers. My manager insists that he usually cannot make better decisions than we do, because we usually understand the problems better than him. His major request is that if anything gets stuck we need to raise it immediately so that it can be solved quicker and doesn't block others.
I've switched to saying "I'd vote for XYZ".
The most empowering form of leadership is pure democracy. I'm a bit dismayed that for all of our brilliant insights and expertise, we're so quick to replicate authoritarian power structures in our careers. There are some talks by Richard Wolff on YouTube about democracy in the workplace and I'd urge everyone here to watch them.
The most empowering form of leadership is pure democracy. I'm a bit dismayed that for all of our brilliant insights and expertise, we're so quick to replicate authoritarian power structures in our careers. There are some talks by Richard Wolff on YouTube about democracy in the workplace and I'd urge everyone here to watch them.
Any management strategy that is based on the assumption that everyone is the same and wants the same things and can act the same way is doomed to fail. I didn't see a single sentence about this person listening to and adapting to his team members as individual people. Some people might mumble the words, but aren't really interested in being leaders at all.
> Initially, my team was a team of eight engineers, from juniors to more senior members. Two years later, I have a team of triple the size, where most people have led a significant project, with mentorship/coaching support from a more experienced leader.
Huh. Two years. TBH that is not long enough to understand the sustainability of this approach. It's frustrating that people shout from the rooftops after one success like this.
There is some good advice in this post, but its hubris is galling. I would encourage the author of this post to continue growing and learning, maybe go through a failure or two, before speaking up.
> Initially, my team was a team of eight engineers, from juniors to more senior members. Two years later, I have a team of triple the size, where most people have led a significant project, with mentorship/coaching support from a more experienced leader.
Huh. Two years. TBH that is not long enough to understand the sustainability of this approach. It's frustrating that people shout from the rooftops after one success like this.
There is some good advice in this post, but its hubris is galling. I would encourage the author of this post to continue growing and learning, maybe go through a failure or two, before speaking up.
Everyone is a leader implies a more flat organization, this isn’t that. This is just talking about effectively delegating and having layers of organization within a team. Ie manager splits up the projects to project teams and a project leader and the leader with the team gets autonomy to run the project their own way with mentoring.
I think it’s a good approach and for me at least orders of magnitude better than top down micromanagement. But the title I think just confuses things.
Imagine that instead of “leaders” the smaller projects were their own teams and replace the leader with manager title and it’d be the same thing.
EDIT: btw I see the lack of clarity around accountability play out at organizations. Where for instance on practice responsibility is split. Maybe the “leaders” set the direction and the team executed. But when it comes to accountability, like when something goes wrong, fingers get pointed to only the team or only the leaders without examining which piece (direction vs execution) failed.
I think it’s a good approach and for me at least orders of magnitude better than top down micromanagement. But the title I think just confuses things.
Imagine that instead of “leaders” the smaller projects were their own teams and replace the leader with manager title and it’d be the same thing.
EDIT: btw I see the lack of clarity around accountability play out at organizations. Where for instance on practice responsibility is split. Maybe the “leaders” set the direction and the team executed. But when it comes to accountability, like when something goes wrong, fingers get pointed to only the team or only the leaders without examining which piece (direction vs execution) failed.
Reading this article I was reminded of the book It's Your Ship, the motto used by one navy captain to empower the crew to turn around a poorly performing ship. Then I see that part of the inspiration for this post was... a book about a different navy ship.
I often think back to It's Your Ship, I'd highly recommend it.
I often think back to It's Your Ship, I'd highly recommend it.
Dee Hock, the founding CEO of Visa, described a similar approach as chaordic leadership.
http://www.griequity.com/resources/integraltech/GRIBusinessM...
http://www.griequity.com/resources/integraltech/GRIBusinessM...
> By chaord, I mean any self-organizing, self governing, adaptive, nonlinear, complex organism, organization, community or system
What a strange word to avoid using anarchism.
What a strange word to avoid using anarchism.
It's better for everyone to be a leader than for the company to select the wrong leaders. But if the company is capable of picking leaders well, then that's better. But it's much harder than it looks and most companies get it completely wrong.
I wonder how this works for large scale engineering architectures and unified approaches. Seems like it'd lead to a lot of disjointed projects and pieces each with a different approach. That in turn adds cognitive overhead to an organization and lowers the bus factor.
The replies here are so telling, many would not survive on such a team. However, their perspective is critical to understanding who you must exclude to make this system work, and the kind of passion required for people to feel the sense of ownership needed.
Isn't this the same as DRI (Directly responsible individual ) at Apple?
[deleted]
this is a repost from less than 3 months ago. sorry i don’t have the url.
and sorry, but if you don’t have accountability you aren’t a leader.
and sorry, but if you don’t have accountability you aren’t a leader.
Taking direction or orders from a manager is only ever stressful if that manager doesn't take accountability for their decisions and directions. I'm not sure the solution to that is a new framework where managers can direct without responsibility or accountability. Set a bar for managers that includes ownership, and the ability to delegate responsibility while persuading staff to willingly take on their own level of ownership.
This "manager as peer," approach I have seen in a number of organizations is dishonest and seems to just mean forfeiting responsibility, while opportunistically cherry picking successes to take credit for.
Team members don't need to be "heard," or need sympathy from managers, they need confidence that their leadership understands the environment they work in, takes responsibility for decisions, and gives them direction based shared competence.
Of the problems to solve for, improving the quality and selection of managers seems smarter than contorting ourselves into new frameworks to work with ones who avoid responsibility.
If you want to be liked, just be nice. If you want to be respected, take responsibility.