How to deal with difficult people on software projects(howtodeal.dev) |
How to deal with difficult people on software projects(howtodeal.dev) |
Now. Where can a 57yo idealist find a job in today's world?
Narcissism is fundamentally about self-interest.
In corporate workplaces, teamwork is simply a temporary treaty imposed by higher level capitalists/narcissists so that you do their bidding, not yours.
If you are working in a corporation, you are almost certainly doing things for narcissistic reasons (for some definition of narcissism/self-interest/self-gratification/self-actualization).
Many of the "antipatterns" are really defense mechanisms from the fundamental hobbesian nature of a workplace.
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.
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).
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.
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.
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.”
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.
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.
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.
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
> 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.
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?
If you meet an asshole in the morning, you met an asshole. If you meet assholes all day long, you’re the asshole.
You should try and see how websites like this facilitate technological excellence even though they make you uncomfortable.
That's both more mature and more likely to lead to technical excellence.
I am the PITA security guy that never has good news.
Stereotyping people into these jungian archetypes makes the error of presuming personality flaws and individual agency rather than load bearing organizational sociopolitical vectors, historical decisions and cruft that needs to be unwound, high level executive directives, and market conditions. That is to say, context, history, and structure; goals and incentives -- all this rather than theory which sounds good but is unfalsifiable (much like modern astrology).
It's borderline irresponsible and unethical to give these ideas the time of day, because they are intrinsically unfalsifiable and based on stereotypes. Constructively approaching any of the issues seen here requires concretely addressing reality -- how can you find evidence of previous challenges, how can you bring said person to understand those challenges, what are they interested in from their perspective (rather than what your stereotype presumes), and is there materially enough to work with to move forward with the working relationship in a constructive manner?
This kind of management consultant voodoo is a pox upon the industry. We should leave it in the past, where it belongs. You've got to ask yourself, what's your goal with these situations? Is it to be /right/? Or is it to /fix problems/? If you want to do the latter, you've got to connect with the other person, and get the solution to come from within /their head/. And frankly, drawing facile, degrading comparisons between them and barnyard animal stereotypes rooted in some blogger's desire to pathologically taxonomize isn't going to get you anywhere.
To end on a constructive note, I'm a fan of Camille Fournier's writing on management. I have found it to be very practically focused with a good blend of strategy as it pertains to the people side of things. If you're interested, read her blog [1] and her book [2]. There are also other classics like Moral Mazes [3] that I've seen come highly recommended from my network but haven't had the time to fully complete (and yet have liked so far). Start there rather than with this stuff.
[1] https://www.elidedbranches.com/
[2] https://www.goodreads.com/book/show/33369254-the-manager-s-p...
Force difficult people to borrow money from adversaries, the marxists, the jihadis, the drug cartel.
Take the difficult people's money.
When the loan comes due, dump them in the ocean. Good luck collecting.
There will be a standoff with your adversaries. To hell with nuclear weapons. How about using recent developments in fusion and matter waves to turn the sun into a giant microwave? Or, better yet, pair production and coherent control to turn the black hole the sun orbits into a giant microwave, and then melt a couple billion people off the earth as easy as adjusting the volume on my speakers.
The article mention heart surgeons. Not like any heart surgeon ever defrauded the public, cashed out in crypto, and flew to Mumbai from Canada with USB stick in their shoe. And not small town surgeons either. Heads of big pharma and research universities.
Granted, I don't know that it means there needs to be dedicated Product Manager roles. Granted, I as an engineer don't particularly want to deal with expectation management, scheduling, and capacity planning, and am perfectly happy to let someone else do it, but most of my work has been for the military and intelligence community and I think we have a much bigger problem there that org structure at the actual product development level can't solve. Our "customer" is an acquisition office, not the actual users of our products, and we're not legally allowed by the structure of contract law to have any direct contact with the actual users. So we cargo cult the hell out of basic agile principles that promise a more responsive and user-oriented process, but we can't legally implement that process the way it is actually supposed to be implemented. Instead of being directly accountable to our users, we're instead accountable to career bureaucrats who are more concerned about adding bullet points to their resumes while taking minimal risk than the actual needs and use cases of analysts and warfighters.
As your company grows, it easily becomes a full-time job, if not a full team. It has nothing to do with 'Project Managers' from the 90s. It actually is not about project management at all in many cases... the engineering teams run their own processes. But it is about making sure they are solving the right problems, at the right time, in the right way. (Meaning, correct consumer experience... Product Managers should not be telling the engineers what to do on the technical side.)
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 doing engineering, which is of course not great.
The definition of a product manager (and project manager/program manager) changes from company to company, but the work of defining the thing to be built is always being done, otherwise you're not building anything. It may be done by committee, by engineers, by engineering managers, by the CEO or via some other method entirely, but it's always happening.
On the one hand, we have "product" work. In an idea world, this consists of talking to users, understanding their individual problems, synthesizing this into higher-level problems for users to solve, helping design the solution and managing iterative feedback on all of these. This is real work and it's important work, at least if you care about consistently building products that actually help people!
On the other hand, we have "project" work: schedules, deadlines, tracking who does what, when... etc. This can be important depending on context, but it's as separate from "product" work as it is from engineering. It's also the most common vector for micromanagement, whether from actual managers, "stakeholders" or other roles.
"Product" considerations are certainly important for timelines and product managers are responsible for prioritizing which customer needs to address first, but exactly the same thing can be said of "engineering" considerations except engineers should prioritize which technical systems to build instead.
All of the complaints I've seen in this thread—and most complaints I've heard from engineers about "PMs"—sound like they're about project management, not product management. I imagine this is a symptom of some broader problem (unreasonable/arbitrary deadlines, micromanagement... etc), but conflating that with product management ends up making the product side of the work much harder and contributes to unnecessarily poor relationships between product management and engineering.
Ah, anyway, I was hoping to find a little disclaimer somewhere saying not to take this exercise too seriously.
And I think beyond that, the answer is to try to work hard to change your life circumstances (where you live, how much effort you put into your network, what skills you develop, how often you switch jobs) so that if you do want to make lateral moves within roughly the same role, it's straightforward. This heavily de-risks the possibility of getting stuck with people who aren't great. It might be common, but it's /not/ every team, it's /not/ every company. The labor market is still very favorable for technologists. Using the market momentum to find your way into a healthy team environment at a company with a healthy culture is highly advised!
Every ineffective manager that I've ever known thinks that they can coach people into being more productive, better team members... but in the end those managers simply pat themselves on the back while the employee goes on causing headaches for the rest of the team.
However, there is also a correalation between how difficult/toxic a team member is and how well they respond to coaching. At this point I think if a truly difficult team member responded to coaching, they probably would have stopped being difficult earlier in their career, because someone else would have told them to knock it off.
The only thing I've seen work there is being embedded into a culture that uniformally corrects the problematic behavior, and even that is a crapshoot.
However, that doesn't change my experience that most people do want to get better and do respond to help.
This is an extremely toxic way of dealing with other people and should be avoided. People are much more than a stereotype.
I follow a very simple rule - if I hate something about my job and it can't be fixed in the mid term, I look a new job. Overthinking this easily leads to burnout and frustration.
I was ready to walk out the org but then COVID hit and thankfully I no longer manage him.
I was ill SO much during the time I worked with the guy - my body was definitely trying to tell me something.
I guess he would fall under "The Diva"?
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.
I'm guessing their perspective on the related roles is either only through the lens of a developer, or through no lens at all, just squinting from afar.
I totally agree with the comments about not stereotyping coworkers. The way this site is setup is naturally contrarian to that idea.
Everything about this site feels gross.
But there are way more stereotypes there, so I agree that they are probably a developer.
How do you talk to people about actual issues in a way that'll get them to be honest/realistic with you? Create safety. Make sure it's clear that nothing they do/say will hurt them or you, or come back to do so later.
What I don't see here, what I don't see anywhere, is how to deal with a legitimate bad actor. I wish more of these kinds of things would talk about how destructive a person with intent to do damage can be, and how to effectively handle someone like that when you can't simply get rid of them.
These political animals also need a habitat, which means food/water, cover, and space. The stage of the organization sets up the conditions for these anti-pattern characters to thrive. The main incentives I've seen in organizations have to do with company stage. Institutions are their own kind of pseudo-soviet crazy, but companies have a life cycle with a finite set of stages, outs, and consequent incentives.
It depends on things like how much runway you have, committed revenue, investor horizon, and executive management character. Maybe there's a potential update.
If this is posited as actual guidance for interpersonal communication, run.
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'
The interesting part to me is that I don't think a person is necessarily just one type at a time. And there's another list of "these are the great types of developers" and I think people can probably be one or more of those good types and one or more of the bad types at the same time.
I find the Actor theory applicable - in the end, everyone in an org has dominant interests, usually not many.
And the most dangerous are the systems players - because organized groups can take out and dominate any individual. One of the reasons why those playing the system vs the value creators take over in most large organizations.
I think you hit the nail on the head. Personally, I'm really nervous of anything which further deepens "me vs them" dichotomies. They're really unproductive. If you're acting as a leader in any capacity building a product, you have to figure out how to nip these things in the bud before they metastasize like cancers.
I have found myself in a few of them.
> There is no “solution” to The Rockstar Developer
> It is impossible to solve The Aspiring Manager
> The Extreme Overestimator... is fixable, but there is no will to fix it.
> if The Incompetent Developer had the capacity to learn software development, they would have already
> All in all, [The Soldier is] nearly an impossible problem to fix.
> There is no fixing The Legacy Maintainer
At least having disabused ourselves of the ability to actually try to address issues, we can now get rid of management since they clearly have no work to do!
I say this as a soldier myself.
if the person is really just being obstructive, explain to their manager (or have your manager explain to that manager) why you think that team should fix the issue. keep going up the chain until someone with authority knows who ought to fix the issue. it's possible you get all the way to the CEO without finding someone responsible for fixing the issue, but in this case the problem is with the organization, not the IC.
At first I was horrified at this. “You can’t tell the boss no!”
Six months later I had to admit it was by far the most productive team I had or have ever been on.
p.s. interesting views, so am looking forward to learning more
The rest of his advice reads pretty poorly. He claims that non-technical managers don't hurt projects and that the remediation is just for developers to not rely on them to arbite technical disputes. At this point in my management career, I've witnessed several non-technical managers unknowingly misrepresent their teams capability, causing projects to fail without developer meddling.
I wouldn't take this website seriously.
Nothing more frustrating when working with soldiers who say they were just following orders and miss the forest surrounding the tree. In the end multiple levels of missed opportunity to provide feedback which points to a process problem.
Also don't let your QA team get too powerful...
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).
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?
Requirements gathering is the main job of the PM, and it's most definitely not technical (or at least not remotely to the level of technical knowledge required to actually write code).
For example, a PM at Twitter defined that Tweets should be 140 characters (at least in the olden days). That's a fundamental requirement of the platform, but it's related to the company's objectives, user engagement and other things that have nothing to do with writing the code. There's zero reason that engineers should have anything to do with that. Once it's been decided that Tweets are 140 characters max, then that requirement gets handed off to the engineers to actually do the development.
Obviously all oversimplified, but the point is that if you think requirements are technical, then you're probably dealing with bad PMs who aren't drawing them up particularly well. The irony is that when this comes up, it's usually because the PMs used to be engineers and don't have the experience to separate the two roles.
It's fine that you have a non-technical creative side, but it's frankly not what you're paid for. That's true of everyone in the organization - I'm really enjoy writing and am very good at it, but I don't believe I'm being mistreated or underutilized because I'm not asked to do copywriting. That's the purview of marketing, not product.
This is even true within engineering - if you have experience working on both iOS and Android apps, but you interview for and are hired for a role on the company's iOS app team, nobody is undervaluing you because they don't also ask you to work on their Android app.
Businesses benefit from specialization and focus of their employees. Product exists to gather requirements and define specs not because dev can't, but because that's not what developers are hired to do.