9 ms·

Bad engineering managers think leadership is about power

72 points by sidcool 5y ago

chunkyfunky 5y ago
I can't say I disagree with many of the points made in the article, but I am getting just a little tired of what I perceive to be the current trend of generalised manager-bashing these days...I transitioned from dev to manager a few years back and whilst I'm definitely not the greatest leader ever, I am also definitely not anything like the tired stereotypes portrayed in the article (case in point: when a dev tells me "two weeks" I smile and say "I believe you meant SIX weeks, right?". And then it takes 4, but everyone's happy cos the stakeholders got it 2 weeks "early" and the dev can sleep at night knowing the code is rock solid. etc. This "Us vs Them" thing is bollox - we're all on the same team as far as I am concerned! And, even though I have a good 20+ years of development behind me, I can honestly say that the two BEST engineering managers I ever had were people that could not have written a line of code to save their lives...they were just brilliant leaders and motivators who focused on me as an individual and trusted me enough to have the technical chops to get the job done whilst they meat-shielded us against waves of shite from the C-suite. Well anyway, what would I know, I'm just a dumb-ass manager :)
- abc_lisper 5y ago
  > I can honestly say that the two BEST engineering managers I ever had were people that could not have written a line of code to save their lives This is some truth to this. On the other hand, there are a lot of dumb-ass power wielding managers who think technical chops are low level stuff and look down on the engineers. The second group outweighs the first by a factor of 3 at least
- routerl 5y ago
  > we're all on the same team as far as I am concerned Your peers have burned through all the believability of this line, by using it when it is a lie.
  - AnimalMuppet 5y ago
    The manager who actually believes it, and lives it, will eventually be believed. The managers who parrot it will be ignored.
    - tcbawo 5y ago
      This reminds me of something that came up a while ago here, Lou Holtz's three questions asked of a leader: Can I trust you? Are you committed? Do you care about me?
- existencebox 5y ago
  > when a dev tells me "two weeks" I smile and say "I believe you meant SIX weeks, right?" Wanted to chime in and say _thank you_ for giving me the prompt that this is an "OK" thing to do. (as a technique for trying to encourage/help devs build in good buffer) As another dev-converted-to-manger, who was also somewhat taken back by that same perception of the malicious manager (I certainly had that perception from time to time as an eng, so it's not entirely foreign although I am surprised by how widespread it seems to have become) what you've written really resonates with me; One consequence is that I've become way more forgiving (in terms of trying to proactively improve it) for what I used to perceive as "bad management" as I struggle to improve my own techniques :P > This "Us vs Them" thing is bollox - we're all on the same team as far as I am concerned! I swear I want to scream this from the rooftops in many of the ragging-on-management threads I see but I know it's not the dev's fault for feeling miffed, a bad manager can _wreck_ your life, but I wish I had a magic password I could tell devs to let them know "I'm here to make you/your work successful, not the other way around, and if I'm ever failing at that I _want to fix it_." (As sister responses point out, this is something earned, and fully agree, it can just often be an uphill battle, potentially rationally from what devs have experienced prior; again just trying to give everyone in the picture the benefit of the doubt as I'd hope they would me.) > what would I know, I'm just a dumb-ass manager You're in good company :)
Tarucho 5y ago
Basically an article from a dev trying to portrait herself as a good prospective manager by writing about things that have been repeated ad-nauseam. >The services of a good leader is an important gap that development teams desperately need filled. However, very few managers know how to properly serve software development teams. And of course the author knows.
- emma-w 5y ago
  >And of course the author knows. Author here, I don't actually know, I'm still learning. But I know that by observation most of my peers are truly ignorant and just winging it. Fixing that would make life better for everyone.
  - Tarucho 5y ago
    >Author here, I don't actually know Why are you writing authoritatively about something you know you don´t actually know then?
    - s_fischer 5y ago
      My take away was that the author doesn't necessarily claim to have all the answers here. It's more of a list of general guidance that is reverse engineered from the type of behavior the she observed was definitely unsuccessful.
    - emma-w 5y ago
      Because traditional authoritative sources that I would look to for guidance are completely out of date. From where I sit it looks to me like they are more focused on milking endowments than discovering what is happening in the real world.
nine_zeros 5y ago
3 tips to managers who are confused about what their own job is - Enable and empower your engineers - Be an unblocker. Do not judge engineers reaching out to you. Just unblock. - Promote your engineers aggressively. Market their work around the company. Let them feel like their work is important enough for you to take time to market around. Give them actual promotions when it's due Don't do the following - Stealing credit - Pushing people issues back onto your engineers just because you are scared if talking to others - Impede their work by micromanaging their execution (stop blocking PRs on bullshit nits, stop blocking docs on formatting. None of this is consequential to the actual project) - Do not bullshit and lie about promotions - Do not insert yourself into every step. Let engineers take charge and also suffer the consequences of their decisions - Practice what you preach. If you ask everyone on the team to write a doc for their projects, you need to do it for your own. If not, your hypocrisy is visible easily and you will lose respect. Lastly, remove the boss attitude. You are working with people who are perhaps more skilled than you. Work with mutual respect, not with supervisory dictatorship.
- emma-w 5y ago
  This.
- mic47 5y ago
  Couldn't agree more.
xyzzy21 5y ago
Sad. Because that's what "management" is: action by authority of position in the org chart. That's 100% NOT what leadership is. Leadership is action by people voluntary following the leader. It's a profound difference!
- P_I_Staker 5y ago
  This isn't really understood by many of the people that push "leadership". At a certain point you also have the problem where the type of people that want management jobs, are the kind of people that want power. Leadership can really suck. It often means more work, stress, and people disliking you. I was talking to a college friend that's a CTO and was taking calls as his baby was being delivered. He could probably have most of the same stuff as a standard developer and live very comfortably. There's something up with someone that really wants to take that tradeoff. I'm not judging or manager bashing either. I'm sure if any of you read this you're one of the ones in it for the great things you can accomplish, and to build an excellent team that's totally safe and healthy!
- drewcoo 5y ago
  But "servant management" raises too many ugly questions. Is that really managing the servants or serving management?
rramadass 5y ago
Why do people insist on not facing Reality? Management/Leadership IS about Power/Conflict/Negotiation/Human Behaviour/Goals. It is the process which is used to achieve these objectives i.e. whether by Diktat (conventional organizational management) or by Cooperation/Empathy (not easy at all) that varies. Some selected resources: * Speech by Dave Packard to HP Managers - https://gizmodo.com/the-hp-way-how-bill-hewlett-and-i-built-our-company-5634378 https://gizmodo.com/the-hp-way-how-bill-hewlett-and-i-built-... * Management: A Political Activity by Ted Stephenson. * Managing with Power by Jeffrey Pfeffer. * Leadership BS: Fixing Workplaces and Careers One Truth at a Time by Jeffrey Pfeffer. * Power: Why Some People Have It―and Others Don't by Jeffrey Pfeffer.
- marcus_holmes 5y ago
  This, I think, is the crux of the problem. A manager, traditionally, has the power. They can hire and fire, and have the organisation's power structure behind them. But in a software team, the devs have the power and they know it. There is literally nothing a manager can do to make the project go faster or be successful if the devs don't co-operate. And often the manager has no visibility into the process and don't understand what's going on or why. For a lot of (bad) managers this makes them very insecure, and they react badly. It also puts them in a very difficult situation. For example: if the rest of the management team agree on a deadline that they would like the devs to meet, the dev manager is put in the awkward position of having to ask the devs if they can meet it, and then carrying the answer back to the management team, and generally being a go-between rather than in control. The temptation is clearly to agree to the deadline and then impose it on the dev team. It becomes a conflict situation where the dev manager has to pick a side and either fight the dev team or fight the rest of the organisation. Avoiding this is tricky. Managing without power can be difficult.
  - discreteevent 5y ago
    > It becomes a conflict situation where the dev manager has to pick a side and either fight the dev team or fight the rest of the organisation. I think that describes a weak dev manager because they immediately got caught in the trap of playing a fictional estimation game instead of trying to deal with reality. A strong dev manager will communicate the risk to the rest of the managment team. Then they will make decisions based on risk and reward and educate the rest of the managment team about that. If the rest of the managment team wants to pretend that risk doesn't exist and that they want to be shielded from reality then they in turn are weak and there is not much you can do about it. (other fields are similar, e.g. the military).
dasil003 5y ago
After straddling the line of IC to EM to CTO in orgs from 1 to 25k employees over the past 20 years, I have to say the truth of engineering management failure is so much more nuanced and subtle than what is portrayed here. Yes, there are plenty of power-hungry blow-hards and clueless pointy hairs without a lick of talent, but I honestly believe the majority of managers are trying to do a good job, but ultimately it's a really really hard job and the failure modes are extremely diverse. As an IC you might not have visibility to even properly judge the situation. There are questions of strategy, communication, priorities, performance management, micro-managing, giving someone more than they can handle, technical debt vs velocity, quality balance on critical code vs leaf-node code, individual strengths and weaknesses, bus factors, overall morale, cross-functional differences, strategic priorities, cost centers vs profit centers, business landscape, difficult but talented people, easy-going but over-committing people, capable but unmotivated people, etc. To paraphrase Tolstoy: all happy teams are alike, but every unhappy team is unhappy in its own way.
- vieux_vague 5y ago
  The dizzying list of competing priorities is a great way of showing how much a manager must juggle. I'm not a manager but an IC leading projects at a FAANG company. The engineers are very competent and my responsibilities are a fraction of a manager's and yet I really struggle with many of the things in your list. For example, the capable but somehow-unable-make-solid-progress engineer who's been in this mode for 2 years and nothing I (or others) have tried has got them out of this. My current manager is great and also very transparent about everything they do; this has given me new-found respect for a difficult and thankless role.
  - darkwater 5y ago
    > I'm not a manager but an IC leading projects at a FAANG company. The engineers are very competent and my responsibilities are a fraction of a manager's and yet I really struggle with many of the things in your list. Out of curiosity, what are the tasks you are supposed to do in your position and how different are from a manager's or a - let's say - project manager's? Thanks!
jordanbeiber 5y ago
As a leader of 25 young’ish software developers I’ve come to realize that the lack of history is both a blessing and a curse. > If I’m a leader that is serving a team of people doing manufacturing work, there are scientifically proven processes and techniques that can be readily trained and applied. And someone who learns those manufacturing management techniques can reliably boost team productivity. The same cannot be said for software leaders Leadership is one thing, process of work something else. Using techniques from manufacturing is one of the most effective ways of improving output and quality of a software team. The Lean principles matches up quite quite well with the work of producing software. This, however, does not in any way imply that you should treat devs (or people in general) like machines. Work process is incredibly important to create a professional and able organization - leading people here without infringing on their motivation, continuous learning and control is what management is about (to me at least). Many of my young devs have not lived through the 90s and 00 with it’s projects and outsourcing/off-shoring strategies. They’ve landed in the aftermath of an agile revolution turned a beast in it self. They’ve seen nothing else and are forced to accept it. My job is to have them level up and pick the cherries out of the mess we’re in. Have them make it theirs - have them own the process. Agile, in my mind, is about professionalism, ownership and accountability on behalf of the devs. Give them the freedom to claim the above and an insane output can be achieved while having fun. Simple but clear process should surround this work, but the ”why” have to be internalized by the team.
marcus_holmes 5y ago
Software developer with an MBA here. MBA courses do in fact teach servant leadership style (which is what the article is advocating). As a software dev manager, I found the MBA to be useful for three reasons: 1. I could understand the rest of the management team better, and learned the appropriate technical terms to talk to them about the problems they faced. As always, it's easier to reduce conflict if you understand the other participant's problems and objectives. 2. The people-management and leadership training was actually useful, and has been useful since when dealing with some tough people problems. 3. There is, to some extent, a dismissive "you're just a code monkey" attitude amongst some managers. Having an MBA does help with dealing with that. It's difficult to dismiss me as just the nerd who pushes the nerd-buttons when I'm more qualified than them in their own area. I'm not sure I'd recommend that all software dev leads go and get an MBA - it's definitely overkill. But on the other hand, dismissing the entire corpus of management learning as irrelevant because software dev is special is also overkill. There are things to learn from traditional management courses. Devs are still people, after all, and managing them as people is still the same. I do think that a dev manager should be able to code, and preferably have worked as a commercial developer at some point in their past. It does help with understanding the situation and the problems. And it's almost impossible to get any respect from the team if you can't talk the talk and haven't walked the walk. I have experienced the bad management that the author talks about, and seen it in action. But I don't think this is unique to development - there is a lot of bad management around in all industries. The answer to this is more management training, not less ;) Getting dev managers onto management courses is still going to be a net good because they'll be better managers, even if they still don't understand why they can't get accurate estimates for anything. If the author goes on to manage a team for a few years, I'd be interested to read their take on it then. The view is very different from the other side.
flashgordon 5y ago
I am slightly worried about all these manager related articles use the term "manager" in a negative light but "leader" in a positive light. Are there no bad leaders (umm I am pretty sure Hitler wouldn't be labelled a manager)? Wouldnt the title "Bad engineering leaders think..." Or even "Bad leaders think ..." Be just as apt? There are ineffective and toxic behaviors everywhere and just labelling a class of jobs seems scary. By the way I have gone between IC and management (even managing managers) and the "badness" I've witnessed (and sadly also partaken in) was never localized!

72 points by sidcool 5y ago

I can't say I disagree with many of the points made in the article, but I am getting just a little tired of what I perceive to be the current trend of generalised manager-bashing these days...I transitioned from dev to manager a few years back and whilst I'm definitely not the greatest leader ever, I am also definitely not anything like the tired stereotypes portrayed in the article (case in point: when a dev tells me "two weeks" I smile and say "I believe you meant SIX weeks, right?". And then it takes 4, but everyone's happy cos the stakeholders got it 2 weeks "early" and the dev can sleep at night knowing the code is rock solid. etc. This "Us vs Them" thing is bollox - we're all on the same team as far as I am concerned! And, even though I have a good 20+ years of development behind me, I can honestly say that the two BEST engineering managers I ever had were people that could not have written a line of code to save their lives...they were just brilliant leaders and motivators who focused on me as an individual and trusted me enough to have the technical chops to get the job done whilst they meat-shielded us against waves of shite from the C-suite. Well anyway, what would I know, I'm just a dumb-ass manager :)

abc_lisper 5y ago
> I can honestly say that the two BEST engineering managers I ever had were people that could not have written a line of code to save their lives This is some truth to this. On the other hand, there are a lot of dumb-ass power wielding managers who think technical chops are low level stuff and look down on the engineers. The second group outweighs the first by a factor of 3 at least
routerl 5y ago
> we're all on the same team as far as I am concerned Your peers have burned through all the believability of this line, by using it when it is a lie.
- AnimalMuppet 5y ago
  The manager who actually believes it, and lives it, will eventually be believed. The managers who parrot it will be ignored.
  - tcbawo 5y ago
    This reminds me of something that came up a while ago here, Lou Holtz's three questions asked of a leader: Can I trust you? Are you committed? Do you care about me?
existencebox 5y ago
> when a dev tells me "two weeks" I smile and say "I believe you meant SIX weeks, right?" Wanted to chime in and say _thank you_ for giving me the prompt that this is an "OK" thing to do. (as a technique for trying to encourage/help devs build in good buffer) As another dev-converted-to-manger, who was also somewhat taken back by that same perception of the malicious manager (I certainly had that perception from time to time as an eng, so it's not entirely foreign although I am surprised by how widespread it seems to have become) what you've written really resonates with me; One consequence is that I've become way more forgiving (in terms of trying to proactively improve it) for what I used to perceive as "bad management" as I struggle to improve my own techniques :P > This "Us vs Them" thing is bollox - we're all on the same team as far as I am concerned! I swear I want to scream this from the rooftops in many of the ragging-on-management threads I see but I know it's not the dev's fault for feeling miffed, a bad manager can _wreck_ your life, but I wish I had a magic password I could tell devs to let them know "I'm here to make you/your work successful, not the other way around, and if I'm ever failing at that I _want to fix it_." (As sister responses point out, this is something earned, and fully agree, it can just often be an uphill battle, potentially rationally from what devs have experienced prior; again just trying to give everyone in the picture the benefit of the doubt as I'd hope they would me.) > what would I know, I'm just a dumb-ass manager You're in good company :)

Tarucho 5y ago

Basically an article from a dev trying to portrait herself as a good prospective manager by writing about things that have been repeated ad-nauseam. >The services of a good leader is an important gap that development teams desperately need filled. However, very few managers know how to properly serve software development teams. And of course the author knows.

emma-w 5y ago
>And of course the author knows. Author here, I don't actually know, I'm still learning. But I know that by observation most of my peers are truly ignorant and just winging it. Fixing that would make life better for everyone.
- Tarucho 5y ago
  >Author here, I don't actually know Why are you writing authoritatively about something you know you don´t actually know then?
  - s_fischer 5y ago
    My take away was that the author doesn't necessarily claim to have all the answers here. It's more of a list of general guidance that is reverse engineered from the type of behavior the she observed was definitely unsuccessful.
  - emma-w 5y ago
    Because traditional authoritative sources that I would look to for guidance are completely out of date. From where I sit it looks to me like they are more focused on milking endowments than discovering what is happening in the real world.

nine_zeros 5y ago

3 tips to managers who are confused about what their own job is - Enable and empower your engineers - Be an unblocker. Do not judge engineers reaching out to you. Just unblock. - Promote your engineers aggressively. Market their work around the company. Let them feel like their work is important enough for you to take time to market around. Give them actual promotions when it's due Don't do the following - Stealing credit - Pushing people issues back onto your engineers just because you are scared if talking to others - Impede their work by micromanaging their execution (stop blocking PRs on bullshit nits, stop blocking docs on formatting. None of this is consequential to the actual project) - Do not bullshit and lie about promotions - Do not insert yourself into every step. Let engineers take charge and also suffer the consequences of their decisions - Practice what you preach. If you ask everyone on the team to write a doc for their projects, you need to do it for your own. If not, your hypocrisy is visible easily and you will lose respect. Lastly, remove the boss attitude. You are working with people who are perhaps more skilled than you. Work with mutual respect, not with supervisory dictatorship.

emma-w 5y ago
This.
mic47 5y ago
Couldn't agree more.

xyzzy21 5y ago

Sad. Because that's what "management" is: action by authority of position in the org chart. That's 100% NOT what leadership is. Leadership is action by people voluntary following the leader. It's a profound difference!

P_I_Staker 5y ago
This isn't really understood by many of the people that push "leadership". At a certain point you also have the problem where the type of people that want management jobs, are the kind of people that want power. Leadership can really suck. It often means more work, stress, and people disliking you. I was talking to a college friend that's a CTO and was taking calls as his baby was being delivered. He could probably have most of the same stuff as a standard developer and live very comfortably. There's something up with someone that really wants to take that tradeoff. I'm not judging or manager bashing either. I'm sure if any of you read this you're one of the ones in it for the great things you can accomplish, and to build an excellent team that's totally safe and healthy!
drewcoo 5y ago
But "servant management" raises too many ugly questions. Is that really managing the servants or serving management?

rramadass 5y ago

Why do people insist on not facing Reality? Management/Leadership IS about Power/Conflict/Negotiation/Human Behaviour/Goals. It is the process which is used to achieve these objectives i.e. whether by Diktat (conventional organizational management) or by Cooperation/Empathy (not easy at all) that varies. Some selected resources: * Speech by Dave Packard to HP Managers - https://gizmodo.com/the-hp-way-how-bill-hewlett-and-i-built-our-company-5634378 https://gizmodo.com/the-hp-way-how-bill-hewlett-and-i-built-... * Management: A Political Activity by Ted Stephenson. * Managing with Power by Jeffrey Pfeffer. * Leadership BS: Fixing Workplaces and Careers One Truth at a Time by Jeffrey Pfeffer. * Power: Why Some People Have It―and Others Don't by Jeffrey Pfeffer.

marcus_holmes 5y ago
This, I think, is the crux of the problem. A manager, traditionally, has the power. They can hire and fire, and have the organisation's power structure behind them. But in a software team, the devs have the power and they know it. There is literally nothing a manager can do to make the project go faster or be successful if the devs don't co-operate. And often the manager has no visibility into the process and don't understand what's going on or why. For a lot of (bad) managers this makes them very insecure, and they react badly. It also puts them in a very difficult situation. For example: if the rest of the management team agree on a deadline that they would like the devs to meet, the dev manager is put in the awkward position of having to ask the devs if they can meet it, and then carrying the answer back to the management team, and generally being a go-between rather than in control. The temptation is clearly to agree to the deadline and then impose it on the dev team. It becomes a conflict situation where the dev manager has to pick a side and either fight the dev team or fight the rest of the organisation. Avoiding this is tricky. Managing without power can be difficult.
- discreteevent 5y ago
  > It becomes a conflict situation where the dev manager has to pick a side and either fight the dev team or fight the rest of the organisation. I think that describes a weak dev manager because they immediately got caught in the trap of playing a fictional estimation game instead of trying to deal with reality. A strong dev manager will communicate the risk to the rest of the managment team. Then they will make decisions based on risk and reward and educate the rest of the managment team about that. If the rest of the managment team wants to pretend that risk doesn't exist and that they want to be shielded from reality then they in turn are weak and there is not much you can do about it. (other fields are similar, e.g. the military).

dasil003 5y ago

After straddling the line of IC to EM to CTO in orgs from 1 to 25k employees over the past 20 years, I have to say the truth of engineering management failure is so much more nuanced and subtle than what is portrayed here. Yes, there are plenty of power-hungry blow-hards and clueless pointy hairs without a lick of talent, but I honestly believe the majority of managers are trying to do a good job, but ultimately it's a really really hard job and the failure modes are extremely diverse. As an IC you might not have visibility to even properly judge the situation. There are questions of strategy, communication, priorities, performance management, micro-managing, giving someone more than they can handle, technical debt vs velocity, quality balance on critical code vs leaf-node code, individual strengths and weaknesses, bus factors, overall morale, cross-functional differences, strategic priorities, cost centers vs profit centers, business landscape, difficult but talented people, easy-going but over-committing people, capable but unmotivated people, etc. To paraphrase Tolstoy: all happy teams are alike, but every unhappy team is unhappy in its own way.

vieux_vague 5y ago
The dizzying list of competing priorities is a great way of showing how much a manager must juggle. I'm not a manager but an IC leading projects at a FAANG company. The engineers are very competent and my responsibilities are a fraction of a manager's and yet I really struggle with many of the things in your list. For example, the capable but somehow-unable-make-solid-progress engineer who's been in this mode for 2 years and nothing I (or others) have tried has got them out of this. My current manager is great and also very transparent about everything they do; this has given me new-found respect for a difficult and thankless role.
- darkwater 5y ago
  > I'm not a manager but an IC leading projects at a FAANG company. The engineers are very competent and my responsibilities are a fraction of a manager's and yet I really struggle with many of the things in your list. Out of curiosity, what are the tasks you are supposed to do in your position and how different are from a manager's or a - let's say - project manager's? Thanks!

jordanbeiber 5y ago

As a leader of 25 young’ish software developers I’ve come to realize that the lack of history is both a blessing and a curse. > If I’m a leader that is serving a team of people doing manufacturing work, there are scientifically proven processes and techniques that can be readily trained and applied. And someone who learns those manufacturing management techniques can reliably boost team productivity. The same cannot be said for software leaders Leadership is one thing, process of work something else. Using techniques from manufacturing is one of the most effective ways of improving output and quality of a software team. The Lean principles matches up quite quite well with the work of producing software. This, however, does not in any way imply that you should treat devs (or people in general) like machines. Work process is incredibly important to create a professional and able organization - leading people here without infringing on their motivation, continuous learning and control is what management is about (to me at least). Many of my young devs have not lived through the 90s and 00 with it’s projects and outsourcing/off-shoring strategies. They’ve landed in the aftermath of an agile revolution turned a beast in it self. They’ve seen nothing else and are forced to accept it. My job is to have them level up and pick the cherries out of the mess we’re in. Have them make it theirs - have them own the process. Agile, in my mind, is about professionalism, ownership and accountability on behalf of the devs. Give them the freedom to claim the above and an insane output can be achieved while having fun. Simple but clear process should surround this work, but the ”why” have to be internalized by the team.

marcus_holmes 5y ago

Software developer with an MBA here. MBA courses do in fact teach servant leadership style (which is what the article is advocating). As a software dev manager, I found the MBA to be useful for three reasons: 1. I could understand the rest of the management team better, and learned the appropriate technical terms to talk to them about the problems they faced. As always, it's easier to reduce conflict if you understand the other participant's problems and objectives. 2. The people-management and leadership training was actually useful, and has been useful since when dealing with some tough people problems. 3. There is, to some extent, a dismissive "you're just a code monkey" attitude amongst some managers. Having an MBA does help with dealing with that. It's difficult to dismiss me as just the nerd who pushes the nerd-buttons when I'm more qualified than them in their own area. I'm not sure I'd recommend that all software dev leads go and get an MBA - it's definitely overkill. But on the other hand, dismissing the entire corpus of management learning as irrelevant because software dev is special is also overkill. There are things to learn from traditional management courses. Devs are still people, after all, and managing them as people is still the same. I do think that a dev manager should be able to code, and preferably have worked as a commercial developer at some point in their past. It does help with understanding the situation and the problems. And it's almost impossible to get any respect from the team if you can't talk the talk and haven't walked the walk. I have experienced the bad management that the author talks about, and seen it in action. But I don't think this is unique to development - there is a lot of bad management around in all industries. The answer to this is more management training, not less ;) Getting dev managers onto management courses is still going to be a net good because they'll be better managers, even if they still don't understand why they can't get accurate estimates for anything. If the author goes on to manage a team for a few years, I'd be interested to read their take on it then. The view is very different from the other side.

flashgordon 5y ago

I am slightly worried about all these manager related articles use the term "manager" in a negative light but "leader" in a positive light. Are there no bad leaders (umm I am pretty sure Hitler wouldn't be labelled a manager)? Wouldnt the title "Bad engineering leaders think..." Or even "Bad leaders think ..." Be just as apt? There are ineffective and toxic behaviors everywhere and just labelling a class of jobs seems scary. By the way I have gone between IC and management (even managing managers) and the "badness" I've witnessed (and sadly also partaken in) was never localized!