This often is a real issue. When there's a technical problem that is too sensitive/complicated/important to handle carelessly, assholes kick in in the middle, oversimplify the problem, ignore possible critical issues, and push plans without plan B. They offer what they can do right now as the best solution, and often don't even check the documentation nor the community best practice.
What's worse, assholes normally don't care to document the decision and its context. This helps them feel important because people should ask these assholes for the context. Also, this increases the chance of getting positive reviews during peer review, because they did help someone anyway. There's this positive cycle that makes them keep being asshole.
Until someone comes and directly inspect the situation, no assessment process from the management can ever detect this behavior. Assholes are hiding in the plain-sight, and behavior themselves in the presence of management. They look safe and sound technical, just enough.
If you're a manager, be advised. If you see an asshole out in the field, it's likely the guy isn't the asshole - the one's just stupid, so is safe, since everyone can clearly recognize the guy is a stupid-ass. You can tame guys like that.
On the contrary, assholes often are praised as good and even performant. However, in reality, they actively ruin normal decision process and technical communication in general. This alone discourages a lot of engineers, but they also tend to create lots of tech debts, as they already ruined the communication that could have prevented debts from the beginning.
So, one possible way to detect an asshole in the organization is to tracking the source of all tech-debts - how they are introduced, who did that, why they did so. You'll have to talk to engineers directly, because assholes only "talk" to distort decisions.
Another way is to (ab)using interns as litmus paper. Just interview everyone of them at the end of their work term. They do tell you the truth, as most of them will never see you again (or they believe so).
Yup. Though sussing out these guys is very difficult, as they also often seem to actively weed out anyone who challenges the petty tyrant or even other assholes moving in on their turf. So their teams become loyal to the asshole's little fiefdom. I spent my entire exit interview at my last company just blasting this one guy, in a vain attempt to get the company to recognize he was cancer.
This is the one that I see so often and wish my managers' would recognize faster. Nobody picks up the ticket in the queue that actually needs to get done, but when hackathon comes around somebody's shitty barely working code becomes a huge win for the company instead of recognized for a giant loan of tech debt. Debt that will be paid from the poor schmucks that will actually need to maintain that thing. But hey "I won't be here, you won't be here" is the cornerstone of hockey stick growth.
This often is a real issue. When there's a technical problem that is too sensitive/complicated/important to handle carelessly, assholes kick in in the middle, oversimplify the problem, ignore possible critical issues, and push plans without plan B. They offer what they can do right now as the best solution, and often don't even check the documentation nor the community best practice.
What's worse, assholes normally don't care to document the decision and its context. This helps them feel important because people should ask these assholes for the context. Also, this increases the chance of getting positive reviews during peer review, because they did help someone anyway. There's this positive cycle that makes them keep being asshole.
Until someone comes and directly inspect the situation, no assessment process from the management can ever detect this behavior. Assholes are hiding in the plain-sight, and behavior themselves in the presence of management. They look safe and sound technical, just enough.
If you're a manager, be advised. If you see an asshole out in the field, it's likely the guy isn't the asshole - the one's just stupid, so is safe, since everyone can clearly recognize the guy is a stupid-ass. You can tame guys like that.
On the contrary, assholes often are praised as good and even performant. However, in reality, they actively ruin normal decision process and technical communication in general. This alone discourages a lot of engineers, but they also tend to create lots of tech debts, as they already ruined the communication that could have prevented debts from the beginning.
So, one possible way to detect an asshole in the organization is to tracking the source of all tech-debts - how they are introduced, who did that, why they did so. You'll have to talk to engineers directly, because assholes only "talk" to distort decisions.
Another way is to (ab)using interns as litmus paper. Just interview everyone of them at the end of their work term. They do tell you the truth, as most of them will never see you again (or they believe so).