Speaking from experience. Talk to your superior about the issue. If they are the issue (my case) or if the issue is not addressed as you see fit then leave the company. This is not an extremity. There are plenty of companies looking for good devs- even remote. You will be happier and perform better. Let the swamp be the swamp - not your job to fix it.
How to deal with difficult people on software projects
31–40 of 130 posts
Re: How to deal with difficult people on software projects
#32I got stuck on the first one "Product Manager". Do the newer companies have this role? I mean, for the companies that are consumer facing and not enterprise oriented. IMO, this is a spillover role from the enterprise heavy 90s/2000s into today. Am I wrong?
I spent about a decade as a PM at startups, so I can definitely attest they do. Obviously I'm biased here, but the PM role isn't just some spillover, it's work that needs to be done. Someone has to talk to stakeholders, gather and document requirements, work with customer-facing teams on launches/preparation/etc. and so forth. If the product manager isn't doing it, then engineers are doing it, which means they aren't…
From my experience PMs serve one true purpose well. That’s reporting to the higher ups (execs building a moat) and being a single point of contact for the devs. Everything else is red tape. Gathering requirements is hard and a PM digesting it first is never optimal.
Re: How to deal with difficult people on software projects
#33I hovered over each item under the appropriate category, and I clicked the one that best described me. The description was 100% accurate, and outlined my flaws perfectly. Now I know what I need to do, thanks.
Re: How to deal with difficult people on software projects
#34How do I go about using this without knowing which label I fall under? I would assume that to know how to work with X I need to know how my strengths and weaknesses as Y relate to them—otherwise this is just another way to see the world as 'me vs them'
I think they're more patterns we're all susceptible to
Would be much better if the website stated it explicitly. The current description is rather unfortunate.
Re: How to deal with difficult people on software projects
#35Throwaway as I don’t want to admit I am one of these negative ones (soldier) with my main.
The negative reaction to this seems like ego. “I’m special, unique, and complex so you can’t profile me this way.”
The thing is, people aren’t. Social media companies have demonstrated that most people can be broken down into categories and targeted in very specific and effective ways.
And yes, as the article says, try as people might, if you work with me, you will never learn why I am that way.
Re: How to deal with difficult people on software projects
#36How do I go about using this without knowing which label I fall under? I would assume that to know how to work with X I need to know how my strengths and weaknesses as Y relate to them—otherwise this is just another way to see the world as 'me vs them'
Take a look at the The Problem header. There is usually a list under there discussing the actions/motivations they take.
I have found myself in a few of them.
Re: How to deal with difficult people on software projects
#37This 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…
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 wh…
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.
Re: How to deal with difficult people on software projects
#38What a toxic little website. Do not follow the advise here. Do not label your co-workers. Trust them, listen to them. If you see them exhibit traits you perceive as negative (and fall into these crude buckets) - talk to them, and give them feedback. Chances are, they will appreciate it, and your working relationship will improve.
Re: How to deal with difficult people on software projects
#39Fire them
Re: How to deal with difficult people on software projects
#40This 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…
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.