High performers tend to get bored with the reality of most development. This usually presents as over-enginerring and a reluctance to do dull but necessary tasks.
Over time the risk of them leaving builds and others are reluctant to take on their mantle (complex code, assumed overtime, whatever). I've never been able to hire a high performer with the remit of 'please take over this complex and custom system your predecessor built and walked away from' - such people want to build that stuff themselves and someone else has already had the fun.
Businesses want reliability and predictability, your high performance is probably better spent on your hobbies, or your own (ownership >= 10%) businesses.
High is relative to other team members so I suspect this is true no matter the baseline skill.
>High performers tend to get bored with the reality of most development. This usually presents as over-enginerring and a reluctance to do dull but necessary tasks.
Oh hell yes. This exactly matches my experience. To the point where I actually consider high performers a detriment to the overall effort. I have been the most happy with mediocre, cooperative people in the team.
I dunno, the best devs I know get bored but spend that in thinking a lot about how to make things simpler and with less. It's equally as challenging as over-engineering if not more so.
I would say it is basically the same on all levels. Devs just want to rebuild everything all the time and most of the time reasons are made up - real reason is they want to make it themselves their way.
This might be true sometimes, but it hardly addresses the real problem: WHY are (some) devs like that?
From experience I'd say that there are at least three (usually overlapping) reasons:
- There are often valid technical reasons to rewrite at least parts of the codebase. Most companies tend towards a "don't fix it if it isn't broken" policy, which tends to lead to most components being in a "not far from broken due to poor maintenance" state. It is reasonable to want to fix those up before they cause an outage. An ounce of prevention saves a pound of cure and all that.
- Making new things is more "fun" in one way or another, even if it is just because trying to grok the spaghetti code of another is "not fun".
- The dev in question has (usually correctly) identified that the way to get more of what they want, be it money or power or fun colleagues or interesting projects, is to be involved in building new things. It's no secret that humans often ascribe more value to those who make new things even if it's not justified.
Unless the environment becomes such that these three get mitigated, devs will always want to rewrite things as they are heavily incentivized to do so.
> real reason is they want to make it themselves their way.
I have a different theory. I think the real reason is that writing code is easier than reading. Literally, it's psychologically more comfortable to write code than to read it.
This is part of it that I agree with.
Downside is those devs forget that in 3-6 months of not working on that part will have the same feelings.
I work on the same system for 10 years now, I moved to a more dev ops position and don't write that much code, when I pick up some ticket I am really amazed to find out code that I am working on changing for the ticket is something I wrote a year or two years ago and I have no memories of writing that because I was doing thousands other tasks in different places of the system.
Which is why adding tests is a great way to get to understand a codebase.
College should redesign the courses, the job is software reengineering.
Most people who have studied this field we're in have gained Computer Science degrees. These courses often don't prepare the student for working as a SWE.
I work with more graduates of Russian than I do Software Engineering.
Meanwhile, universities should research the "One Right Way of Writing It" to defeat reengineering when possible.
> I've never been able to hire a high performer with the remit of 'please take over this complex and custom system your predecessor built and walked away from' - such people want to build that stuff themselves and someone else has already had the fun.
Are you hiring right now, cos this sounds like fun?
(modulo the likelihood that our definitions of high performance differ).
One of the easiest ways to be a 10x dev is to sabotage the productivity of every other dev on your team. I suppose it’s often not consciously intentional, but that’s the end result when you ship features at a breakneck rate using the bolt-on pattern. That being the one where every new feature is bolted on to the existing code without ever bothering to refactor or otherwise slow down and consider the design as a whole. The end result is the 10x dev runs the technical debt printing press hard and fast, and then once he perceives that the system is about to collapse under its own weight, he moves on to another project. Meanwhile whatever sucker takes over responsibility gets left holding that bag and the almost inevitable PIP that comes with it.
One of my more gratifying mentorship experiences was having one of the devs I advised come back to me years later and tell me how much my teaching him to recognize this phenomenon helped his career.
I don't think someone who cranks through 10x more features while leaving loads of debt behind them is a 10x engineer.
In general you could think of all software development as a heap of hacks. It gets taller and taller and taller until it falls over. What you are describing is someone who makes the heap a lot closer to falling over. The ideal of a 10x engineer is someone who makes the heap more stable, someone whose architectural contributions make it possible to have a higher heap and allow others to do more/better work. Over the long term a 10x engineer's product is the capacity for more growth.
Mentorship is certainly one way to get a longer lever to stand on -- a way of making investments in the future, but even feature dev can fit the bill: https://thedailywtf.com/articles/the-cool-cam
Ive seen this happen wayyy too frequently. My general perspective now is to never ever trust tech blogs or hype until youve seen a system work in production. 99% of the time its a polished turd for some dumbfucks promo packet.
Your definition of high performers seems different from the articles. How can someone be a high-performer if they don't maintain a system they are involved with, or consider how it will be maintained by others if they move on?
I see lots of really good Devs who love the details and making sure they are communicated well, writing code that is understandable and time on ensuring regular maintenance and upgrades are carried out or better still automated, but most importantly spreading that knowledge around the team.
It does sound like you have considered these things, just your definition of high performers seems like it could do with a rethink.
In every big company high performer means “ships, a lot.”
That’s one of the benefits of a higher job level. You get to claim credit for shipping everything you had a hand in even when your contribution was often little more than organizational presence. Which is to say, being the “face” of the project to upper management.
Doesn't reflect my experience of working in many organisations. Not to say I haven't seen what you describe, but only in the more dysfunctional ones. Maybe the issue is more the "low performing management"
Is it the case that high performers are bored by it? Or companies don't reward it with promotions?
> Over time the risk of them leaving builds and others are reluctant to take on their mantle (complex code, assumed overtime, whatever). I've never been able to hire a high performer with the remit of 'please take over this complex and custom system your predecessor built and walked away from' - such people want to build that stuff themselves and someone else has already had the fun.
Let me read between the lines here and assume the worst, then please correct me and tell me it doesn't apply to you.
A left. High performer candidate B didn't want to pick up A's stuff. Let's say it was over-engineered or over-complex or whatever. You ended up hiring C, and C was not a high performer. In fact, a wild guess: you hired two C's at the price of one A.
Perhaps your preference was to hire two "everyone is replaceable" C's all along? That's not to say that some projects are not more suited to low performers. But the engineering management style can tip the scales no matter what.
I think we're conflating skill with performance. The hiring system should be assumed to filter for a baseline skill, when I say performance I really mean output.
A high output team player is gold and we want as many as possible. A high output singleton will likely have sacrificed some element of quality or maintainability or thoroughness or likely even their own personal lives to reach that output, for the projects they enjoy doing.
That output is unlikely to translate into a new, less interesting project and if the work or system is now structured to require that level of output then few would want to take up the position.
The over used canoe metaphor is useful, you want people to pull at the same speed. I also enjoy the 'always be leaving your job' approach that guides people away from building themselves into the system.
Let me rephrase. Let's say you're writing textbooks instead of code. You need Ivy League PhD's to write grad school textbooks, but not grammar school ones. Here are two crappy scenarios I was thinking about:
- You choose to write grammar school textbooks just so you can hire cheaper writers.
- Or worse, you're required to write grad school textbooks but you still hire cheaper replaceable writers.
We are conflating skill with performance, but the 10x theory (IIRC) is that they are correlated, or at least can be given the proper motivation.
Team players are always better than singletons, so let's assume there's no correlation there (which may be a stretch, sure.)
Depends on how you define “high performer”.
Someone who doesn’t want to take over someone else’s code deep dive and understand it first is not high performer in my understanding.
Efficient debugging and understanding systems other wrote or created is basic requirement for high performing dev in my opinion.
Life is too short to want to spend it grovelling around in the shit left behind by other people.
There's a fundamental difference between being able to rip apart a ball of mud and rebuild something sane out of it and being excited to do that for a pittance.
There is a world of difference to rip something apart and rebuild just for one person ego and actually serving other people’s needs.
Isn't pittance the key word here?
Yep. I think there's a correlation between expecting people to joyfully do very boring things and believing they should do it cheaply.
[dead]
High performance is generally an anti pattern in software. The name of the game, at least historically, is first hiring and Jira task completion second.
The only real incentive to become a 10x developer, at least for me, is to use my time for other things. Otherwise, stepping outside the mold just upsets people in the corporate world.
> stepping outside the mold just upsets people in the corporate world.
This is the crux of the problem for me. How many of us are literally not allowed to work on stuff not on the backlog, which is usually driven by product people. We only deal with the product roadmap and other issues (technical debt, inefficiency, security issues, etc) don’t get resolved unless it somehow impacts the product. If you’re very lucky, you’ll have an actual technical CTO who has the power to say no and allow the developers to remediate issues (one CTO I worked with had to spend enormous political capital to get a single sprint dedicated to upgrading to Java 8 so that the developers could benefit from lambdas - something that for our code base literally cut development time in half due to the way we ingest and process very dynamic ingested data).
There must be some law of software engineering that all engineering teams eventually become run like assembly lines where management disallows ground-up thinking.
One place I worked finally only implemented a proper security program when a potential customer demanded it, and it was ultimately implemented as a checkmark-based solution to meet the terms of the contract. This meant burning CVE’s more than writing secure code.
This was frustrating as management at the time decided microservices were what we needed, but then resulted in a distributed monolith because they weren’t allowed to spend the time on architecture work, tooling to secure communication between services, or even have proper distributed tracing.
> There must be some law of software engineering that all engineering teams eventually become run like assembly lines where management disallows ground-up thinking.
Its a law of incentives.
At some point protecting the existing processes is more important than growing, which implies disruption.
At that point all the things mentioned above start
> High performance is generally an anti pattern in software.
Talk about "10X performers" reminds me of the saying "It’s a marathon, not a race." Most people recognize Usain Bolt, but how many people have heard of Eliud Kipchoge?
In our field, the "Usains"—the flashy 10X performers—are hailed as heroes. If you are a "Kipchoge", quietly focusing on a sustainable career, you will probably fly under the radar.
You and I have very different definitions of 10x developers. 10x developers are just people who can achieve vastly superior performance. Rarely is there any announcement, bragging, or bravado that comes with this. On the contrary most 10x developers tend to want to hide their performance up until they are ready to quit.
Its not like they are going to get paid 10x more for over achieving. There is nothing flashy to this. Instead they will be reassigned to other people's problems on top of their own work. So, its best to just keep it to themselves and over achieve as necessary to do less work, because they will get paid the same either way.
Kipchoge is less like "quietly focusing on a sustainable career" and more like "consistently maintaining the highest quality and pace of development and rarely if ever having an off week".
> "It’s a marathon, not a race."
Rather "it's a crawl, not a marathon".
Also, I think the most value a programmer provide is as a maintainer.
I blame feature factories led by agile clergy for the perceived drop in commercial software quality in the last 10-15 years. There is no place for maintainance.
> I blame feature factories led by agile clergy
This is a weird take. The most basic principle of agile is that you start with a tiny kernel of software that does something useful, and then iterate on it. In effect, all agile software development is maintenance.
>Otherwise, stepping outside the mold just upsets people in the corporate world.
That's not exactly true. What upsets people in the corporate world is telling others that their creative ideas enshrined as a Corporate Policy are wrong and asking to do it the other way.
What doesn't upset people in the corporate world is finding a way to further said Policy while at the same time getting yourself a license to some creativity in the ways to implement it.
As a JavaScript developer you live in a world where people are afraid to write software... any software, at all. When I say afraid I mean that word in the very visceral emotional way. It is a culture of extreme Invented Here Syndrome where you add dependencies and if there is not a dependency that already solves a given problem the problem is simply not worth solving.
So, you end up with these colossal frameworks, yes that's plural. The developers like to pat themselves on the back for their supreme challenge of conquering the beast to... put text on screen. It's stupid, but it a way it's self-validating because these frameworks are just massive. They provide an API more than 10x larger the standards they replace so that developers don't have to form original opinions or build things.
When I say stepping outside the mold I mean not doing any of that stupid shit. As a result of avoiding the stupid I can release products that are possibly 1000x faster to execute, more accessible, dramatically faster to maintain, and so on. One developer that actually knows what they are doing can easily replace an entire development team. If that one developer that knows what they are doing always knows how to implement test automation they can reduce expenses associated by regression around 95-98%. But when you do any of that you have immediately invalidated the existence and imposter nonsense of the other developers like popping a balloon. The natural response is hostility.
Fortunately I was able to switch careers and go do something else.
I've experienced this.
It'd be nice to hear from the counter example here, the 10x developers in meritocratic nests. Mostly so we know where they are.
Here I am, hired as a team lead, got to a VP of Eng. in 2 years during which I fixed (initiated and led the projects, didn't code myself) many long standing issues with the company's engineering organization and the product itself. I was a director before this job, though at a smaller company. It's a 200-person startup.
I'm kind of an high performer and it's not so simple. The first thing is that you need to flight under the radar most of the time. It doesn't pay to do 10x all the time (and realistically you can't constantly in all facets of your job), you need to do 1.5x most of the time and then do 10x when it's most needed and most clear to everyone that you just saved the day.
The second thing is that I never said no to more money. It's a job, your boss and colleagues are people who work with you. Occasionally they can become friends but not automatically and not most of the time.
Corporate world ain't the place for 10x devs, that's just a non-primary skill maxed.
Primary skill is somewhere around understanding politics and grokking how to please the person evaluating / promoting you. If its about rating from others then same applies to them. Rarely is that directly relevant to quality of engineering output itself.
This goes often very directly against innate desire of engineers to do some good creative work so we often struggle to get appreciated, but that's how it is. That's why various degree of sociopathy present naturally helps with above and smart sociopaths comfortably inhibit higher levels of management of such places. I don't use that term as an insult just to be clear, rather personality trait that is not binary but very much endless tones of grey.
Triple above if IT is just a cost center to given corporation.
Managers and managers of managers, absent a few limited scenarios (vocation, edge case personal finance stuff) your high performers are seeking more comp. No fluff or hallway conversation will make up for that. You’ve got to make their lives decent and win the end of FY comp knifefight. You can safely ignore everything this person wrote.
I think a lot of people will quit on the spot when having high compensation but no say and being just a ticket closer and being scoffed at by not making quota.
I’d rather lower compensation but actually being heard out by business.
It also of course usually works that having higher compensation goes in hand with business listening to people with higher comp.
Yes, in practice more often than not, the people who respect you enough to pay you well often also respect you enough to treat you well (and the opposite).
It's less of a trade-off than it's often portrayed as.
> Yes, in practice more often than not, the people who respect you enough to pay you well often also respect you enough to treat you well (and the opposite).
In practice, these are not the same people. The people who have a direct impact on empowering and respecting you are your manager and their manager.
These people also have (having been one) surprisingly little say in how much you get paid. HR rules that land. We can present arguments and beg and plead, but ultimately don't really have any decision making power on the paycheck side.
There's probably a causal relation too: both the compensation AND the desire to take ideas seriously come from the same source, which can generally be summarized as "respect for the way specific expertise can help along a shared cause".
The fact that we are arguing about the basic rules of money still is amusing. Any corporate drone can tell you that allocating budget is the main way a corporation identifies what is important. If it wasn't, why is the CEO getting paid so much? Why are the biggest problems and the dearest things allocated the most budget? How many backflips do we perform for said things? Any other interpretation is ignoring the most basic power dynamics at play.
You don’t get to be high performing if you’re just closing tickets. High performers add significant value and provide real impact.
If tickets are filed by customers and closing them means I solved the issue for the customer thereby making them happy, being a better ticket closer totally adds significant value. It’s the difference between “my ticket was solved satisfactorily in 10 minutes, excellent support” and “it’s been weeks without a reply because there are 500 tickets in the queue and nobody gives a crap”.
You know those people you meet who say 'I used to code...' They traded IC software work for being able to have a say about the business. They never look happy.
I can see myself in this comment and I don't like it.
Pushing teams and product managers to take a bit of time up-front to consider architectural decisions, ideal vs minimal feature sets, security concerns, etc. got me promoted into a manager of managers role.
What I didn't realise was that it wouldn't actually mean having more weight to throw around. Instead those sideline efforts became my entire job and that job was exhausting.
I still believe it's possible for startup product teams to move fast without sacrificing quality and sustainability, but I'm increasingly convinced that the only way to achieve that balance is to build it in from the start.
There are also the ones who were never good at it and use it as badge of honor like stolen valor.
Because no one has means to validate what actually they did.
I have seen loads of ppl who cannot make heads or tails in code but went management route.
Many of my friends used to code, and either moved up the engineering ladder chain or moved to other more business-y roles.
Only one went back to coding. Most of us are quite happy with our work (not sure how we look).
Yeah, because the happy ones don't mention that they used to code ;)
Can't speak for everyone but most times I left jobs for those with lower comp. I wanted to do something else or have more autonomy. Basically non salary concerns. If it was just salary you wouldn't see turnover at FAANG companies of 2-3 years. A ton of people leave and take huge pay cuts because they don't like the work or feel bored
golden handcuffs are real, you rapidly stop caring about compensation if you don't wake up interested in the goal or how it's done
a good team and good project is worth a lot
> You can safely ignore everything this person wrote.
I could say we can safely ignore everything you wrote. Not everyone is driven solely (or even primarily) by money alone. Some/many people are, so your take is one of many valid ones but not the only one. So managers, you actually need to understand what drives your high performers.
I have never quit a job due to pay, it has always been due to other factors.
This comment above is absolutely gold and true! An organization can offer the following benefits to employees: Comp(salary, bonus, etc), health Benefits(health, insurance, counselling), autonomy, interesting/challenging work, push you out of your comfort zone, a non-toxic environment, etc.
The key is to recognize the Maslow's hierarchy here as well (hierarchy of benefits, instead of hierarchy of needs). Once you offer someone top comp and top health benefits, you have crossed the hygiene layer. Then you go to the social layer (recognition, awards, non-toxic env) and finally the self-actualization layer (autonomy, pushing them harder, long-term aspirations).
Dont cheap out on the hygiene factors!!
> An organization can offer the following benefits to employees: Comp(salary, bonus, etc), health Benefits(health, insurance, counselling), autonomy, interesting/challenging work, push you out of your comfort zone, a non-toxic environment, etc.
A non-toxic work environment isn’t a “benefit”, it’s a basic requirement. Same for autonomy. Healthcare is just compensation.
In the end, compensation is what matters.
Non toxic environments are rare and are absolutely, 100% a benefit. If you don’t believe this Im genuinely happy that youve had such good experiences.
Not ignore, but carefully consider. At certain point, money stops being the only motivator that can be used. Few years ago, I wouldn't be trading money for spending more time with my kid, but now I am willing to make that trade. I guess what I am saying is that thing do differ and while it makes for an easy quip 'pas d'argent pas de suisse'. I mean, it is true in general, but not an absolute truth without exceptions and edge cases.
<< You’ve got to make their lives decent
And this is where we agree. If you can make the performer life better ( not automatically with money ), you got their attention.
This may be true— but I also think few “high performers” are seeking less responsibility/commitment. They are working hard to be recognized for it, and the recognition ought to be financial in most cases.
I totally agree with your sentiment but I think “more free time” is a difficult award in general. Most managers would probably look at most high performers and say “you want more time? Then work less! You are already over performing” it’s somewhat out of their hands how much someone chooses to work, but they can more directly control how much they pay and award via bonuses.
I think you are right in terms of an employee class. Anecdotally, my buddy ( I don't see myself as a high performer those past few years ), is going out of his way to make things work, while I kinda drift along. He is definitely more stressed and he should get cash money for it, while it is still an option AND he is not burnt out.
I feel that 'burn out' in many cases is realizing the futility in 'working hard and giving your best' for someone else without being compensated for it.
Note that I am not denying pathalogical burn out is a thing.
Yeah, but I think a lot of the compensation people in this situation need comes from recognition and autonomy. Like, money is great and all, but as long as you have "enough" then those other factors are super important.
Like, I'm currently willing to take a pay cut to get more autonomy and a better (for me) workplace environment.
Correct! In the vast majority of cases we're talking about base salary or daily rate increases exclusively. Money. Now. End of story.
There is also a downside - high performers doing stuff they think is important disconnected from business reality.
It goes well when company goals align with high performers goals and as soon as the two diverge it starts being more problem than not.
We have lots of articles and voices about CV driven development so that is also there.
It's been my experience they're kept in the dark by Product, on purpose. So no wonder when they're bored they just do what they can in their little box, disconnected from the business
Very much a "developers do the Jira tickets I create, that's it" kind of mentality in most PMs I've ever met
Why do you think they are kept in the dark on purpose?
Politics, at least in our company.
If they're off doing things that are disconnected form business reality, how can they be performing at all?
A good example is fixing massive technical debt on a service that's either rarely touched or wont be around in a few years. The performance required to do this is impressive, but it adds little business value. It's all relative, high technical performance but low business productivity.
This article[0] about tech debt was posted the other day on HN. It seems to be a good guide for how to determine what type of tech debt to take on.
Exactly what you're saying - does this tech debt Work™ or is it affecting future development or causing incidents?
[0] https://technology.riotgames.com/news/taxonomy-tech-debt
Yikes. No, leave me alone. I don't need weekly 1:1 meetings and other stupidity.
4. Autonomy and Trust
One of the quickest ways to disengage a high performer is to micromanage them. These individuals have proven time and again that they are capable, innovative, and reliable.
The saying that “A level management hires A’s , while B’s hire C’s” is true and directly ties into this.
The arrogant-yet-incompetent management I have encountered actually makes it difficult for high performers since the mental “box” they want people to fit into and be cogs in the machine, gets exposed as false; the usual way to fix this is to get rid of the problem, by firing the high performers.
I mean, I don't disagree with you, but it's important to note that high performance is incredibly context dependent, like the same person can be a rockstar at company A and complete garbage at company B.
Ultimately, I think if the management has self awareness and clear goals, a lot of this crap can be avoided (but sometimes that means selecting out people who are rocking, because they don't match the system).
What the article seems to miss is that for every delusional high-performer who's about to be short-changed on reward and recognition, there's an order-of-magnitude more potential high-performers who aware of the lack of reward and recognition, are having a nice relaxing life. Possibly knocking out their work in a couple of hours in the morning and spending the afternoon studying micro-biology to perfect their sourdough pizza crust.
i.e. retaining your 10x superstar is important, but are the rest of the team really only capable of 1x? Really? What's the benefit to them of giving 2x?
There seems to be some myth that everybody gives every ounce of their potential, out of the goodness of their heart as an employee. I think the reality is that most of us do whatever the role requires, plus anything we happen to enjoy/fixing frustrations.
This is a really good insight.
You also have the effect where the perception of being a 'high performer' might be gamed.
E.g. it might be rather trivial to churn out code and be perceived like a high performer, but you are essentially just creating alot more job for everyone else and drag them down.
Also, it is easy to do so much stuff that you will be blocked and waiting on other, who seem slow etc.
Unless the manager is working along side you he likely wont notice. And these points also happen automatically by itself. But I guess adversial collegues use the concept to game the workplace.
In the vast majority of cases the answer is more money. Employers will do literally anything besides offering that, even when explicitly told by the top performing employees that they only want more money and nothing else.
The one flaw I see in the premise of this article is that, very often, high performers are much smarter and more capable than their managers, so expecting managers to recognize the talent and not be threatened by it when they do is unrealistic.
It’s uncommon but not unrealistic. The old adage “surround yourself with people smarter than you” applies and is a mark of a good manager. Maybe it’s good if the manager is not a clueless MBA and has enough technical expertise to understand what the team is taking about. It should be a manager of manager’s job to identify and replace managers who don’t understand this.
Absolutely, and I’ve worked with (and tried to model myself on) people who hire people smarter than they are. If nothing else, management is itself a skill and many highly competent doers have little interest in management. And that’s ok! But I have seen way too many managers-promoting-managers and ignoring doers along the way.
"So, what do high performers really want in the workplace? They seek recognition, growth opportunities, and autonomy, but retaining their commitment requires more than just understanding these needs."
Or you could pay the high performers more and compensate them better?
People are generally not spending their time at work for sheer altruism. There are of course exceptions, but I would say the majority has bills to pay and the uncertain future to consider; people work, not because of self-fulfillment and spiritual growth and whatnot, but because they get money for their efforts.
Also, if the work environment is micro-managed, meeting-infested, has arbitrary policies, lacks autonomy, does not recognize people, has near zero growth opportunities, bottom ranks go "WTF?" every time when upper ranks open their mouth, and so on, I doubt people can become high performers to begin with.
That is: the work environment has to do something right for high performers to arise at all. So, optimizing the components of a good work environment further might be fine, but if those are already on an OK level, from the point of view of the high performer: what's the point -- what's in it for them?
Trust is important for high performers. Trusted to get the job done and to make the best decisions.
Consistently been such a high performer, but being gifted, ADD and on the spectrum made absolutely sure I can’t be politically correct enough to get any form of compensation, approval or recognition commensurate with my achievements. You get used to it I suppose, both a blessing and a curse.
Tell me more. I don't really think that isn't possible to learn -- I'm not saying lying, I'm saying adding a second translation layer which allows you to tell the truth in a inclusive way. "Black people are dumb" VS "People with less access to quality education tend to be disproportionately people of color".
Then again, I don't live in the States.
I don’t either. Didn’t mean it that way, sure, interesting point. I could learn that translation layer and I surely tried. But so far it’s been pretty unsuccessful to say the least.
That is probably because you are not a Yes-man, not because of DEI policies.