The Disenfranchised Designer is spookily good
How to deal with difficult people on software projects
71–80 of 130 posts
Re: How to deal with difficult people on software projects
#72Software engineers have the privilege of being at or near the top of the food chain when it comes to job mobility.
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.
Re: How to deal with difficult people on software projects
#73I for one want to see a Security section.
I am the PITA security guy that never has good news.
Re: How to deal with difficult people on software projects
#74Earlier quoted context omitted.
I'll second that. Any time I've seen PMs involved in dev work (like requirements gathering) it's a shit show. PMs can usually have shallow conversations about software, but not deep enough to do requirements gathering.
I hope you have better experiences with product orgs in the future, because based on what you're saying, you have worked with some really bad ones. 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…
Wow. You probably have high dev turn over rate or extremely complacent ones. Mistake many pms and execs make is assume dev is only worth they’re coding skills. We are humans who also have a non technical creative side. But the assumption is someone has already done all the high level thinking so we don’t have to.
Re: How to deal with difficult people on software projects
#75I kind of like it. All the comments saying not to categorize your co-workers are right, but---to an extent, we are what we do. I think it's a useful list of behaviors people can fall into, without making comment on their eternal soul.
Re: How to deal with difficult people on software projects
#76I 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…
It seems like many companies do a poor job of separating product management from project management—I believe this is actively counter-productive and explains the issues engineers complain about.
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.
Re: How to deal with difficult people on software projects
#77Which personalities displayed in this article sum up for a developer which is also lead developer, CTO, very oriented on functionalities delivery, strict about new ways (always wants to write an article about something, always wants to do research, to the point where I as a 10 years of experience dev feel like he does not trust me)? And yes he is someone who does not trust if I do not back my ideas, opinions or methodologies with googled articles. He also has no sense of humour, or does not show up with it in the team. I sometimes think about him he is a robot...
Re: How to deal with difficult people on software projects
#78Earlier quoted context omitted.
If the dev team reports to a non-technical PM, your organization has bigger issues than just a rogue PM.
The entire org reports to a non technical person. That's how almost every company operates.
Most companies won't ever go close to a trillion in valuation either.
Re: How to deal with difficult people on software projects
#79How do I deal with working with the sort of person who would make this website?
Re: How to deal with difficult people on software projects
#80Earlier quoted context omitted.
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).
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…
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.