Engineer Alice is the only person incompetent at their job in this conversation. If "irrepressibly existential sigh" is how you argue security with your bosses then maybe you're not senior enough to be in meetings like these.
The Manager and QA Engineers here depend on the expertise of the engineers. If the engineers fail to communicate key details of the situation, then that's on them. Sure, the boss is still at fault for depending on a shitty engineer for decision making, but that's all.
There are plenty of poor engineers, but this “fix” has to go through a process defined and enforced by managers. In a good process, multiple engineers would review the code, and if the office culture is good, then objections will be brought up and listened to, and if a fix is insufficient, management will understand and assign resources to make it right. None of those things depend on any one engineer or manager. They’re a culture issue. But the only people with the power to fix a broken culture is management. Engineer Alice doesn’t have that power herself.
If its more than one engineer I would say there is a very real chance that the issue is the manager.
Sometimes things need to be more complex than they first appear. Think all that pesky error checking that you totally don't need as long as everything is working perfectly for an extreme case.
If the engineers are experienced think strongly about letting the do the work as long as they are ones who will also take the pain of the complexity. Also having them explain why something is needed to the rest of the team is a good way to have everyone on board with a decision and it helps bring the rest of the team up to speed.
> Are there significant issues with the management or other devs? This really should be a time where you bring up the issues you're having, and options for others to help you.
Any issues with the management an engineer brings up are issues readily solved with a pink slip for the engineer. "Reading the room" is essential -- understanding the company culture -- before you speak. And even then, you might be wrong.
The lack of empathy in the comments here is worrisome. The manager was clearly failing to manage effectively. Blaming the engineer for not managing up with a manager who didn’t want to listen doesn’t make sense.
This scenario is my biggest fear as a people leader - that ICs are being mismanaged and I won’t be able to see it or intervene before it is too late.
I think online software development discussions tend to lean slightly towards blaming management rather than engineers, probably because we're most of us engineers and can empathize with them better, but in this case I think it's reasonable to blame the engineer. A manager's job isn't to micro-manage every single task and to make sure that an engineer is highly engaged at every hour of the day. If the engineer is blocked on everything, above a certain level of seniority which is not so high, it's incumbent on them to find ways to contribute or find things to do, and if need be convey their situation to their manager.
You're one of those micro-managers that wants to keep metrics on all engineers. You presume all engineers are fucking the company until you witness them giving their all for the 'team.' You want a bunch of robot cogs that do exactly what you say, when you say.
Your whole outlook is 'someone is screwing around, we need more or better managers, preferably one that's been an engineer so he/she can more easily root these people out.'
> If you have critical risks that only engineers can understand, then you have extremely poor engineering leadership.
Or extremely incompetent PMs. I've had one PM be confronted with the documentation of something where it clearly said "don't do this, it's wrong and will ruin everything" (which, totally by coincidence, is what he was told by someone on the team before). He still demanded it to be done because he had heard a talk at some conference where that was recommended. It took getting the CEO into the issue via back channels to clear that out.
Imho the percentage of PMs, POs etc that have no clue what they are doing is much, much higher than in any technical role. If they're good at bullshitting, they can usually talk their way out of being blamed for their failure and switch to a different company later.
I don't disagree with you, but I don't think the responsibility lies primarily with the engineer. Especially in large orgs, you have armies of people whose job is ostensibly to understand the needs of the people their team serves, yet they continually fail to do so.
Management aren’t trained engineers. They shouldn’t have to be. We’re the experts in the room. That’s literally what we’re hired for. We should act like it and stop trying to pass blame to other people.
> It’s also indicative of poor process, communication and documentation.
I recall one engineer in a team of 20 or so that, whenever he ran into a problem, he'd stop, fold his hands, and sit back in his chair. And wait until the manager noticed this, would come by, ask what the problem was, fix it for him, and he'd then proceed.
You could say this was all the manager's fault, but the rest of the team did not behave this way.
Another time, I recall one who needed micromanaging. Eventually it turned out he was on drugs.
It's basically what happens when technically incompetent and inexperienced people wear management hats. If I was running a firm, the engineers would dictate to management, not the other way around.
Yeah I'm used to in-house, no material contract experience.
> the dysfunction is everyone else's fault, not our own
I specifically said the relationship. It takes two parties for effective communication to occur. An engineer who have given up trying because they assume experienced management will not listen, is just as bad as a manager that steamrolls their experienced engineers.
You seem to be bringing in piles of other things here: technical debt, complexity, cruft, etc. My post is about none of those things. You also note that the prevalence of those things is because no one will listen to engineers “with some deep skills & knowledge”. At some point, you also have to assign some responsibility for failure to communicate effectively, and not just a failure to listen. Or maybe they are not listening also, and not understanding the full context? I’m not doubting that poor decisions happen, but I’m not sure it’s useful to assign unilateral blame to management based on a failure to listen to the engineers you’ve deemed special here.
> I realize the sticking point is “voice my concerns”
But in an interaction between an engineer and a manager, anything less than voicing your concerns is an abdication of responsibility. If the manager switches off at the first expression of concern from an engineer, then I imagine that's a team that's bound to failure.
The Manager and QA Engineers here depend on the expertise of the engineers. If the engineers fail to communicate key details of the situation, then that's on them. Sure, the boss is still at fault for depending on a shitty engineer for decision making, but that's all.
reply