Short sighted decision making that doesn't account for the larger ecosystem. Sloppy code that barely meets the requirements. Zero coordination on a release that clearly left another team scrambling because it placed significant load on their service/ introduced a disruptive user story/ broke or delayed another team's clearly announced pending release.
The list goes on, but the bottom line is that many folks will be happy to optimize for their personal "local minima" but literally harm the organization in the process.
"local minima" is entirely a function of what processes and requirements are in place for code to be accepted. In a well designed engineering org, the "local minima" and "optimal" are indistinguishable from each other, because you only let through fully tested code that passes the hopefully many CI steps you have and has also been subjected to extensive code review, QA, etc.
If the reviewers and QA folks are doing their job, nothing like what you're describing should get through, and true "problem" engineers are simply those who are never able to get something through.
When this falls apart it is invariably leadership's fault for writing bad tickets or not implementing proper CI, quality control, or testing practices, or not allocating sufficient time and resources to the code review process.
And this stuff is only becoming more important as we integrate LLMs into our workflows...
All of that said, engineers are not static -- everyone is learning and changing all the time, so "problem" engineers after you've eliminated the above are simply people who have a ways to go before they change enough to become effective in your org (or, quite possibly, your org and its processes have a ways to go before more than an extremely specific type of engineer can become effective). Then it's just a value-prop of "do we think it's worth it to wait it out for this particular employee" because they're always learning and leveling up.
Other problems, like dishonesty, not doing enough work, not appearing to level up, honestly all come back to comp/benefits/company-culture. I genuinely believe that a good manager with sufficient resources can get good engineering work out of literally anyone, given sufficient time and (possibly quite high) resources.
And sometimes, the employees that require the highest investment in that regard can have a very high return when they finally do level up. In fact, I find that a really good predictor of success is simply ambition to level up. I care about that much more than I care about raw skill at the time of hiring.
Of course what you are saying is true but there is more nuance here. The fact is that regardless of architecture, requirments and test cases the engineer is going to make lots of small decisions, and if they are not motivated to make good decisions for the benefit of the org then there will be consequences that maybe could be mitigated but will still impose significant costs. So the fact remains that these engineers need to exit the org.
Every time I read a variation of the "for the benefit of the org" phrase I cannot help but laugh at the absurdity of it.
Do I own the org? If I produce 5x more, do I get rewarded 5x more? What about the other way around: will the org work "for my benefit" every step of the way?
Folks, most people work where they work because they have to. You work or you starve, that's the deal society gives us.
So many clueless managers buy into this crap and go on to become horrible managers "for the benefit of the org".
This phrase is completely nonsensical because it implies that the employee, that has no real stake in the company (no, stock options don't count), should be altruistic and work in the benefit of the organization above his own interests. I say above his own interests because if the interests of the organization and the individual's were aligned, this would be a non-issue.
The reality is that the absolute majority of organizations don't want to fix their incentives because it's cheaper and easier to label people "difficult employees" and fire them. After all, we're all replaceable.
Anecdotal but I've never come across someone that was actively trying to harm their employers. Even the ones labelled "difficult". It was always about bad incentives from the organization.
That's a big mischaracterization of what I wrote. No, it's not a binary choice between professional or not professional. This kind of simplification is exactly the type of harm the original article reinforces.
If you wanna tout around "professionalism", at least explain to all of us what that entails in your world view. Because, for me, someone that does what they're paid to do is professional with or without a blind sense of loyalty to "the organization".
This is also why I believe after many many failed iterations and variations of capitalism, we will arrive at worker-owned co-ops winning in the end. It is the only way to truly align interests while still working within this ridiculous capitalist framework.
The fun part is the union leader becomes the CEO, gets elected, etc.
> The list goes on, but the bottom line is that many folks will be happy to optimize for their personal "local minima" but literally harm the organization in the process.
Yes, because doing exactly what you're supposed to, exactly how its asked, and then clocking out "harms" the organization. No one has passion for your CRUD app for dogs. Everyone wants to make money, go home, and live their lives.
Maybe the managers should write better specs that capture the company vision instead of this dysfunctional bullshit we call agile. Agile creates the drive to the local minima. I don't care about anything happening outside my bubble and have been gainfully employed for decades now. In fact, everything you said can be solved by BETTER MANAGEMENT:
> Sloppy code that barely meets the requirements.
Not the developer's problem. Give me 2 sprint points and shitty specs you get what you wrote. I'm a squeaky wheel. In every company I've worked at I learn to shut up because asking for sprint points to double to in order to insure good, clean, testable code (not "perfect code") is looked at with ire because, allegedly, developers are just people who want "perfect everything" and without "proper management" they will end up rewriting the entire operating system every ticket. The result is garbage in garbage out. Give me a day to finish a ticket with tests and you're going to get a rock bottom solution designed to fit the exact use case, no more, no less. No matter how many "I told you so's" I give I've never been able to get a manager to understand why the alarms going off are related to their shitty decisions months prior.
> Zero coordination on a release that clearly left another team scrambling because it placed significant load on their service/ introduced a disruptive user story/ broke or delayed another team's clearly announced pending release
Sounds like the management should be coordinating releases between teams because they have a broader perspective on the ecosystem. You know, MANAGING the systems.
Your entire post reeks of the entitlement of an all-smiles CEO that uses the word "family" as a comma.
Yes these things happen, but in my experience it's about incentives set by the environment.
When short term gains outweigh long term gains, short sighted decisions will be favored.
When nobody really cares about quality, people ship sloppy code. See the broken window parable.
When rewards are given for shipping fast and not thinking about the whole picture, teams will ship without caring about other teams.
I acknowledge there are outliers that really do not give a f***, but those are rare. Personally I have yet to find a real "difficult engineer" in all my 15+ years in software. What I have found were dysfunctional organizations and managers that set the wrong incentives then fail to comprehend the ramifications.
The list goes on, but the bottom line is that many folks will be happy to optimize for their personal "local minima" but literally harm the organization in the process.