I am doing so because I am in progress of validating an idea which should result in a course which is to educate engineering managers and leaders towards what I have come to terms with is a a field-experience based approach (fred brooks comes to mind) and what I call common knowledge for what my own expectations are from engineering managers.
What would you teach your manager about managing software developers and teams ?
Lack of vision and lack of decisiveness. A "we'll cross that bridge when we get there" attitude for everything. No clue about the tech stack and no direction causes the programmers to, for lack of a better word, start working randomly, and it's no surprise the code will look like an ant colony. Bad design decisions go undetected, and when someone does bring them up, management has no clue what to do about it. In fact it is really too late by then.
There's a guy who is on the spectrum. Terrible communicator. But understands pretty much everything about our code.
There's a guy who doesn't understand shit, doesn't know software engineering terms, and feels the need to redo everything his way (so that he understands. He admitted so when I called him out).
There's a guy who gets shit done, but there's always a couple of issues with it that reveal themselves later that have to be iterated on, back and forth.
There's me, I need some central directives and direction. Right now the rewrite-guy is always breathing down my neck and second guessing the way I have my microservice set up, despite not understanding the external API problems I have to design around.
Would love a manager/tech lead that could actually just do something useful with this situation rather than faff about. The tech lead is present for all of this, and sees all of it happen, but never really interjects or involves himself. There's never resolution, unless you really push him for it.
When I compare software corporate leadership versus military leadership this is the thing that sticks out the most. In corporate software (at least in web dev) everyone is treated like a small child who needs their hands held and must be protected from themselves by a parent who pretends to care about their output. That is stupid.
Look, the only purpose of software is automation. If you want to impose a bunch of safety and sanity checks stop the bike shedding insanity and instead automate the shit out of it. As someone who has written a test automation application for the browser it isn’t hard, and yet it’s treated as a separate speciality.
When people are allowed to fail they are empowered to succeed.
This transition frequently leads to unrealistic demands regarding project timelines and deliveries. There's a prevalent lack of faith in engineers among these managers, primarily because they struggle to grasp the intricacies of the work engineers do.
I really would appreciate a nice bagel with smoked salmon and hot honey.
Then a nice craft Cola.