Hacker News Reader

Comment by stevecalifornia | Hacker News Reader

This is a horrible website and you will likely experience diminished tenure if you follow it's advice.

First, there is a complete lack of empathy for the person being labelled. What are the motivations and constraints that led to this person acting this way? A key question and the foundation for building healthy productive relationships.

Second, the 'solutions' are horrible. "Go around the person" is terrible advice for anyone on a team. If you follow the advice from this website you will end up being the problem.

I would argue that this website is almost sociopathic-- completely ignoring the perspectives of anyone but the reader and suggesting damaging solutions and labels.

View on HN

Go around is a valid strategy, eventually your entire team will go around the difficult person and the difficult person will no longer be part of the solution chain essentially relegated to obscurity. Works in big teams with sufficient overlap not in small ones

Soft agree. Going around people isn't always as borderline-sociopathic as people in this thread make it out to be. For example, the given solution for handling the process-obsessed is surprisingly non-toxic: encourage them to favor incremental change to give them the time to learn and grow their strats enough to come up with something that's tailored to the team.

I literally don't know how else to deal with certain categories of folks with whom talking and trying to resolve the issue has no effect.

Going around them/ignoring them is literally the advice you get from basically every literature I've read, and I've read a lot about this.

But you do have to try to work through the issue first, and you have to be willing to try again if they seem open to resolving the problem down the line. Never write someone off completely (for professional disagreements).

What would you suggest from your readings?

I've mostly benefited from hard realism approach and Actor theory (as applied by some: everyone has an agenda, to work with them: Align, make Peace, or Destroy).

This seems to be working best for me so far.

It's actually a bit of a gap -- everything I've read tries very hard to assume positive intent; people will cooperate if you can create a sense within them that they can express themselves without fear of reprisal or judgement.

The reasoning in the literature for avoiding this topic is sound. If you provide the "destroy" option to folks, they're usually going to go with that pretty quickly, and only nominally go for the other methods of resolving conflict.

I've had someone make that determination about me at a previous role, which then put me obviously in a "what do I do with this person?" position which itself led me to the "ignore/destroy" answer. If it hadn't been an option, would this person and I have had a more pleasant working environment?

I've been collecting on that gap in personal interviews, I have observed it as well. CMS (Critical Management Theory ) had some tidbits that I found useful, since they criticize mainstream management and describe some of the tactics avoided by mainstream research.

I had a “hostage taker” running devops and CI on a project last year that I had warned the product owner about multiple times.

This person would not respond to basic developer experience problems and could not get a release out the door without some manner of basic code merging problems.

Repeated direct and polite feedback would not move them an inch. It was like they knew they didn’t have to change and could keep their job.

The manager should have been able to identify this and handle it but they were distracted and not able to do it.

Eventually this hostage taker‘a failure to execute and complete sandbagging of any attempt to wrest control over deployments endangered a major new enterprise sale.

We went around this person, rebuilt what they had been responsible for and got back to work completing the product.

They were sidelined and let go eventually and the project is way better for it.

Fully agreed.

Amusingly, every single archetype in the "manager" section of this site contains advice which runs exactly counter to the advice from the also highly-upvoted "Common Mistakes of New Engineering Managers" article currently on the HN home page.

This just goes to show the extent to which our industry is still very "unsolved" and contains a multitude of often completely-opposed opinions - which means that reducing these opinions and the people who hold them to labels and suggesting they be "solved" is patently ridiculous.

Management has been around since ancient times in various forms. There are things that kinda work, but the game keeps changing as the interests and balances of power shift in the workplace. Why would it ever be "solved"?

It wouldn't! - which is pretty much the point I was trying to make about generalization and stereotypes, although I do think there are fewer "generally accepted best practices" in this industry than in most.

But that’s just because managing software development is about managing people, and the behavior of people can’t be captured by logical rules. In other words, I doubt that there is something that can or even should be solved here.

I think this quote says it best: “The test of a first-rate intelligence is the ability to hold two opposed ideas in mind at the same time and still retain the ability to function.”

I feel like between this and the sibling comment my point was misunderstood - to clarify, I wasn't trying to say "our industry is unsolved but should be solved," rather, "there is no 'solve' for these sorts of things which aren't even 'problems' so much as difference of opinion, even outside of the technology industry, and within the technology industry there is an even greater breadth of opinion around product and project scheduling and management" - so, the linked article is triply ridiculous.

Seriously - the "Patent Author" PM may well have come to be that ways because if he doesn't, the engineering team just makes assumptions (that are wrong) and build the wrong thing, instead of checking with the PM. When I've worked with dev teams in India (with me in CA), I have written extremely detailed and specific product specs, because I'm asleep while they're working, so if something is unclear it can waste a whole day of a dev's time.

The article on Patent Author does mention as one of the exceptions exaclty that - working with teams on different time zones may require a Patent Author attitude. However, I do have to agree with the original comment in this chain, that website is filled with bad advice and slightly sociopathic in nature.

I think there's a kernel of usefulness here, as long as you keep in mind that the labels don't inhere in the person, but rather refer to behavior and are relative to their current role. Developers love to systematize so it's easy to forget that people don't really fall into neatly labelled categories like this.

A "downtrodden" QA person could become uptrodden on a different team. Having a "patent author" PM is probably a good thing if you're working on life-critical software. Even an "incompetent" developer can learn to become better, or might be better suited to some other project. I'm decent at embedded development but if you put me on a deep learning task I'd be incompetent initially.

> This is a horrible website and you will likely experience diminished tenure if you follow it's advice.

I'm pretty sure it's supposed to be at least somewhat humorous/tongue in cheek. I can certainly recognise the tropes both in myself and in others.

It's just kind of fun, and I'm certainly not planning to take any of its advice that seriously.

I'm baffled that some people might think this is serious. I found it hilarious.

Indeed, and there are loads of them on this subthread. I'm dating myself here but it just goes to show that, absent body-language, voice tone, and other contextual cues, humour still sometimes doesn't communicate well on the web.

> This is a horrible website and you will likely experience diminished tenure if you follow it's advice.

Only if you take this seriously. It's no less toxic than a Dilbert strip. You are also doomed if you try to follow Dilbert.

I can not say it's a true piece of art, but looking at the engineering row, I have met every single cliché in this list and the description are perfect.

Each individuals are unique, so the "solutions" part is foolish, only a bad manager would follow them blindly but I would definitely say that the labelling is on point

Agreed - maybe there is a grain of validity in many of these stereotypes, but it's riddled with misinformation such as:

> Typically – especially on large development teams – low quality is caused by individual developers rather than the team as a whole.

Maybe that's true at whatever firm they work at, but in my experience it's failure of leadership to implement process where it's needed.

I've been viewing it in a comedic light because it feels like a joke, and it is quite funny.

Go around might be the only option available to you if you don’t want to quit your job. I have been lucky enough to experience only a few difficult co-workers in my career but a few of them were toxic beyond belief. And not even “rationally toxic” as in doing it to further their own interests (they would regularly sabotage themselves on top of sabotaging everybody else).

The only one that kind of bothered me was "The Legacy Maintainer" which argues that your legacy maintainers _want_ to be stuck on a legacy project with their career in ruins. In my experience, nobody wants that, but neither can they do anything about it. Then again, the world already looks down on LM's as effectively an "untouchable" caste, so any excuse will do.

If that's the only one that bothered you, you may want to consider why that is.

It's something you have experience with, and therefore feel empathy for. Is it likely that you just happened to have experience with the one "role" that's worth being empathetic towards?

I've worked with tons people who have built their careers around a particular piece of technology, get comfortable in that role, and never leave.

Can't agree more. Everything from the framing of the problems, to the solutions, to the model of how things work (and how they ought to be fixed) go directly against anything that has ever worked in my experience.

> If you follow the advice from this website you will end up being the problem.

If you meet an asshole in the morning, you met an asshole. If you meet assholes all day long, you’re the asshole.

I sense that you may fall into one of these categories and you don't like that...

You sound like the The Peacemaker.

You should try and see how websites like this facilitate technological excellence even though they make you uncomfortable.

What? The peacemaker wants to avoid arguments. Going around someone avoids arguments. The peacemaker would follow the advice on the site and go around someone. This person, on the other hand, is saying thats bad, and that a more confrontational (but less passive aggressive) approach is likely better.

That's both more mature and more likely to lead to technical excellence.

Reply on news.ycombinator.com