What 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.
That was my thinking when I started reading it. The site is missing an archetype: The Zebra, a developer who sees everyone around them in black and white terms and focuses on calling out problems for all to see rather than fixing them as quickly and gently as possible.
Ah, anyway, I was hoping to find a little disclaimer somewhere saying not to take this exercise too seriously.
Have you actually experienced working with co-workers who exhibit all the symptoms of sociopaths/narcissists? They will take your trust and good intentions and do whatever they can to take advantage of it. Most people are worthy of trust. But the 3% that aren’t are toxic/dangerous in ways you will only realise after the damage is done. So assume the best but don’t be naive.
While this is true, you do yourself no favors by remaining there and "surviving" the dysfunctional work environment. As the old canard goes, your best option is to either "change your job, or change your job."
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!
Yep I completely agree. My point wasn’t that you shouldn’t get away from the situation. My point was that believing you can change/improve all people is naive and potentially dangerous.
This coaching fallacy is actually quite toxic in my experience... many/most people in the workplace don't want to change, and they don't want constructive criticism.
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.
That’s a dangerous generalization imo. There are absolutely organizations that value folks who are receptive to constructive criticism and who are willing to keep an open mind about all sorts of things. These companies screen carefully for characteristics that align with that culture and I can say from experience that it produces a much better working environment.
I do a lot of mentoring and coaching. Very roughly, 60% of people respond well, 30% struggle but have some improvement, and 10% don't respond at all. I really do think 90% of people benefit and change at least somewhat from coaching.
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.
We all have simplified models of other people in our heads. Without it we wouldn’t be able to function. You do too. However you might be fooling yourself into believing that your understanding of other people is somehow better than everybody else. That is another common characteristic of people: thinking that your understanding of the world and people skills are better that most. Most people think so but it obviously can’t be true. We aren’t aware of the automatic non-reflective categorisations that our subconscious makes for us before our “thinking” kicks in.
I think its a great Illustration of the different problematic behaviors you encounter when you work pretty much anywhere. However, the solutions although quite straightforward and make sense, in real the situation is not so simplistic. For e.g. you have the dictator PMs that refuse to do anything that didn't come from them. The solution is to have the upper management talk to them. In my work, we have a PM who is literally sitting at the top of the chain (reports to CEO) and displays those characteristics. Pretty everything anyone has tried to solve this problem in the last 10 years, hasn't worked and people have destroyed their own careers over trying to fix the behavior. In cases like this, the only thing that works is either do what they say or find another job.
Software 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.
Whilst technically leading a software project, I worked with a contractor who was so arrogant it defied belief. He told me he was smarter than everyone else in the organisation, and repeatedly told me that he used to work "at board level" whenever he wanted to override my decisions. You know what - I'm fine for anyone in a team to express different opinions and happy to take them on board, but there's a way of going about this without being so hostile. You don't accuse colleagues of being "stupid" (which he repeatedly told us) and then go on to make massive errors in the codebase, over-engineer everything and refuse to read documentation because "I know better". He seemed to really have it in for me, which is odd considering I've worked with plenty of software contractors some of which still message me years after they left just to say "hello".
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.
Throwaway 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.
You are absolutely right. It has been shown again and again that people in general overestimates their own intelligence, skills, people skills etc. And (in general) that the more incompetent you are, the more you inflate your own believes of competency.
The author is clearly a developer, as there are some positive stereotypes in that category, but no positive stereotypes in any other category.
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.
While that is the title of the site, the site also has an entire section dedicated to "Dev Types" which all sound like a one-sided glorification of highly questionable developer behaviors.
~There are no positive stereotypes in that category.~ Scratch that, you are correct. The entire website does have some, outside of that "difficult people section".
But there are way more stereotypes there, so I agree that they are probably a developer.
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.
Almost every single one of these problems can be solved by talking to the groups involved.
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.
Agree. Most of the time you can simply have a quiet polite conversation with difficult people and they will realise that they need to change and sometimes even thank you for letting them know. But I have experienced cases where co-workers don’t give a f** about anybody but themselves, will hate the fact that you approached them, and will go out of their way to sabotage you and everybody else in the future.
Can recommend another couple of anti-pattern archetypes, but maybe adding a level above product about the form the organizations themselves take could provide some additional insight. It could be helpful to look at the incentives for why these figures emerge. Nobody wants to become these, but they do it to survive. They only do it because it works for them, and we get what we reward.
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.
While most of those advices (or rather tricks like go around or hire replacement and ask to train them) would work sometimes, they lack empathy and reproduceability. In fact might even be counter effective.
From my experience it works best to build good relation, give honest feedback and ask for reasons of bad behaviour. It might be because of some factor that we do not know or control (eg someone has problems at home, has different understanding of their role, are not aware of the scale of effect of their actions). Only after, if it won't improve, clear boundaries should be shown, which when overstepped would result in well defined consequences. If behaviour is noxious to the team, it is much better to let offender go early on clear notice, not as results of playing some psychological ticks on them.
How 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'
There's some kind of online quiz in that site to find what type you are.
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.
There is a view that the ego, being non-existent, is constantly shifting and re-framing. Observe the roles/personas you shift to throughout the day, how and why?
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.
> otherwise this is just another way to see the world as 'me vs them'
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 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.
If the author is reading this. I think this website would have been much better if you presented these flaws as biases as opposed to labels. You can also make it clear that bias is something that you can change about yourself by being conscious about it and changes over time.
Which 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...
> 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!
Where is the category for devs that will weasel out of any work by claiming a ticket is out of scope, or that the responsibilities for handling a certain piece of work lies with some other team, or that you should go through the project manager so that the work can be done 5 sprints later?
the first thing I ask myself in this sort of situation is whether the person is actually correct. part of being effective in a specific role is refusing to take on random work people throw at you. estimates can't be valid if key players are spending lots of time on stuff that wasn't on the schedule.
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.
huh, they should be writing up their own after building a shared understanding of the problem in hand, what you experienced was a top down ticket factory
Curiously, the author doesn't bother to categories difficult executives. He exhibits a willingness to criticize everyone except for the ones far above him.
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'd be interested in discussions on the Silos, the CYA , the NIMBY and the NIH archetypes. Silos is generally indicate a bigger org problem. CYA blames everyone else, the NIMBY refuses change, and NIH reinvent everything.
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.
Its funny but you may find you might take some of these negative labels over your career. I have been a number of these but it depends where I am in my life, career and the project. Currently I am a "Rockstar" developer.. and looking at the door. Luckily this project has a specific end date I can plan on.
I'm fine being labeled an idealist. Depending on the client or employer, this role has served me well. On occasion, there is no space for an idealist and if alignment can't be carved out, I'm happy to move on.
Now. Where can a 57yo idealist find a job in today's world?
I don't see a single reference to backstabber, empire builder, or middle management machiavelli. Maybe ladder climber, but who in "management" isn't in the ladder climbing business?
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.
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.
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
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).
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 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.
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 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.
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.
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.
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.
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.
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.
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
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?
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.
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.
I 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?
The bulk of software that is actually making money and not just trying to convince investors to get in early enough to get rich off of other investors before enough people figure out they're never going to monetize are still selling to enterprise customers. For every 30 people figuring out how to profit off a user-facing web app, there are 3000 chugging away at basic J2EE or maybe Spring Boot now for some proprietary backend business system for a Fortune 500 or the government that no member of the public will ever see. This sort of work seems to have become invisible to web-based developer communities like Hacker News, but they're still there. The need and the demand has only grown.
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.
All software companies have someone fulfilling this role, it just isn't always a full-time job with that title. Somebody is deciding what the product will do. In tiny companies, it may be the founders. As it grows, that may filter down to other teams. Or, if nobody takes on the role, the engineers will take it by default because they are literally the ones who choose what the product does as they write it.
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.)
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 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.
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.
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.
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 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.
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.
It's not about assuming that devs are only worth their coding skills, it's about recognizing that their coding skills are what they're hired for (and also what they're extremely highly paid for).
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.
Alright, keep cooking up the ideas in an ivory tower and us lowely well paid devs will just code it up. Because that is how outsourcing works. Really, may as well outsource your in-house devs.
This view is a really poor understanding of what engineering is about. If what you are saying is true then we wouldn't be sitting here trying to encourage engineers to learn every layer of the stack. Each of those layers is significantly different and quickly falls out of the domain of a Software Engineer.
I have the same categorical feeling of revulsion seeing this kind of pseudoscience today as I did when I first saw it a year ago. This is basically corporate astrology. It's unfalsifiable, patronizing, reductionist and amounts to unwarranted adversarial psychological aggression. If you ever used this in the corporate setting at any place I've ever worked at, you'd be laughed out of the room so fast it would make your head spin.
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.
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.
I 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.
THIS IS SOOO GOOODDDD!!! I'm thinking how to make this a team activity to kindly label each other and understand how to address them as a group. Though i guess this requires a maturity that is rare...
