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.
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.
> 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!
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 :)
> 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
> 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.)
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.
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.
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.
It is impossible. Whether the Power (in the most general sense of the term) is overt or covert is a function of circumstances and the nature of the people being managed.
The way i look at it is as consisting of three distinct axes;
* People - Their Nature, Wants, Psychology and Behaviour. This is what everybody should focus on majorly since this is the most variable, malleable, amorphous and difficult to learn and master. An analogy i use (and which often raises people's ire) is how we train other species to get them to do what we want; eg. Lions/Tigers in a Circus vs. Sheep herding Dogs vs. Teaching a parrot to Talk etc. You get the idea. There are some fundamental principles but they all have to be tailored for each species and the individual within a species. We are the same except that our social/communication structures are vastly more complex.
* Resources - Materials and Time. You are given a finite amount of these with which you have to do the best you can.
The big problem here is Time due to our equating it with Money and the self-imposed breakneck speed towards everything.
* Domain Knowledge - This is a must and especially relevant to Software Development domain because of the breadth and complexity of the subjects involved. The author of the article seems to conflate this with the whole of "Management".
All the above three will have to be "Managed" for a successful outcome but the emphasis on each will vary according to Circumstances and Issues involved.
> 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).
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.
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.
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!
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.
Readit News
To paraphrase Tolstoy: all happy teams are alike, but every unhappy team is unhappy in its own way.
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.
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!
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 :)
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
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 :)
Your peers have burned through all the believability of this line, by using it when it is a lie.
- 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.
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-...
* 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.
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.
It is impossible. Whether the Power (in the most general sense of the term) is overt or covert is a function of circumstances and the nature of the people being managed.
The way i look at it is as consisting of three distinct axes;
* People - Their Nature, Wants, Psychology and Behaviour. This is what everybody should focus on majorly since this is the most variable, malleable, amorphous and difficult to learn and master. An analogy i use (and which often raises people's ire) is how we train other species to get them to do what we want; eg. Lions/Tigers in a Circus vs. Sheep herding Dogs vs. Teaching a parrot to Talk etc. You get the idea. There are some fundamental principles but they all have to be tailored for each species and the individual within a species. We are the same except that our social/communication structures are vastly more complex.
* Resources - Materials and Time. You are given a finite amount of these with which you have to do the best you can. The big problem here is Time due to our equating it with Money and the self-imposed breakneck speed towards everything.
* Domain Knowledge - This is a must and especially relevant to Software Development domain because of the breadth and complexity of the subjects involved. The author of the article seems to conflate this with the whole of "Management".
All the above three will have to be "Managed" for a successful outcome but the emphasis on each will vary according to Circumstances and Issues involved.
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).
>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.
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.
Why are you writing authoritatively about something you know you don´t actually know then?
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.
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!
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!
> 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.