Bad engineering managers think leadership is about power
ewattwhere.substack.com
ewattwhere.substack.com
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!
As an IC, I lack authority and have to rely more on influence. A good manager relies on influence by default but some things are very hard to achieve without some authority (as distasteful as it may seem).
For me, getting folks to pull in the same direction consistently over a long period of time is hard. Getting folks to appreciate why doing this thing rather than another (because business value) is hard.
And I am well aware that I can and do also make life hard for my manager in exactly the same way! Humans are hard.
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
Your peers have burned through all the believability of this line, by using it when it is a lie.
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 :)
- 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.
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).
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 this is where you're talking about the same thing but using different words. Is the ability to persuade people to do something (without any ability to force them to do it) the same as having "power" over them?
Otoh, Negotiation where both parties give up something to come to an understanding and treat each other as equals is different. Power is still being exercised but with equal emphasis.
>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.
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!