[PragmaticPulp]

I felt similarly as an IC, but my perspective changed as I shifted into management.

I didn’t believe that “negative value” engineers existed when I was working on the front lines alongside other good engineers. In reality, I was seeing the end result of competent management teams who effectively filtered out negative employees in the hiring process or quickly dealt with anyone who became problematic after being hired.

Being a negative value engineer isn’t just about writing bad code or being incompetent. Those things are trivially obvious in any technical interview. The reality is that negative value usually comes from behavioral issues. Engineers who are constantly sowing discord against the company or management can bring down entire teams. Engineers who create conflict and destroy morale are toxic for productivity and will drive away your best team members. Engineers who can’t ever ship anything on time because they can’t manage their own time or they have pathological perfectionist tendencies will sink your schedules. Ironically, negative value can often come from those with great technical chops who are unfortunately mired in personal issues.

Managers can compensate to some degree with intense attention and guidance for those individuals, but at what cost? Obviously managers should make an attempt to correct behavioral problems that are dragging the team down, but at some point you need to do the inevitable and replace the problematic employee with someone who can perform without the behavioral issues.

It’s not just a question of whether or not someone can write good code. It’s a question of whether or not the team and company are best served by keeping a troubled employee as opposed to reallocating that finite headcount to a new candidate.

[kitsune_]

Exactly, to use the framing of "Speed of Trust" by Covey, trust has multiple dimensions, if you only focus on the skills and results dimension you end up with toxic employees with malicious intent or who have a profound lack of integrity and leave a trail of carnage throughout the organization. Whether you need to have a hierarchical managerial system to rectify this is another question, high functioning teams are perfectly capable of making this assessment themselves.

Another underappreciated factor are mental health issues. The chances are high that you will run into people that have undiagnosed ADHD, OCD, Aspergers, autism, bipolar, anti-social disorder in software engineering, or even that you might have a mental health problem yourself without knowing it.

[nucleardog]

I’ve gotten rid of the engineer you describe.

He was technically proficient but lacking in literally every single other ancillary skill for an engineer or a human being.

He could write complex code but it was overengineered and overcomplicated imposing a huge maintenance burden and making it brittle. His whole team was “Wow, he must be so smart!” but when asked on what basis he’d chosen the approach he’d taken instead of the naive solution he got rude and defensive. Nobody else on the team could maintain his code. (It wasn’t bad in isolation, just inappropriate in context.)

Presented with a problem to solve, he would not write something that made sense for the business, designing around requirements that did not match what a reasonable person would assume. When more explicit requirements were included, he complained he was being too restricted.

When presented with a problem to solve, he would not solve it in a way that made sense in the overall technical landscape (I need to serve some absurd number of requests, should I write the most efficient program possible but restrict it to a single instance, or write something less efficient that’s horizontally scalable?).

He was not interested in learning new things. When presented with different technologies, he instead began a solo rewrite of core company systems to ones he was more familiar with because “that’s what I’m more familiar with”. When it was explained that we’d moved away from those systems because of certain problems, he powered ahead with “Yeah, but that’s what I’m more familiar with.” When the foot was finally put down, the answer was “Fine, I’ll use the tech you use but if I have any problems I won’t fix it someone else will have to figure it out.”

He sat idle for weeks because one of our internal company tools was poorly documented that he needed it to do his job (no one thought to document it beyond the inline help because that had been sufficient thus far...). Seeing this tool used daily for two weeks, he did not try it, did not ask his teammates he saw using it, his supervisor, or anyone else for help. He checked the internal wiki and when he failed to find a clear explanation he just... did nothing. Until he got fed up with not knowing what he was doing and scheduled a meeting with the CTO, his supervisor, and ops to walk through every wiki page one-by-one and demonstrate that it was not documented on that page. That meeting was cut very short but probably still easily cost $600.

In every meeting everyone he dealt with walked away with a bad taste because he was rude and interrupted people constantly. He did not bring ideas on technical merit but instead “well I always...”. The biggest thing we emphasize with all our engineers is “data”. Decisions are based on data and documentation, not feelings and opinions. He pushed things through on sheer stubbornness and got upset when he ran up against people that refused to accept that.

His supervisor was not a strong, confident type and within about three days of being hired he’d steamrolled him and started completely overhauling how the team works causing deadlines to be missed as everyone on the team became confused about how to do their job.

And when all of these things were repeatedly discussed with him, explaining what the problem was, why it was a problem, and how we expected an employee to behave... he disagreed there was an issue and carried on as he was.

I did not do the hiring in this case, but I resolved the issue. For that team it was a brief couple week interlude where some guy showed up, wrote some “really smart” code and tried to do some other really smart stuff, then was gone before any of it really got implemented and life went on as usual.

Which is all to say I agree...

Awful engineers don’t have to be technically incompetent, there are a lot more skills involved to being an engineer than just writing code. And if you’re not actively opposed to it, a good manager can smooth over deficiencies in some areas so nobody ever notices.

And if you’ve never worked with an awful engineer, that’s likely a result of a lot of other systems doing their job. If you hired everyone that applied to our company you’d end up with mostly unqualified engineers... and a couple of drywallers. Every improvement past there came from a deliberate action by somebody.

[Viliam1234]

> He was technically proficient

> He was not interested in learning new things.

So, sounds to me like he was only proficient with one specific technology.