The Great Tech Terminology Debate: When Slang Goes Professional
You're in a meeting with upper management, discussing why your team's productivity has dropped 30% since the latest platform update. The new "AI-enhanced" interface requires three extra clicks for every common task, notifications have become relentless, and the search function now prioritizes sponsored content over actual results. Your colleague leans forward and says what everyone's thinking: "It's classic enshittification." The room goes quiet. Was that professional? Appropriate? Or just painfully accurate?
This scenario plays out daily in tech organizations worldwide. The term "enshittification"—coined by writer Cory Doctorow to describe how platforms degrade quality to extract maximum value—has moved from niche blogs to mainstream tech discourse. But as we navigate 2026's complex software landscape, where AI integration often means feature bloat rather than genuine improvement, professionals face a real dilemma. Do we embrace this visceral, descriptive term that perfectly captures our frustration? Or do we stick with safer, more corporate alternatives that might not convey the urgency of the problem?
In this article, we'll explore the evolution of tech terminology, examine how "enshittification" has permeated professional discussions, and provide practical guidance for sysadmins, DevOps engineers, and IT leaders navigating this linguistic minefield. We'll answer the questions raised in recent community discussions and give you the tools to communicate effectively about product degradation—whether you choose to use the controversial term or not.
The Origins and Evolution of a Perfectly Descriptive Term
Cory Doctorow didn't just invent a word—he gave voice to a phenomenon that tech professionals had been experiencing for years but lacked the vocabulary to describe succinctly. The concept follows a predictable pattern: platforms start by being good to their users, then become good to their business customers, and finally become good only to their shareholders at everyone else's expense. What makes the term resonate so strongly is its specificity. It's not just "getting worse" or "declining in quality." It's a particular kind of degradation driven by specific business incentives.
By 2026, we've seen this pattern play out across countless platforms. Social media feeds prioritize engagement over meaningful connection. Productivity tools add "AI features" that complicate rather than simplify workflows. Enterprise software becomes subscription-based with mandatory annual price hikes and reduced functionality in lower tiers. The term gained traction because it's diagnostic—it doesn't just describe the symptom but points to the underlying cause: a shift in who the platform serves and what it optimizes for.
What's fascinating is how quickly this moved from tech commentary to professional discourse. I've personally heard it used in meetings at Fortune 500 companies, seen it in internal documentation at major tech firms, and watched it appear in official communications from industry analysts. The speed of adoption tells us something important: when a term fills a genuine gap in professional vocabulary, it spreads regardless of its origins or perceived propriety.
The Sysadmin Perspective: Real-World Usage Patterns
Let's get specific about how this term actually gets used in professional settings. Based on discussions across sysadmin communities and my own experience consulting with IT departments, I've observed several distinct patterns.
First, there's the "water cooler usage"—informal conversations between technical staff where the term serves as shorthand for shared frustration. "Did you see the latest update to our monitoring platform? Total enshittification." In these contexts, the term functions as professional slang, building camaraderie through shared understanding of technical degradation patterns.
Second, there's what I call "diagnostic usage" in technical documentation and post-mortems. I've reviewed internal reports that literally use the term to categorize a class of problems. One DevOps team I worked with had a "enshittification risk assessment" section in their vendor evaluation framework. They'd track indicators like: reduced API reliability without corresponding price decreases, removal of self-hosted options, or the introduction of "AI features" that actually reduce usability.
Third, and most controversially, there's the "escalation usage"—bringing the term into conversations with non-technical stakeholders. This is where opinions diverge dramatically. Some senior engineers argue that using visceral language is sometimes necessary to convey the seriousness of technical debt or platform degradation. Others maintain that it immediately undermines credibility with executives who prefer more measured terminology.
Microsoft Copilot and the AI Acceleration Effect
The original discussion specifically called out Microsoft Copilot as an example, and this deserves deeper examination. What we're seeing in 2026 isn't just traditional feature creep or monetization pressure—it's something new. The rush to integrate AI has created what I'm calling "AI-induced enshittification," where products become worse specifically because of how AI features are implemented.
Take Microsoft's ecosystem as a case study. Office 365's integration of Copilot has followed a familiar pattern: initially promising productivity gains, followed by intrusive suggestions that can't be fully disabled, then performance degradation as the AI models run locally, and finally, the relegation of previously standard features to higher pricing tiers. The sysadmins managing these deployments aren't just dealing with technical issues—they're facing user rebellion, training overhead, and genuine productivity losses.
But Microsoft is just the most visible example. I've documented similar patterns across the DevOps toolchain. Monitoring platforms that now prioritize AI-generated insights over raw data access. CI/CD systems that push "smart deployments" that actually reduce transparency and control. Container registries that use AI to "optimize" images in ways that break compatibility. In each case, the pattern is the same: AI features are added not because they solve user problems, but because they're marketable and lock users into specific ecosystems.
The concerning trend for 2026 is that this AI integration often serves as cover for broader platform changes that reduce user autonomy. When you complain about a feature being removed or made less accessible, the response is often, "But our AI can handle that for you now." Except it can't—or at least, not reliably enough for professional use.
Professional Alternatives: When You Need Corporate-Speak
So what do you say when "enshittification" feels right but might not be appropriate for the audience? Having consulted with dozens of organizations on technical communication strategy, I've developed a framework for discussing platform degradation professionally.
First, there's the value extraction framework. Instead of saying "enshittification," you might describe "a shift in value allocation from end-users to platform shareholders" or "increasing asymmetry between user value delivered and value extracted." These are corporate-safe ways of saying the same thing, though they lack the punch of the original term.
Second, consider the technical debt analogy. You can frame it as "accelerated platform technical debt accumulation" or "architectural decisions that prioritize monetization over maintainability." This connects the concept to something most technical managers already understand and track.
Third, there's the user experience perspective. Terms like "progressive feature degradation," "negative usability migration," or "value inversion in the user-platform relationship" might work in formal documents. My personal favorite for executive briefings is "platform maturity misalignment"—it sounds academic enough to be taken seriously while accurately describing what's happening.
But here's the reality I've observed: the more senior and secure someone is in their position, the more likely they are to use direct language. I've heard CTOs use "enshittification" in board meetings when they need to cut through corporate doublespeak and make the stakes clear. The term's power comes from its inability to be sanitized or misunderstood.
The Cultural Divide: Generational and Organizational Factors
Whether "enshittification" works in your professional context depends heavily on your organization's culture and the generational makeup of your team. In my consulting work, I've noticed clear patterns.
Younger tech professionals (Gen Z and younger Millennials) generally embrace the term without hesitation. They've grown up with platforms that constantly degrade, and they appreciate language that accurately describes their experience. For them, avoiding the term can feel like participating in the very corporate doublespeak that enables platform degradation to continue unchallenged.
Older professionals, particularly those who came up in more formal corporate environments, often prefer traditional terminology. They might see "enshittification" as unprofessional, emotional, or lacking in precision. This isn't necessarily about being stuffy—some genuinely believe that maintaining formal language preserves important professional boundaries and objectivity.
Organizational culture plays an even bigger role. In startups and tech-forward companies, the term is often embraced as part of a culture of direct communication. In highly regulated industries (finance, healthcare, government) or traditional enterprises, it's typically avoided in formal contexts. The most interesting cases are in the middle—companies undergoing digital transformation where different parts of the organization have completely different norms.
My advice? Map your organization's communication culture before deciding on terminology. Pay attention to what language gets results. Does direct, visceral language move decisions forward? Or does it cause stakeholders to dismiss technical concerns as "emotional" or "unprofessional"?
Practical Communication Strategies for Technical Leaders
Let's get concrete about how to handle this terminology question in your daily work. Based on managing these conversations across multiple organizations, here's my practical framework.
First, know your audience and purpose. In technical design documents or post-mortems for engineering teams? "Enshittification" might be perfectly appropriate if it's part of your team's shared vocabulary. In a risk assessment for legal or compliance? Probably not. The key question: Will this language help or hinder the document's purpose?
Second, consider the escalation path. I teach teams to use a "terminology ladder" approach. Start with precise technical descriptions in documentation ("API reliability decreased from 99.95% to 99.5% while costs increased 40%"). Use conceptual frameworks in team discussions ("This follows the platform degradation pattern we've seen before"). Reserve visceral language like "enshittification" for when you need to escalate attention to a critical problem that's being ignored through more formal channels.
Third, document patterns, not just incidents. One of the most effective strategies I've seen is creating internal documentation that tracks platform degradation patterns across vendors. When you can show that three different tools have followed the same negative trajectory—reduced transparency, increased lock-in, degraded performance—you don't need visceral language to make the point. The data speaks for itself.
Finally, develop shared vocabulary within your team. Have explicit conversations about what terms you'll use in what contexts. Some teams I work with have literally added "enshittification" to their team glossary with specific guidelines about when it's appropriate. This prevents misunderstandings and ensures everyone's communicating effectively.
When Direct Language Actually Serves Professional Goals
Here's the counterintuitive reality: sometimes using "unprofessional" language is the most professional choice you can make. Let me explain with a real example from last year.
I was consulting with a financial services company that was considering renewing a seven-figure contract with a major cloud provider. The technical team had documented numerous issues: performance degradation, reduced support quality, mandatory migration to more expensive tiers. Their formal reports weren't getting traction with executives who saw the vendor relationship as strategic.
The lead architect finally said in an executive meeting, "I need to be direct: we're experiencing rapid enshittification of this platform, and if we renew without addressing these issues, we'll be paying more for less while our competitors move to more modern solutions." The room was shocked—then engaged. The direct language cut through months of corporate positioning and led to a genuine discussion of alternatives.
The lesson? Professionalism isn't about using the most formal language possible. It's about using language that effectively advances your professional goals. When technical teams constantly sanitize their language, they risk having their concerns sanitized out of existence.
That said, there are rules for using direct language professionally. First, establish your credibility first—don't lead with visceral language if you haven't established technical competence. Second, follow with data—the emotional language gets attention, but the data makes the case. Third, have alternatives ready—if you're criticizing a platform's direction, you should understand the competitive landscape.
The Future of Tech Terminology in 2026 and Beyond
As we look toward the rest of 2026 and beyond, I see several trends shaping how we talk about platform quality and degradation.
First, the acceleration of AI integration will likely create more need for precise language about its negative impacts. We're already seeing terms like "AI-washing" (adding AI features for marketing rather than utility) and "automation theater" (AI that appears to do something but requires more human oversight than the manual process). "Enshittification" might evolve or spawn more specific descendant terms.
Second, increased regulatory attention on platform power might professionalize some of this terminology. When the EU's Digital Services Act talks about "systemic risks" from very large online platforms, they're describing similar phenomena with legal terminology. As these concepts enter legal and regulatory frameworks, they'll inevitably influence professional vocabulary.
Third, I'm observing a broader trend toward what linguists call "semantic reclamation" in tech—taking blunt or even offensive terms and giving them precise technical meanings. This happens when communities need language that existing terminology doesn't provide. Whether "enshittification" follows this path remains to be seen, but the pattern is established.
What's clear is that as platforms continue to evolve—and often degrade—in predictable patterns, professionals will need language to describe what's happening. The question isn't whether we'll have terminology for platform degradation, but which terminology will prove most useful.
Making Your Own Call: A Framework for Decision
So back to our original question: should you use "enshittification" in professional settings? Here's my decision framework based on working with hundreds of tech professionals.
First, assess the power dynamics. If you're in a position of authority or security, you have more freedom with language. If you're early in your career or in a precarious position, err on the side of more formal terminology until you understand your organization's norms.
Second, consider the communication goal. Are you trying to build camaraderie with technical peers? The term might help. Are you documenting a pattern for future reference? More formal language might serve better. Are you escalating a critical issue that's being ignored? Direct language might be necessary.
Third, know your organization's culture. Some companies appreciate blunt talk. Others see it as unprofessional. There's no right answer that applies everywhere—the professional choice is the one that works in your specific context.
Finally, remember that terminology evolves. What feels edgy or inappropriate today might be standard professional vocabulary in a few years. The tech industry has a history of adopting vivid language that accurately describes real phenomena—think "technical debt," "bus factor," or "yak shaving." These terms started as informal metaphors before becoming professional standards.
My personal approach after two decades in tech? I use the term when it's the most accurate description available and when my audience will understand it. I don't use it for shock value or to seem edgy. And I always have more formal alternatives ready for contexts where the term wouldn't serve my professional goals.
The Bottom Line: Precision Over Propriety
After examining this from every angle—talking with sysadmins, analyzing organizational patterns, and considering the evolution of professional language—here's where I land.
The real question isn't whether "enshittification" is professional. It's whether we have language precise enough to describe the complex degradation patterns we're seeing in modern platforms. When formal terminology fails us—when "value migration" or "platform evolution" doesn't capture the specific pattern of extracting value from users to benefit shareholders—we'll naturally reach for language that does.
What makes a term professional isn't its origins or its politeness. It's whether it serves professional communication. Does it convey meaning accurately? Does it facilitate decision-making? Does it help professionals do their jobs better? By these measures, "enshittification" has already proven its professional utility in many contexts.
As we navigate 2026's increasingly complex tech landscape, with AI integration often accelerating rather than alleviating platform degradation, we need all the linguistic tools we can get. Whether you choose to use this particular tool depends on your context, your audience, and your goals. But dismissing it outright because it originated outside corporate environments would be missing the point: sometimes the most professional thing you can do is call something what it actually is.
The sysadmins and DevOps professionals dealing with daily platform degradation don't need permission to use specific terminology. They need effective ways to communicate problems and drive solutions. Sometimes that means saying "enshittification" in a board meeting. Sometimes it means writing a detailed technical analysis without a single visceral term. The professionalism is in knowing the difference—and having the courage to use the right language for the job.
