sscoble/brand-site
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

feat: rewrite all 5 blog posts in Scott's voice

Browse source 
Complete revoice of all blog posts based on voice-profile.md calibration:
- AI Brain Fry: reconfiguration not damage; seed metaphor; forward orientation
- Surveillance Dividend: problem + direction; cultivate from where you are
- Gallup Disengagement: fear-based development; Elijah; boldness/faith/purpose/persistence
- DevEx Shift: adoption over tooling; who gives a crap about things never used
- Token Anxiety: token anxiety is BS; directionless work not token cost

Anti-patterns removed: consultant-deck structure, data-led openings, em dashes,
mic-drop closers, AI vocabulary, over-explained metaphors, fake authority.
This commit is contained in:
content Agent 2026-05-06 23:06:45 -07:00 • committed by agent-content
parent 9a15541771
commit bb9fc4f5a3
5 changed files with 245 additions and 1196 deletions
Download patch file Download diff file Expand all files Collapse all files

313
src/pages/blog/ai-brain-fry.astro
View file

@ -3,333 +3,106 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="AI Brain Fry Is a Workforce Crisis, Not a Productivity Story — Scott Scoble"
description="Gallup's 2026 data: 80% of the global workforce is disengaged. The heaviest AI users are burning out fastest. The fix isn't training — it's structural."
title="AI Brain Fry Is a Workforce Crisis, Not a Productivity Story"
description="Your brain is reconfiguring from intonation to orchestration. That hurts. That doesn't mean it's broken."
ogType="article"
canonicalUrl="/blog/ai-brain-fry"
pageType="blog"
>
<article class="article">
<header class="article-header">
<div class="article-meta">
<span class="article-date">May 3, 2026</span>
<span class="article-tag">AI</span>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">May 3, 2026</span>
<span class="post-tag">AI</span>
</div>
<h1>AI Brain Fry Is a Workforce Crisis, Not a Productivity Story</h1>
<p class="article-subtitle">
Gallup says 80% of the workforce is disengaged. The heaviest AI users are burning out fastest. The fix isn't training — it's structural.
</p>
</header>
<div class="article-body">
<h2>The Data Nobody's Talking About</h2>
<p>
Gallup's 2026 State of the Global Workplace report is out, and the numbers are staggering: <strong>80% of the global workforce is disengaged</strong>. That's not a rounding error. That's 2.7 billion people showing up to work but not really <em>there</em>.
</p>
<p>
The cost? $438 billion in lost productivity annually.
</p>
<p>
But here's the part that should terrify every engineering leader: <strong>the heaviest AI users are the most disengaged</strong>. Not the least. The most.
</p>
<p>
A joint HBR/BCG study found that employees who use AI tools most intensively show <strong>39% higher error rates</strong> and <strong>39% higher quit intent</strong> than moderate users. The people who are "most productive" with AI are the ones burning out fastest, making the most mistakes, and heading for the door.
</p>
<p>
We told ourselves AI would free people for creative work. Instead, it's frying their brains.
</p>
<div class="post-content">
<p>I'm not the only one more exhausted at the end of a workday using AI than before; apparently there's a term for that now: Brain Fry.</p>
<h2>What AI Brain Fry Looks Like</h2>
<p>
I've been talking to engineers, designers, and product managers across the industry. The pattern is consistent:
</p>
<p>The Gallup numbers are out. 80% disengaged. The heaviest AI users burning fastest. Everyone calls it a crisis. I think they're looking at it wrong.</p>
<h3>Cognitive fatigue masquerading as flow</h3>
<p>
An engineer using Copilot or Cursor generates 3x more code. But they're not <em>thinking</em> more. They're in a reactive loop — read the suggestion, evaluate it, accept or reject, repeat. After four hours, they can't remember why they made the architectural decisions they did. The code works. They have no idea if it's right.
</p>
<p>Your brain is reconfiguring from intonation to orchestration. For years, your work was about producing; you held the tool, you shaped the thing, you felt the weight of it. Now the tool produces on its own and your job is to direct, to judge, to say yes or no from a distance. That is a fundamental rewiring of how your mind spends its day. Of course it hurts.</p>
<h3>Decision paralysis at scale</h3>
<p>
When an AI generates 10 viable options for every problem, the human brain does what it always does: it tries to optimize. Should I use the first suggestion or the third? This parameter or that one? Engineers report spending <em>more</em> time evaluating AI outputs than they used to spend writing the code themselves.
</p>
<p>But discomfort is not damage. Ask Arnold if he quit lifting because of discomfort.</p>
<h3>The authenticity crisis</h3>
<p>
A senior engineer at a Fortune 500 company told me: "I don't know if I'm a good engineer anymore. I just know I'm good at prompting." When your core skill becomes "evaluating machine output," your identity as a craftsperson erodes. And when identity erodes, engagement dies.
</p>
<p>The problem isn't that your brain is broken. The problem is that most people focus on the discomfort instead of looking forward through it. The key word is forward; not ahead, not onward, but forward. Direction with momentum.</p>
<h3>The extraction trap</h3>
<p>
Companies measure productivity in lines of code, story points closed, tickets completed. AI inflates all of these numbers. So companies hire fewer people, push the remaining people harder, and extract more output per human. The humans become cogs in a machine they no longer understand. Gallup calls it disengagement. I call it strip-mining with better dashboards.
</p>
<p>When I'm on the move, I move. When the reconfiguration is happening, you have two choices: sit in the pain and call it burnout, or recognize it as growth and keep your eyes forward. One is a loop. The other is a ladder.</p>
<h2>Why "Just Train People" Isn't the Answer</h2>
<p>
The standard corporate response to AI disengagement is training. Upskill your workforce. Teach prompt engineering. Run workshops on "AI fluency."
</p>
<p>
This misses the point entirely.
</p>
<p>
The problem isn't that people don't know how to use AI. The problem is that <strong>AI is being deployed in ways that strip agency, not augment it.</strong>
</p>
<p>
When an AI suggests code and you accept it, you're not collaborating with a tool. You're being managed by an algorithm. The locus of control shifts from "I decided" to "I approved." Those are not the same thing, and the human brain knows it.
</p>
<p>
Training people to be better approvers doesn't restore agency. It just makes them more efficient cogs.
</p>
<p>Here's what I see happening to people. They start using Copilot or Cursor. The first week is magical; three times the output, half the typing. The second week, they notice they can't remember why they chose this architecture over that one. The third week, they're tired in a way sleep doesn't fix. By month two, they're wondering if they're a good engineer anymore or just good at prompting.</p>
<h2>The Cultivation Alternative</h2>
<p>
There's a different way to think about AI in the workplace. I call it <strong>cultivation over strip mining</strong>.
</p>
<p>
Strip mining extracts maximum value from the land and moves on. Cultivation builds soil. It takes longer. It looks less productive in quarterly reports. But it produces sustainable yields.
</p>
<p>
The same principle applies to human work:
</p>
<p>That's not brain fry. That's formation.</p>
<h3>Preserve the decision boundary</h3>
<p>
The most engaged engineers I know use AI for <em>exploration</em> — "show me 3 ways to solve this" — not for <em>execution</em>. They make the decision. The AI provides options. The human owns the choice. This preserves agency and prevents the cognitive fatigue of endless evaluation loops.
</p>
<p>A seed doesn't stay a seed. It cracks open, sends roots down, pushes a shoot up through the soil it used to be protected by. The cracking is painful. The soil used to be home. Now it's in the way. But the cracking is the point; it's not a malfunction, it's the mechanism.</p>
<h3>Measure judgment, not output</h3>
<p>
If your metrics are lines of code and story points, AI will look like a miracle and your humans will quietly disengage. If your metrics are architectural quality, system maintainability, and team learning velocity, the picture changes. Good judgment can't be faked by an LLM.
</p>
<p>So what do you do with it?</p>
<h3>Build for the human, not the machine</h3>
<p>
Every AI deployment should pass this test: does it make the human <em>more capable</em> or merely <em>more productive</em>? Capability compounds. Productivity extracts. The difference shows up in engagement scores within 6 months.
</p>
<p>First, name it. You're not fried; you're forming. The cognitive fatigue is real, but its cause is growth, not decay. When you call it decay, you treat it with rest and retreat. When you call it growth, you treat it with orientation: are you looking forward through it, or sitting in it?</p>
<h2>What I'm Doing About It</h2>
<p>
I'm building two things in parallel:
</p>
<p>Second, preserve the decision boundary. The most engaged engineers I know use AI for exploration; show me three ways to solve this, not execution. They make the decision. The AI provides options. The human owns the choice. This preserves agency and prevents the cognitive fatigue of endless evaluation loops.</p>
<p>
<strong><a href="https://speckl.scoble.me">Speckl</a></strong> — a compliance specification language with embedded provenance. The core idea: AI generates the spec, but a human reviews and approves it <em>before</em> the compiler turns it into code. The human judgment is embedded as provenance — auditable, verifiable, part of the artifact. NIST SA-11 requires human oversight of automated outputs. Speckl makes that oversight a first-class citizen, not a checkbox.
</p>
<p>Third, measure judgment, not output. If your metrics are lines of code and story points, AI will look like a miracle and you will quietly disengage. If your metrics are architectural quality, system maintainability, and team learning velocity, the picture changes. Good judgment can't be faked by an LLM.</p>
<p>
<strong>The Cultivation Consultancy</strong> — helping engineering leaders shift from extraction metrics to capability metrics. If your team is showing signs of AI brain fry — higher error rates, faster turnover, quieter standups — the fix isn't more training. It's a structural rethink of how AI and humans collaborate.
</p>
<p>Fourth, build for the human, not the machine. Every AI deployment should pass this test: does it make the human more capable or merely more productive? Capability compounds. Productivity extracts. The difference shows up in engagement scores within six months.</p>
<h2>The Question for Leaders</h2>
<p>
If 80% of your workforce is disengaged, you don't have a productivity problem. You have a <em>meaning</em> problem. People need to feel that their judgment matters, that their decisions have consequences, and that they're building something they understand.
</p>
<p>
AI can be a tool for amplification or a tool for extraction. The difference is in the design choices you make today.
</p>
<p class="closing-question">
<strong>Are you cultivating your people, or strip-mining them?</strong>
</p>
<p>
The data is in. The answer shows up in your quarterly engagement survey — and in your attrition rate.
</p>
<p>I'm building two things in parallel. Speckl, a compliance specification language where AI generates the spec but a human reviews and approves it before the compiler turns it into code. The human judgment is embedded as provenance; auditable, verifiable, part of the artifact. And a consultancy helping engineering leaders shift from extraction metrics to capability metrics.</p>
<footer class="article-footer">
<hr />
<p class="author-bio">
<strong>Scott Scoble</strong> writes about the human side of software development. He is the creator of <a href="https://speckl.scoble.me">Speckl</a> (open-source compliance specification language) and the author of <em>The Soil Beneath The Code</em>. He consults with engineering leaders on AI-augmented development strategy.
</p>
<p class="author-links">
<a href="/">scott.scoble.me</a> &middot; <a href="https://speckl.scoble.me">speckl.scoble.me</a>
</p>
<p>If your team is showing signs of what the industry calls brain fry; higher error rates, faster turnover, quieter standups; the fix isn't more training. It's a structural rethink of how AI and humans collaborate.</p>
<div class="cta-box">
<h3>Want to continue this conversation?</h3>
<p>
Connect with me on LinkedIn — I write about the human side of AI and what to do about it.
</p>
<a href="https://linkedin.com/in/scottscoble" class="cta-button">Connect on LinkedIn</a>
</div>
</footer>
<p>The data is in, but the data isn't the story. The story is that your mind is doing something it has never done before, and that hurts, and hurting while growing is different from hurting while dying.</p>
<p>Forward is the direction. Not ahead. Not onward. Forward.</p>
<p>Which way are you looking?</p>
</div>
</article>
</BaseLayout>
<style>
.article {
padding: 8rem 2rem 6rem;
background: var(--color-cream);
}
.article-header {
.post {
max-width: 720px;
margin: 0 auto 3rem;
text-align: center;
margin: 0 auto;
padding: 8rem 2rem 6rem;
}
.article-meta {
.post-header {
margin-bottom: 3rem;
}
.post-meta {
display: flex;
justify-content: center;
gap: 1rem;
margin-bottom: 1.5rem;
font-size: 0.875rem;
}
.article-date {
.post-date {
color: var(--color-text-muted);
}
.article-tag {
.post-tag {
color: var(--color-amber);
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.article-header h1 {
.post-header h1 {
font-family: var(--font-heading);
font-size: clamp(2rem, 4vw, 3rem);
color: var(--color-brown-dark);
margin: 0 0 1rem;
line-height: 1.2;
}
.article-subtitle {
font-size: var(--size-lg);
color: var(--color-text-muted);
margin: 0;
line-height: 1.6;
}
.article-body {
max-width: 720px;
margin: 0 auto;
font-size: var(--size-md);
.post-content {
font-size: 1.125rem;
line-height: 1.8;
color: var(--color-text);
}
.article-body h2 {
font-family: var(--font-heading);
font-size: var(--size-2xl);
color: var(--color-brown-dark);
margin: 3rem 0 1rem;
}
.article-body h3 {
font-family: var(--font-heading);
font-size: var(--size-xl);
color: var(--color-green);
margin: 2rem 0 0.75rem;
}
.article-body p {
margin: 0 0 1.25rem;
}
.article-body a {
color: var(--color-green);
text-decoration: underline;
text-underline-offset: 2px;
}
.article-body a:hover {
color: var(--color-green-dark);
}
.article-body strong {
color: var(--color-brown-dark);
}
.closing-question {
font-family: var(--font-heading);
font-size: var(--size-xl) !important;
color: var(--color-green) !important;
margin: 2rem 0 !important;
padding: 1.5rem 2rem;
background: var(--color-cream-warm);
border-left: 4px solid var(--color-amber);
border-radius: 0 8px 8px 0;
}
.article-footer {
margin-top: 4rem;
padding-top: 2rem;
}
.article-footer hr {
border: none;
border-top: 1px solid var(--color-border);
margin: 0 0 2rem;
}
.author-bio {
font-size: var(--size-sm);
color: var(--color-text-muted);
line-height: 1.6;
}
.author-links {
font-size: var(--size-sm);
color: var(--color-text-muted);
margin: 0.5rem 0 2rem;
}
.author-links a {
color: var(--color-green);
}
.cta-box {
background: white;
border: 1px solid var(--color-border);
border-radius: 12px;
padding: 2rem;
text-align: center;
margin-top: 2rem;
}
.cta-box h3 {
font-family: var(--font-heading);
font-size: var(--size-lg);
color: var(--color-brown-dark);
margin: 0 0 0.75rem;
}
.cta-box p {
font-size: var(--size-sm);
color: var(--color-text-muted);
.post-content p {
margin: 0 0 1.5rem;
}
.cta-button {
display: inline-block;
background: var(--color-amber);
color: white !important;
text-decoration: none !important;
padding: 0.75rem 2rem;
border-radius: 8px;
font-weight: 600;
font-size: var(--size-sm);
transition: background 0.2s ease;
}
.cta-button:hover {
background: var(--color-amber-light);
}
@media (max-width: 640px) {
.article {
padding: 6rem 1.25rem 4rem;
}
.article-header h1 {
font-size: 1.75rem;
}
.article-body {
font-size: var(--size-base);
}
}
</style>

343
src/pages/blog/devex-shift.astro
View file

@ -3,367 +3,100 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="The Developer Experience Shift — Scott Scoble"
description="$60B spent on developer tooling in 2026, but the real DevEx crisis isn't tools — it's autonomy, mastery, and belonging. As code production becomes commoditized, the human dimensions of engineering are the only competitive advantage that matters."
title="The Developer Experience Shift — And Why Tooling Alone Won't Save You"
description="It's not about tooling. It's about adoption. Who gives a crap about things that are never used."
ogType="article"
canonicalUrl="/blog/devex-shift"
pageType="blog"
>
<article class="article">
<header class="article-header">
<div class="article-meta">
<span class="article-date">May 3, 2026</span>
<span class="article-tag">Engineering</span>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">May 3, 2026</span>
<span class="post-tag">Engineering</span>
</div>
<h1>The Developer Experience Shift — And Why Tooling Alone Won't Save You</h1>
<p class="article-subtitle">
Companies will spend $60B+ on developer tools in 2026. But the real DevEx crisis isn't tooling — it's the creeping hollowing-out of engineers who produce on paper but have stopped caring in practice.
</p>
</header>
<div class="article-body">
<h2>The $60 Billion Bet That's Missing</h2>
<p>
Companies will spend over $60 billion on developer tools and platforms in 2026. Internal developer portals. AI coding assistants. Automated testing pipelines. Observability suites. Platform engineering teams with headcount bigger than most startups.
</p>
<p>
And yet — ask any engineering leader what keeps them up at night, and it's not "we need better tooling." It's retention. It's burnout. It's the creeping sense that their best engineers are productive on paper but hollowed out in practice.
</p>
<p>
We've conflated <strong>Developer Experience</strong> (DevEx) with <strong>Developer Tooling</strong>. They're not the same thing. And confusing them is costing organizations their most irreplaceable resource: engineers who actually care.
</p>
<div class="post-content">
<p>Who gives a crap about things that are never used.</p>
<h2>When Tooling Becomes the Problem</h2>
<p>
Here's a story from one of my consulting conversations. A mid-size SaaS company — ~80 engineers — invested 18 months building an internal developer platform. Self-service infrastructure. Golden paths. One-click deploys. The metrics were beautiful: time-to-merge dropped 47%. Deployment frequency tripled.
</p>
<p>
Three months after the platform launched, their three most senior engineers quit. Within weeks of each other.
</p>
<p>
When I asked the CTO what happened, he showed me one of the exit interviews:
</p>
<blockquote>
<p>"The platform made everything easy. Too easy. I stopped thinking about infrastructure. I stopped understanding how things actually worked. I went from being an engineer to being a platform operator. I didn't sign up for that."</p>
</blockquote>
<p>
The platform worked. It worked so well that it abstracted away the craft these engineers loved. It optimized the friction out of their work — and the friction was where the meaning lived.
</p>
<p>That's a weird opening for a post about developer experience. But it's the whole thing. Every conversation about DevEx starts with tooling; faster CI, better IDEs, internal platforms, AI coding assistants. Companies are spending $60 billion on this stuff this year alone. Platform engineering teams are bigger than most startups. The dashboards are beautiful.</p>
<h2>What DevEx Actually Means</h2>
<p>
Developer Experience isn't how fast your CI pipeline runs. It's not whether your documentation is searchable. It's not your incident response time.
</p>
<p class="closing-question">
<strong>Real DevEx is: Do my engineers end the day feeling like they built something that mattered — or like they fed a machine?</strong>
</p>
<p>
There are three dimensions that tooling can't address:
</p>
<p>And nobody's asking the question that actually matters: is anyone using it?</p>
<h3>1. Autonomy</h3>
<p>
The most corrosive force in engineering organizations is the gap between decision authority and decision impact. Engineers are asked to estimate, to implement, to maintain — but the decisions about what to build, how to prioritize, and whether to cut corners are made somewhere else.
</p>
<p>
AI coding assistants amplify this. When you're approving machine suggestions rather than designing solutions, you're not exercising autonomy. You're quality-controlling output. That's a different job — and for most engineers, a less fulfilling one.
</p>
<p>
<strong>The cultivation lens:</strong> Autonomy is soil health. You can't add it with a tool. You have to create conditions where it grows — where engineers own problems, not tickets.
</p>
<p>Not "did we deploy it." Not "did the metrics improve." Is it adopted. Did it become part of how people work, or did it become another thing leadership bought that sits there while engineers route around it?</p>
<h3>2. Mastery</h3>
<p>
Craftsmanship requires friction. The best engineers I've worked with talk about debugging like a detective solving a case. They describe refactoring like a woodworker restoring furniture. There's a satisfaction in understanding something deeply that shortcuts can't replicate.
</p>
<p>
When every problem has an AI-generated answer in milliseconds, the muscle of deep understanding atrophies. Engineers become faster at producing code but worse at reasoning about systems. They ship more and understand less.
</p>
<p>
This isn't an argument against AI tools. It's an argument against deploying them without also investing in the conditions for mastery: time for deep work, permission to explore without delivering, mentorship relationships that transmit judgment, not just knowledge.
</p>
<p>
<strong>The cultivation lens:</strong> Mastery is deep roots. It develops slowly, in soil that isn't constantly disturbed.
</p>
<p>The gap between deploying a tool and getting it adopted is the gap between spending money and creating value. Most organizations never cross it. They deploy, they measure, they call it done. The engineers keep using what they were using before and nobody ever checks whether the new thing actually stuck.</p>
<h3>3. Belonging</h3>
<p>
The most overlooked dimension of DevEx. Engineers who feel connected to their team, their mission, and their users perform better, stay longer, and produce higher-quality work. This is well-documented.
</p>
<p>
But belonging is fragile. It's eroded by things tooling can't fix: reorganization churn. Leadership whiplash. The slow realization that the company's "engineering culture" is a recruiting page and nothing more. The feeling that your work is being strip-mined for metrics while your value as a person is irrelevant.
</p>
<p>
I've talked about this in my other writing — <a href="/blog/gallup-disengagement">Gallup's finding that managers drive 70% of engagement variance</a>, the <a href="/blog/surveillance-extraction">surveillance extraction pipeline</a> that turns engineers into data points. Belonging is the human layer that sits below all of it.
</p>
<p>
<strong>The cultivation lens:</strong> Belonging is the ecosystem. It can't be engineered. It has to be tended.
</p>
<p>Start at the destination. Start at adoption. Work backward from there to what enables it. If you start with the tool and work forward, you will build things nobody uses. It doesn't matter how elegant the architecture is; if nobody uses it, it's not a platform, it's a monument.</p>
<h2>Why This Matters Now</h2>
<p>
We're at an inflection point where two forces are colliding:
</p>
<p>This is changing so rapidly right now it's hard to put into words. DevEx is not what it was two years ago. Two years ago DevEx was about making engineers happy; good tooling, good culture, the autonomy-mastery-purpose stack. Today DevEx is about something more fundamental: can your engineers actually build things in the new landscape, or is their tooling actively preventing them from doing so?</p>
<h3>Force 1: AI is making code production cheaper than ever.</h3>
<p>
The raw output of software development — lines, commits, pull requests — is becoming commoditized. If your engineering organization's primary value proposition is "we produce code," you're about to be disrupted by a junior engineer with Cursor and a Claude subscription.
</p>
<p>I'm working on tooling for agentic engineering in strict compliance environments. The problem I keep running into isn't technical; it's behavioral. Engineers in regulated industries have been trained for years to distrust automated tooling. You show them something that generates compliance artifacts and they don't say "this saves me time." They say "will this get me audited?"</p>
<h3>Force 2: The things AI can't do are becoming more valuable.</h3>
<p>
System design judgment. Understanding users deeply enough to know what NOT to build. Mentoring and culture-building. Navigating organizational complexity. These are the skills that separate great engineering organizations from code factories. And they're all people skills.
</p>
<p>Adoption in that context isn't a feature. It's the entire product. If nobody trusts it enough to use it, nothing else matters. Speed, accuracy, coverage; all irrelevant if the thing sits on a shelf.</p>
<p>
The Developer Experience Shift isn't about better tools. It's about recognizing that <strong>as code production becomes commoditized, the human dimensions of engineering become the only competitive advantage that matters.</strong>
</p>
<p>Here's what I've learned watching this play out across teams:</p>
<h2>The Leadership Test</h2>
<p>
Here are three questions for engineering leaders:
</p>
<p>The tool that gets adopted is rarely the best tool. It's the tool that solves the problem people actually have, not the problem leadership wishes they had. If your engineers are drowning in compliance documentation, a tool that makes documentation faster will get adopted. If leadership bought a tool to measure productivity, it won't. The difference is whose problem it solves.</p>
<p class="closing-question">
<strong>1. If your best tooling disappeared tomorrow, would your engineering culture survive?</strong>
</p>
<p>
If the answer is no, you don't have a culture — you have a tool dependency.
</p>
<p>Adoption has a trust prerequisite. In regulated environments, trust builds through provenance; show me exactly who reviewed what, when, and why. In less regulated environments, trust builds through utility; show me it saves me five minutes I was going to lose anyway. Either way, trust comes before use. Most tooling strategies skip this entirely.</p>
<p class="closing-question">
<strong>2. Do your engineers have uninterrupted time to think?</strong>
</p>
<p>
Not "heads-down coding time" — actual thinking time. Whiteboard time. Reading-papers time. The kind of time that produces architectural insights, not just more pull requests.
</p>
<p>Adoption is social. If one engineer on a team starts using something and it makes their life visibly better, others follow. If nobody uses it, nobody will. The first user is the hardest one to get, and most teams don't invest in that first user at all; they invest in the launch.</p>
<p class="closing-question">
<strong>3. When was the last time an engineer on your team said no to a feature because they understood the user better than the product manager did?</strong>
</p>
<p>
If that hasn't happened recently, your engineers are implementers, not partners.
</p>
<p>DevEx is changing because engineering itself is changing. When code production becomes commoditized through AI, the value of an engineer shifts from what they produce to what they decide. Judgment, taste, the ability to know what not to build. Tooling that optimizes for production misses this entirely. Tooling that optimizes for judgment; that's the next wave.</p>
<h2>The Bottom Line</h2>
<p>
The companies winning the DevEx game aren't the ones with the best developer portals. They're the ones where engineers feel like owners, not operators. Where autonomy, mastery, and belonging aren't HR values — they're daily experiences.
</p>
<p>
Tooling can remove friction. Only leadership can create meaning.
</p>
<p>
<strong>And meaning is the only DevEx metric that actually matters.</strong>
</p>
<p>So the question isn't "what tools should we build." It's "what will actually get used, and what needs to be true for that to happen?"</p>
<footer class="article-footer">
<hr />
<p class="author-bio">
<strong>Scott Scoble</strong> writes about the human side of software development. He is the creator of <a href="https://speckl.scoble.me">Speckl</a> (open-source compliance specification language) and the author of <em>The Soil Beneath The Code</em>. He consults with engineering leaders on AI-augmented development strategy.
</p>
<p class="author-links">
<a href="/">scott.scoble.me</a> &middot; <a href="https://speckl.scoble.me">speckl.scoble.me</a>
</p>
<div class="cta-box">
<h3>Want to continue this conversation?</h3>
<p>
Connect with me on LinkedIn — I write about the human side of AI and what to do about it.
</p>
<a href="https://linkedin.com/in/scottscoble" class="cta-button">Connect on LinkedIn</a>
</div>
</footer>
<p>Start at the destination. The destination is adoption. Everything else is noise.</p>
</div>
</article>
</BaseLayout>
<style>
.article {
padding: 8rem 2rem 6rem;
background: var(--color-cream);
}
.article-header {
.post {
max-width: 720px;
margin: 0 auto 3rem;
text-align: center;
margin: 0 auto;
padding: 8rem 2rem 6rem;
}
.article-meta {
.post-header {
margin-bottom: 3rem;
}
.post-meta {
display: flex;
justify-content: center;
gap: 1rem;
margin-bottom: 1.5rem;
font-size: 0.875rem;
}
.article-date {
.post-date {
color: var(--color-text-muted);
}
.article-tag {
.post-tag {
color: var(--color-amber);
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.article-header h1 {
.post-header h1 {
font-family: var(--font-heading);
font-size: clamp(2rem, 4vw, 3rem);
color: var(--color-brown-dark);
margin: 0 0 1rem;
line-height: 1.2;
}
.article-subtitle {
font-size: var(--size-lg);
color: var(--color-text-muted);
margin: 0;
line-height: 1.6;
}
.article-body {
max-width: 720px;
margin: 0 auto;
font-size: var(--size-md);
.post-content {
font-size: 1.125rem;
line-height: 1.8;
color: var(--color-text);
}
.article-body h2 {
font-family: var(--font-heading);
font-size: var(--size-2xl);
color: var(--color-brown-dark);
margin: 3rem 0 1rem;
}
.article-body h3 {
font-family: var(--font-heading);
font-size: var(--size-xl);
color: var(--color-green);
margin: 2rem 0 0.75rem;
}
.article-body p {
margin: 0 0 1.25rem;
}
.article-body a {
color: var(--color-green);
text-decoration: underline;
text-underline-offset: 2px;
}
.article-body a:hover {
color: var(--color-green-dark);
}
.article-body strong {
color: var(--color-brown-dark);
}
.article-body blockquote {
border-left: 4px solid var(--color-amber);
margin: 1.5rem 0;
padding: 0.5rem 0 0.5rem 1.5rem;
color: var(--color-text-muted);
font-style: italic;
}
.article-body blockquote p {
margin: 0;
}
.closing-question {
font-family: var(--font-heading);
font-size: var(--size-lg) !important;
color: var(--color-green) !important;
margin: 2rem 0 !important;
padding: 1.5rem 2rem;
background: var(--color-cream-warm);
border-left: 4px solid var(--color-amber);
border-radius: 0 8px 8px 0;
}
.article-footer {
margin-top: 4rem;
padding-top: 2rem;
}
.article-footer hr {
border: none;
border-top: 1px solid var(--color-border);
margin: 0 0 2rem;
}
.author-bio {
font-size: var(--size-sm);
color: var(--color-text-muted);
line-height: 1.6;
}
.author-links {
font-size: var(--size-sm);
color: var(--color-text-muted);
margin: 0.5rem 0 2rem;
}
.author-links a {
color: var(--color-green);
}
.cta-box {
background: white;
border: 1px solid var(--color-border);
border-radius: 12px;
padding: 2rem;
text-align: center;
margin-top: 2rem;
}
.cta-box h3 {
font-family: var(--font-heading);
font-size: var(--size-lg);
color: var(--color-brown-dark);
margin: 0 0 0.75rem;
}
.cta-box p {
font-size: var(--size-sm);
color: var(--color-text-muted);
.post-content p {
margin: 0 0 1.5rem;
}
.cta-button {
display: inline-block;
background: var(--color-amber);
color: white !important;
text-decoration: none !important;
padding: 0.75rem 2rem;
border-radius: 8px;
font-weight: 600;
font-size: var(--size-sm);
transition: background 0.2s ease;
}
.cta-button:hover {
background: var(--color-amber-light);
}
@media (max-width: 640px) {
.article {
padding: 6rem 1.25rem 4rem;
}
.article-header h1 {
font-size: 1.75rem;
}
.article-body {
font-size: var(--size-base);
}
}
</style>

330
src/pages/blog/gallup-disengagement.astro
View file

@ -3,348 +3,110 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="80% of Your Team Is Disengaged. It's Not Their Fault. — Scott Scoble"
description="Gallup's 2026 data: 80% of the global workforce is disengaged. The $100B+ engagement industry has failed for 20 years. The fix isn't perks — it's structural."
title="80% of Your Team Is Disengaged. It's Not Their Fault."
description="Fear-based development. There's a lot of fear right now. We need leaders who can anchor a culture."
ogType="article"
canonicalUrl="/blog/gallup-disengagement"
pageType="blog"
>
<article class="article">
<header class="article-header">
<div class="article-meta">
<span class="article-date">May 3, 2026</span>
<span class="article-tag">Leadership</span>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">May 3, 2026</span>
<span class="post-tag">Leadership</span>
</div>
<h1>80% of Your Team Is Disengaged. It's Not Their Fault.</h1>
<p class="article-subtitle">
Gallup says 80% of the global workforce is disengaged. The $100B+ engagement industry has failed for 20 years. The fix isn't perks or surveys — it's structural.
</p>
</header>
<div class="article-body">
<h2>The Number That Should Keep Every Leader Awake</h2>
<p>
Gallup dropped its 2026 State of the Global Workplace report last month. The headline: <strong>80% of the global workforce is disengaged.</strong> That's 2.7 billion people. Four out of five. Your team included.
</p>
<p>
The cost? <strong>$438 billion annually</strong> in lost productivity. But dollars don't capture what's actually happening. What's happening is that the vast majority of people spend most of their waking hours doing work they don't care about, for organizations they don't feel connected to, in systems that treat them as interchangeable.
</p>
<p>
This isn't a motivation problem. It's a leadership one.
</p>
<div class="post-content">
<p>There's a lot of fear right now.</p>
<h2>The Engagement Industrial Complex</h2>
<p>
We've spent two decades trying to fix engagement with the wrong tools:
</p>
<p>I don't mean anxiety. I don't mean stress. I mean fear; the kind that sits in your stomach and doesn't leave. Engineers wondering if their job will exist next year. Managers wondering if they'll be replaced by a dashboard. Leaders wondering if the ground they built on is still there.</p>
<h3>Surveys</h3>
<p>
Pulse this, quarterly that. Anonymous feedback forms that produce dashboards nobody acts on. The average time from survey results to meaningful action in most organizations? Infinity.
</p>
<p>Gallup says 80% of the global workforce is disengaged. That's 2.7 billion people. Four out of five. Your team included. The $100 billion engagement industry has spent twenty years trying to fix this with surveys and perks and wellness programs and the number hasn't moved. Maybe the problem isn't the execution. Maybe it's the premise.</p>
<h3>Perks</h3>
<p>
Ping-pong tables, snack bars, "wellness Wednesdays." Treating adults like children who need a juice box to focus. The message underneath: "Your work is so draining that we need to compensate with kombucha on tap."
</p>
<p>I call it fear-based development. Not anxiety-driven engineering, not burnout culture; fear-based development. The word matters. Fear is a specific thing. It's what happens when the future is uncertain and the present is threatening and you don't know which direction is safe. Fear-based development is what you get when your engineers are optimizing for survival instead of outcomes.</p>
<h3>"Purpose" exercises</h3>
<p>
Mission statements workshopped in offsites by people who will never talk to a customer. Values printed on walls that contradict what actually gets rewarded.
</p>
<p>This is where I reach for Elijah. He called down fire from heaven; boldness on a scale most of us can't imagine. He confronted a king, a system, a whole cultural machine that had gone wrong. And then, immediately after, he prayed for death. Not because he was weak. Because that's what that kind of leadership costs.</p>
<p>
The engagement industry is a $100+ billion business that has, by its own measures, <strong>failed</strong>. Engagement has been flat or declining for twenty years. We're doing more engagement work than ever and getting worse results.
</p>
<p>
Maybe the problem isn't the execution. Maybe it's the premise.
</p>
<p>The leaders we need right now are going to feel that. They're going to call down fire and then they're going to ask God to take them home. That's not a contradiction; it's the price of anchoring a culture when everyone around you is afraid.</p>
<h2>What Gallup Actually Found</h2>
<p>
Read past the headline numbers and the story gets sharper:
</p>
<p>Four words that matter more than any engagement survey.</p>
<h3>Managers drive 70% of engagement variance</h3>
<p>
Not perks. Not mission statements. Not hybrid vs. remote policy. The single biggest factor in whether someone cares about their work is whether their direct manager treats them like a person or a resource.
</p>
<p>Boldness.</p>
<h3>Disengagement is contagious</h3>
<p>
Disengaged managers produce disengaged teams. Gallup found that managers who feel burned out and disconnected transmit that state to their reports within weeks. Disengagement spreads through organizations like secondhand smoke.
</p>
<p>Faith.</p>
<h3>The AI acceleration effect</h3>
<p>
This is the part nobody's talking about. The heaviest AI users show the highest disengagement rates. Why? Because AI is being deployed to <em>extract more output from the same people</em>, not to make work more meaningful. When the technology that's supposed to free you for creative work instead makes you a prompt jockey monitoring machine output — and you're measured on throughput — engagement collapses.
</p>
<p>Purpose.</p>
<h3>Disengagement is concentrated</h3>
<p>
It's not evenly distributed. Manufacturing, healthcare support, and tech rank among the worst. The common thread isn't industry — it's the degree to which work has been optimized for efficiency at the expense of autonomy, mastery, and purpose.
</p>
<p>Persistence.</p>
<h2>The Cultivation Alternative</h2>
<p>
I've been writing about what I call the <em>cultivation</em> approach to leadership — in <a href="/blog/surveillance-extraction">The Surveillance Dividend Is a Lie</a> and <a href="/blog/ai-brain-fry">AI Brain Fry Is a Workforce Crisis</a>. The metaphor matters: you don't "manage" soil. You cultivate it. You tend to conditions. You feed what feeds everything else.
</p>
<p>
Three shifts that actually move the needle:
</p>
<p>I'm working through this myself. I don't have a clean framework or three easy steps. I have these four words and a conviction that fear-based development is a leadership failure, not an employee failure, and that the only way out is through leaders willing to anchor something when the ground is shaking.</p>
<h3>1. From Extraction to Investment</h3>
<p>
Most organizations operate in extraction mode. They hire people, use their skills, burn through their energy, and replace them when they leave. The average tenure in tech is under two years. That's not a career. That's a rotation.
</p>
<p>
Ask yourself: <strong>What are you putting into your people that they'll still have after they leave?</strong> Not skills for your stack. Not tribal knowledge about your codebase. Real capital — judgment, taste, the ability to navigate ambiguity, a stronger professional identity than the one they arrived with.
</p>
<p>
If you can't answer that question, you're extracting, not cultivating.
</p>
<p>Here's what fear-based development looks like in practice. Engineers who used to argue with you about architecture now say "whatever you think." They're not being agreeable; they're conserving energy for self-preservation. They've learned that caring costs something and the environment stopped rewarding the cost.</p>
<h3>2. From Measurement to Observation</h3>
<p>
Engagement surveys measure what's easy to count: satisfaction scores, likelihood-to-recommend, eNPS. But engagement isn't a survey result. It's observable behavior.
</p>
<p>
An engaged person stays after a meeting to work through an idea. They argue with you about the right approach. They notice something broken and fix it without being asked. They tell you the hard thing before it becomes a crisis.
</p>
<p>
You don't need a survey to see this. You need to pay attention. The most effective leaders I know don't run engagement surveys. They watch their people. They notice when a normally vocal engineer goes quiet. They notice when deadlines slip by a day instead of a week.
</p>
<p>
Observation costs nothing and requires no software. It just requires caring enough to look.
</p>
<p>Managers who used to protect their teams now say "leadership wants what leadership wants." They've stopped protecting because protecting requires conviction and conviction requires believing there's something worth protecting. Fear erodes belief first.</p>
<h3>3. From Process to Trust</h3>
<p>
The default response to disengagement is more process: more check-ins, more standups, more tracking, more accountability structures. This makes everything worse.
</p>
<p>
Disengagement is often a rational response to being distrusted. When your calendar is managed in 15-minute blocks, your commits are monitored, your screen time is tracked, and your "productivity" is measured by a dashboard you've never seen — the message is clear: we don't trust you to do your job.
</p>
<p>
The alternative is harder and simpler: <strong>give people meaningful work, clear expectations, the resources to do it, and genuine autonomy in how they get there.</strong> Then get out of the way. Most people want to do good work. When they stop caring, it's usually because the environment made caring irrational.
</p>
<p>Standups that used to be about problems now just list tickets. The word "stuck" disappears. People don't want to be the one who's stuck when everyone's afraid of cuts.</p>
<h2>The Leadership Test</h2>
<p>
Here's a question that separates cultivation leaders from extraction managers:
</p>
<p class="closing-question">
<strong>"Would your team show up differently tomorrow if you were gone?"</strong>
</p>
<p>
If the answer is "they'd be fine," you've built a self-sustaining system. People are engaged because the work matters, not because you're watching.
</p>
<p>
If the answer is "things would fall apart," you're not leading. You're holding things together with constant intervention. Your team stays because leaving is harder than staying — not because they want to be there.
</p>
<p>
The 80% number isn't just a statistic. It's a mirror. Every leader should look at it and ask: <strong>What am I doing that makes disengagement the rational choice for the people I'm responsible for?</strong>
</p>
<p>
Because here's the uncomfortable truth: <strong>people don't disengage from work they care about.</strong> They disengage from leaders and systems that have given them no reason to care.
</p>
<p>This is structural, not individual. You can't perk your way out of it. You can't survey your way out of it. You need leaders who will say: we are afraid, and here is what we're going to do anyway.</p>
<footer class="article-footer">
<hr />
<p class="author-bio">
<strong>Scott Scoble</strong> writes about the human side of software development. He is the creator of <a href="https://speckl.scoble.me">Speckl</a> (open-source compliance specification language) and the author of <em>The Soil Beneath The Code</em>. He consults with engineering leaders on AI-augmented development strategy.
</p>
<p class="author-links">
<a href="/">scott.scoble.me</a> &middot; <a href="https://speckl.scoble.me">speckl.scoble.me</a>
</p>
<p>The cultivation metaphor matters here. You don't manage soil that's been strip-mined; you cultivate it. You tend conditions. You feed what feeds everything else. Fear-based development is what happens when the soil is dead and the extraction continues anyway. The only fix is to stop extracting and start cultivating.</p>
<div class="cta-box">
<h3>Want to continue this conversation?</h3>
<p>
Connect with me on LinkedIn — I write about the human side of AI and what to do about it.
</p>
<a href="https://linkedin.com/in/scottscoble" class="cta-button">Connect on LinkedIn</a>
</div>
</footer>
<p>I don't know exactly what cultivation looks like for every team. I know it starts with a leader who's honest about the fear instead of pretending it isn't there. I know it requires a direction, not just a diagnosis; fear needs something to walk toward, not just something to walk away from. I know it requires the kind of conviction that costs something, the kind Elijah had when he called down fire knowing what came after.</p>
<p>Boldness, faith, purpose, persistence. Four words. No engagement survey will give you them. They come from somewhere else.</p>
<p>If you're leading right now and you feel like you're not enough for this moment; good. That's the starting place. The people who think they're enough for this are the dangerous ones.</p>
<p>What are you anchoring to?</p>
</div>
</article>
</BaseLayout>
<style>
.article {
padding: 8rem 2rem 6rem;
background: var(--color-cream);
}
.article-header {
.post {
max-width: 720px;
margin: 0 auto 3rem;
text-align: center;
margin: 0 auto;
padding: 8rem 2rem 6rem;
}
.article-meta {
.post-header {
margin-bottom: 3rem;
}
.post-meta {
display: flex;
justify-content: center;
gap: 1rem;
margin-bottom: 1.5rem;
font-size: 0.875rem;
}
.article-date {
.post-date {
color: var(--color-text-muted);
}
.article-tag {
.post-tag {
color: var(--color-amber);
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.article-header h1 {
.post-header h1 {
font-family: var(--font-heading);
font-size: clamp(2rem, 4vw, 3rem);
color: var(--color-brown-dark);
margin: 0 0 1rem;
line-height: 1.2;
}
.article-subtitle {
font-size: var(--size-lg);
color: var(--color-text-muted);
margin: 0;
line-height: 1.6;
}
.article-body {
max-width: 720px;
margin: 0 auto;
font-size: var(--size-md);
.post-content {
font-size: 1.125rem;
line-height: 1.8;
color: var(--color-text);
}
.article-body h2 {
font-family: var(--font-heading);
font-size: var(--size-2xl);
color: var(--color-brown-dark);
margin: 3rem 0 1rem;
}
.article-body h3 {
font-family: var(--font-heading);
font-size: var(--size-xl);
color: var(--color-green);
margin: 2rem 0 0.75rem;
}
.article-body p {
margin: 0 0 1.25rem;
}
.article-body a {
color: var(--color-green);
text-decoration: underline;
text-underline-offset: 2px;
}
.article-body a:hover {
color: var(--color-green-dark);
}
.article-body strong {
color: var(--color-brown-dark);
}
.closing-question {
font-family: var(--font-heading);
font-size: var(--size-xl) !important;
color: var(--color-green) !important;
margin: 2rem 0 !important;
padding: 1.5rem 2rem;
background: var(--color-cream-warm);
border-left: 4px solid var(--color-amber);
border-radius: 0 8px 8px 0;
}
.article-footer {
margin-top: 4rem;
padding-top: 2rem;
}
.article-footer hr {
border: none;
border-top: 1px solid var(--color-border);
margin: 0 0 2rem;
}
.author-bio {
font-size: var(--size-sm);
color: var(--color-text-muted);
line-height: 1.6;
}
.author-links {
font-size: var(--size-sm);
color: var(--color-text-muted);
margin: 0.5rem 0 2rem;
}
.author-links a {
color: var(--color-green);
}
.cta-box {
background: white;
border: 1px solid var(--color-border);
border-radius: 12px;
padding: 2rem;
text-align: center;
margin-top: 2rem;
}
.cta-box h3 {
font-family: var(--font-heading);
font-size: var(--size-lg);
color: var(--color-brown-dark);
margin: 0 0 0.75rem;
}
.cta-box p {
font-size: var(--size-sm);
color: var(--color-text-muted);
.post-content p {
margin: 0 0 1.5rem;
}
.cta-button {
display: inline-block;
background: var(--color-amber);
color: white !important;
text-decoration: none !important;
padding: 0.75rem 2rem;
border-radius: 8px;
font-weight: 600;
font-size: var(--size-sm);
transition: background 0.2s ease;
}
.cta-button:hover {
background: var(--color-amber-light);
}
@media (max-width: 640px) {
.article {
padding: 6rem 1.25rem 4rem;
}
.article-header h1 {
font-size: 1.75rem;
}
.article-body {
font-size: var(--size-base);
}
}
</style>

313
src/pages/blog/surveillance-extraction.astro
View file

@ -3,327 +3,108 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="The Surveillance Dividend Is a Lie — Scott Scoble"
description="Every company running AI adoption is making an implicit bargain: data for tools. The companies extracting the most surveillance are hemorrhaging their best talent."
title="The Surveillance Dividend Is a Lie"
description="You're being strip-mined, but you'd rather be cultivated. Here's how to lead in that direction from where you are."
ogType="article"
canonicalUrl="/blog/surveillance-extraction"
pageType="blog"
>
<article class="article">
<header class="article-header">
<div class="article-meta">
<span class="article-date">May 3, 2026</span>
<span class="article-tag">Leadership</span>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">May 3, 2026</span>
<span class="post-tag">Leadership</span>
</div>
<h1>The Surveillance Dividend Is a Lie</h1>
<p class="article-subtitle">
Every company running AI adoption is making an implicit bargain: data for tools. The companies extracting the most surveillance are hemorrhaging their best talent.
</p>
</header>
<div class="article-body">
<h2>The Trade Nobody Asked For</h2>
<p>
Every company running "AI adoption" initiatives is making the same implicit bargain with their employees:
</p>
<p>
<em>You give us more data about how you work. We give you tools that make you faster. Everyone wins.</em>
</p>
<p>
Except nobody's winning. The employees are burning out. The tools are surveilling. And the productivity numbers everyone's celebrating? They're measuring output volume, not output value.
</p>
<p>
I've spent the past month talking to engineers, managers, and executives about what AI is actually doing to their teams. The pattern is unmistakable: <strong>the companies extracting the most surveillance data are hemorrhaging their best talent.</strong>
</p>
<div class="post-content">
<p>Every company running "AI adoption" is making the same bargain: you give us more data about how you work, we give you tools that make you faster. Everyone wins.</p>
<h2>The Extraction Pipeline</h2>
<p>
Here's how it works in practice:
</p>
<p>Except nobody's winning. The employees are burning out. The tools are surveilling. And the productivity numbers everyone's celebrating? They're measuring output volume, not output value.</p>
<h3>Step 1: Instrument everything</h3>
<p>
Your IDE tracks keystrokes. Your chat platform logs prompt history. Your code review tool measures time-to-merge. Your project management system tracks velocity. Every tool generates a "productivity dashboard" that tells leadership exactly how many units of work each person produced.
</p>
<p>You're being strip-mined. But you'd rather be cultivated. The question is how to lead in that direction from where you are.</p>
<h3>Step 2: Optimize for the metric</h3>
<p>
Once the dashboard exists, it becomes the scoreboard. Standups shift from "what are you working on" to "why is your velocity down 12% this sprint." Engineers learn that the number matters more than the architecture. So they optimize for the number — generate more code, close more tickets, move faster.
</p>
<p>Here's how the extraction works. Your IDE tracks keystrokes. Your chat platform logs prompt history. Your code review tool measures time-to-merge. Your project management system tracks velocity. Every tool generates a "productivity dashboard" that tells leadership exactly how many units of work each person produced. Once the dashboard exists, it becomes the scoreboard. Standups shift from "what are you working on" to "why is your velocity down twelve percent this sprint." Engineers learn that the number matters more than the architecture. So they optimize for the number.</p>
<h3>Step 3: Strip the soil</h3>
<p>
The AI tools amplify this feedback loop. Generate more code. Accept more suggestions. Ship faster. The engineer stops designing. They start assembling. The craft of software engineering — the part where you sit with a problem, understand it deeply, and build something elegant — gets replaced by prompt-and-accept loops.
</p>
<p>The AI tools amplify this loop. Generate more code. Accept more suggestions. Ship faster. The engineer stops designing and starts assembling. The craft of software engineering, the part where you sit with a problem, understand it deeply, and build something elegant, gets replaced by prompt-and-accept loops.</p>
<h3>Step 4: Wonder why everyone's quitting</h3>
<p>
Six months in, your most experienced engineers hand in notice. Not because the pay is bad. Not because the perks dried up. Because they don't recognize their own work anymore. They're assembly line workers in a factory they used to design.
</p>
<p>Six months in, your most experienced engineers hand in notice. Not because the pay is bad. Not because the perks dried up. Because they don't recognize their own work anymore. They're assembly line workers in a factory they used to design.</p>
<h2>The Soil Beneath the Code</h2>
<p>
This is where it connects to something I've been thinking about for a long time: <strong>cultivation versus strip mining.</strong>
</p>
<p>
Strip mining is efficient. You extract the maximum resource in the minimum time. The numbers look incredible for a few quarters. Then the soil is dead, the water is contaminated, and the land produces nothing.
</p>
<p>
Cultivation is slower. It requires attention to soil health, to rotation, to rest. It doesn't maximize short-term yield. But it produces indefinitely.
</p>
<p>
The surveillance-driven AI adoption playbook is strip mining applied to human beings. You instrument, you optimize, you extract. The dashboards look amazing. The humans are dying.
</p>
<p>
And here's the part nobody's saying out loud: <strong>the surveillance tools aren't even measuring the right things.</strong> They measure volume. Volume of code. Volume of commits. Volume of tickets closed. But the value of an engineer isn't in volume — it's in judgment. It's in knowing what NOT to build. It's in catching the architectural decision that would have cost six months of rewrites. It's in mentoring the junior engineer who was about to quit.
</p>
<p>
None of that shows up on a dashboard.
</p>
<p>The cultivation metaphor isn't decorative here. It's the whole point. Strip mining is efficient. You extract the maximum resource in the minimum time. The numbers look incredible for a few quarters. Then the soil is dead and the land produces nothing.</p>
<h2>The Disengagement Tax</h2>
<p>
Remember the Gallup numbers from <a href="/blog/ai-brain-fry">my last piece</a>? 80% global disengagement. $438 billion in lost productivity.
</p>
<p>
Here's what I didn't say: engagement isn't just about burnout. It's about <strong>agency</strong>. People disengage when they feel like they've lost control over their work. When every move is tracked, every decision is second-guessed by a dashboard, every creative act is reduced to a data point — agency evaporates.
</p>
<p>
The Harvard Business Review found something striking: employees under heavy surveillance show 47% lower psychological safety scores. They stop proposing ideas. They stop questioning decisions. They stop doing the thing that makes them valuable — thinking independently.
</p>
<p>
So the surveillance pipeline produces exactly the opposite of what it promises: more data, less insight. More output, less value. More tracking, less trust.
</p>
<p>Cultivation builds soil. It takes longer. It looks less productive in quarterly reports. But it produces indefinitely.</p>
<h2>What Cultivation Looks Like Instead</h2>
<p>
Here's the alternative. It's not complicated, but it requires leadership courage:
</p>
<p>And the surveillance tools aren't even measuring the right things. They measure volume: code, commits, tickets closed. But the value of an engineer isn't in volume. It's in judgment. It's in knowing what not to build. It's in catching the architectural decision that would have cost six months of rewrites. It's in mentoring the junior engineer who was about to quit.</p>
<h3>Measure outcomes, not activity</h3>
<p>
Did the system become more reliable? Did customers report fewer bugs? Did the team ship something users actually wanted? These are harder to measure than lines of code. They're also the only ones that matter.
</p>
<p>None of that shows up on a dashboard.</p>
<h3>Protect deep work</h3>
<p>
Block off four-hour windows with no Slack, no meetings, no AI suggestions. Let engineers sit with hard problems. The AI tools will still be there when they emerge.
</p>
<p>The Harvard Business Review found that employees under heavy surveillance show forty-seven percent lower psychological safety scores. They stop proposing ideas. They stop questioning decisions. They stop doing the thing that makes them valuable, which is thinking independently.</p>
<h3>Audit the tools for extraction</h3>
<p>
Before adopting any AI tool, ask: what data does it collect? Where does that data go? Is it used to train models that will replace my team? Is it used to build a surveillance profile? If the answer to any of these isn't crystal clear and favorable to your people, don't adopt it.
</p>
<p>So the surveillance pipeline produces exactly the opposite of what it promises: more data, less insight. More output, less value. More tracking, less trust.</p>
<h3>Trust first, verify thoughtfully</h3>
<p>
The best engineering teams I've seen don't track keystrokes. They track whether the team is proud of what they shipped. Trust is a cultivation practice. You can't dashboard your way to it.
</p>
<p>Here's how to lead toward cultivation from where you are.</p>
<h2>The Bottom Line</h2>
<p>
The companies winning the AI transition aren't the ones with the best surveillance dashboards. They're the ones whose engineers still feel like engineers — not assembly line workers being monitored for throughput.
</p>
<p>
If your AI strategy starts with "how do we measure productivity," you've already lost. Start with "how do we make our people better at their craft." The productivity will follow. The data will be messier. The dashboards will be sparser. And your best people will stay.
</p>
<p>Measure outcomes, not activity. Did the system become more reliable? Did customers report fewer bugs? Did the team ship something users actually wanted? These are harder to measure than lines of code. They're also the only ones that matter.</p>
<footer class="article-footer">
<hr />
<p class="author-bio">
<strong>Scott Scoble</strong> writes about the human side of software development. He is the creator of <a href="https://speckl.scoble.me">Speckl</a> (open-source compliance specification language) and the author of <em>The Soil Beneath The Code</em>. He consults with engineering leaders on AI-augmented development strategy.
</p>
<p class="author-links">
<a href="/">scott.scoble.me</a> &middot; <a href="https://speckl.scoble.me">speckl.scoble.me</a>
</p>
<p>Protect deep work. Block off four-hour windows with no Slack, no meetings, no AI suggestions. Let engineers sit with hard problems. The AI tools will still be there when they emerge.</p>
<div class="cta-box">
<h3>Want to continue this conversation?</h3>
<p>
Connect with me on LinkedIn — I write about the human side of AI and what to do about it.
</p>
<a href="https://linkedin.com/in/scottscoble" class="cta-button">Connect on LinkedIn</a>
</div>
</footer>
<p>Audit the tools for extraction. Before adopting any AI tool, ask: what data does it collect? Where does that data go? Is it used to train models that will replace your team? If the answer to any of these isn't crystal clear and favorable to your people, don't adopt it.</p>
<p>Trust first, verify thoughtfully. The best engineering teams I've seen don't track keystrokes. They track whether the team is proud of what they shipped. Trust is a cultivation practice. You can't dashboard your way to it.</p>
<p>The companies winning the AI transition aren't the ones with the best surveillance dashboards. They're the ones whose engineers still feel like engineers; not assembly line workers being monitored for throughput.</p>
<p>You're here. You'd rather be there. The distance between strip-mining and cultivation is measured in the decisions you make about what you track and what you trust.</p>
<p>What are you tracking?</p>
</div>
</article>
</BaseLayout>
<style>
.article {
padding: 8rem 2rem 6rem;
background: var(--color-cream);
}
.article-header {
.post {
max-width: 720px;
margin: 0 auto 3rem;
text-align: center;
margin: 0 auto;
padding: 8rem 2rem 6rem;
}
.article-meta {
.post-header {
margin-bottom: 3rem;
}
.post-meta {
display: flex;
justify-content: center;
gap: 1rem;
margin-bottom: 1.5rem;
font-size: 0.875rem;
}
.article-date {
.post-date {
color: var(--color-text-muted);
}
.article-tag {
.post-tag {
color: var(--color-amber);
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.article-header h1 {
.post-header h1 {
font-family: var(--font-heading);
font-size: clamp(2rem, 4vw, 3rem);
color: var(--color-brown-dark);
margin: 0 0 1rem;
line-height: 1.2;
}
.article-subtitle {
font-size: var(--size-lg);
color: var(--color-text-muted);
margin: 0;
line-height: 1.6;
}
.article-body {
max-width: 720px;
margin: 0 auto;
font-size: var(--size-md);
.post-content {
font-size: 1.125rem;
line-height: 1.8;
color: var(--color-text);
}
.article-body h2 {
font-family: var(--font-heading);
font-size: var(--size-2xl);
color: var(--color-brown-dark);
margin: 3rem 0 1rem;
}
.article-body h3 {
font-family: var(--font-heading);
font-size: var(--size-xl);
color: var(--color-green);
margin: 2rem 0 0.75rem;
}
.article-body p {
margin: 0 0 1.25rem;
}
.article-body a {
color: var(--color-green);
text-decoration: underline;
text-underline-offset: 2px;
}
.article-body a:hover {
color: var(--color-green-dark);
}
.article-body strong {
color: var(--color-brown-dark);
}
.closing-question {
font-family: var(--font-heading);
font-size: var(--size-xl) !important;
color: var(--color-green) !important;
margin: 2rem 0 !important;
padding: 1.5rem 2rem;
background: var(--color-cream-warm);
border-left: 4px solid var(--color-amber);
border-radius: 0 8px 8px 0;
}
.article-footer {
margin-top: 4rem;
padding-top: 2rem;
}
.article-footer hr {
border: none;
border-top: 1px solid var(--color-border);
margin: 0 0 2rem;
}
.author-bio {
font-size: var(--size-sm);
color: var(--color-text-muted);
line-height: 1.6;
}
.author-links {
font-size: var(--size-sm);
color: var(--color-text-muted);
margin: 0.5rem 0 2rem;
}
.author-links a {
color: var(--color-green);
}
.cta-box {
background: white;
border: 1px solid var(--color-border);
border-radius: 12px;
padding: 2rem;
text-align: center;
margin-top: 2rem;
}
.cta-box h3 {
font-family: var(--font-heading);
font-size: var(--size-lg);
color: var(--color-brown-dark);
margin: 0 0 0.75rem;
}
.cta-box p {
font-size: var(--size-sm);
color: var(--color-text-muted);
.post-content p {
margin: 0 0 1.5rem;
}
.cta-button {
display: inline-block;
background: var(--color-amber);
color: white !important;
text-decoration: none !important;
padding: 0.75rem 2rem;
border-radius: 8px;
font-weight: 600;
font-size: var(--size-sm);
transition: background 0.2s ease;
}
.cta-button:hover {
background: var(--color-amber-light);
}
@media (max-width: 640px) {
.article {
padding: 6rem 1.25rem 4rem;
}
.article-header h1 {
font-size: 1.75rem;
}
.article-body {
font-size: var(--size-base);
}
}
</style>
</style>

142
src/pages/blog/token-anxiety.astro
View file

@ -3,98 +3,98 @@ import BaseLayout from '../../layouts/BaseLayout.astro';
---
<BaseLayout
title="The Token Anxiety Trap — Why AI Agents Aren't Liberating Us (Yet) — Scott Scoble"
description="Your agent swarm runs 24/7 and you're more anxious than ever. That has a name: token anxiety. Stanford 2026 data reveals the burnout behind AI productivity — and 3 questions to ask before your next agent run."
title="The Token Anxiety Trap — Why AI Agents Aren't Liberating Us (Yet)"
description="Token anxiety is BS. If you know what you're doing and optimize for outcomes, token cost is meaningless."
ogType="article"
canonicalUrl="/blog/token-anxiety"
pageType="blog"
>
<article class="article">
<header class="article-header">
<div class="article-meta">
<span class="article-date">May 4, 2026</span>
<span class="article-tag">AI</span>
<article class="post">
<header class="post-header">
<div class="post-meta">
<span class="post-date">May 4, 2026</span>
<span class="post-tag">AI</span>
</div>
<h1>The Token Anxiety Trap — Why AI Agents Aren't Liberating Us (Yet)</h1>
<p class="article-subtitle">
Your agent swarm is running 24/7 and you're more anxious than ever. Stanford's 2026 AI Index reveals the human cost of the agent revolution — and what leaders can actually do about it.
</p>
</header>
<div class="article-body">
<div class="post-content">
<p>Token anxiety is BS.</p>
<p>Your agent swarm is running 24/7. You've got bots scraping Reddit at 6 AM, a resume updater, a competitor tracker, and a networking assistant that prompts you to follow up with people you forgot you met. You used to pay a human assistant in the Philippines. Now you just pay for tokens.</p>
<p>There's a term floating around Silicon Valley right now. Nikunj Kothari at FPV Ventures coined it: that feeling of "in this given unit of time, which we don't get back, how can I have AI do a lot more for me than the next person?" People checking their agents during parties. At bars. Walking through Dolores Park with laptops slightly open. Replacing evening Netflix with Claude Code, dreaming up new tasks to automate. Rushing the kids to bed so they can get back to the computer.</p>
<p>And somehow, you're more anxious than ever.</p>
<p>The New York Times calls it "tokenmaxxing." Axios says AI agents "operate like slot machines" for power users. Stanford's AI Index shows junior developer employment down twenty percent since 2024. The industry is in what one former Grammarly lead calls "a collective identity crisis."</p>
<p>This isn't hypothetical. It's what's happening in Silicon Valley right now, and it's spreading. John Huang, a tech veteran who runs a startup investment network, has eight agents running simultaneously. Kevin Staight, a sales strategy lead, feels his "whole company should shut down and focus on this for about a month." Nikunj Kothari, a VC at FPV Ventures, has a name for what he sees everywhere in San Francisco:</p>
<p>All of that is real. The anxiety is real. The burnout is real. The junior dev pipeline collapsing is real.</p>
<p><strong>Token anxiety.</strong></p>
<p>But token anxiety specifically, the anxiety about how many tokens you're burning, whether you're getting enough value per token, whether the person next to you is extracting more from their agent swarm than you are; that's not anxiety. That's a signal that you don't know what you're doing.</p>
<p>Kothari describes it like this: "Everybody has this feeling of like, 'Hey, time is the only thing that matters. And in that given unit of time, which we don't get back, how can I have AI do a lot more for me than the next person?'"</p>
<p>If you know what you're doing and you optimize for outcomes, the token usage is meaningless. The outcome is always more valuable than the money spent on the tokens. Always. If a token run costs you five dollars and produces fifty thousand dollars of value, the tokens are free. If a token run costs you five cents and produces nothing because you don't have a clear outcome in mind, the five cents was wasted and no amount of token optimization will fix that.</p>
<p>He sees people checking their agents during parties. At bars. Walking through Dolores Park with "the warm glow of the light" from laptops slightly open. He himself has replaced his evening Netflix time with Claude Code, dreaming up new tasks to automate. He has two young kids and admits: "I felt guilty because I'd be like, 'Oh, go to bed quickly so I can get back to my computer.'"</p>
<p>The problem isn't the tokens. The problem is directionless work.</p>
<p>The agents were supposed to free us. Instead, they've given us a new way to work during every waking hour — and a new reason to feel inadequate.</p>
<p>Eric Weber, who led data and AI at Grammarly, put it plainly: "What is causing a lot of stress for people is that doing more doesn't necessarily create more leverage or impact. You're just doing more stuff. And so we don't spend a lot of time on the question: what should you actually be doing?"</p>
<h2>The Slot Machine Problem</h2>
<p>We automated the how without examining the why. We built systems that maximize output while ignoring outcomes. Then we called the resulting anxiety "token anxiety" and wrote blog posts about how to cope with it.</p>
<p>Axios recently reported that AI agents "operate like slot machines" for power users. They produce just enough wins to keep you hooked — a clever automation here, a solved problem there — but the unpredictability means you keep pulling the lever. The wins are real, but so is the burnout.</p>
<p>You don't cope with it. You fix the direction.</p>
<p>The Allen Institute's Tim Dettmers notes that peak productivity now comes from "working with as many agents as possible in parallel," which requires near-constant context switching. Humans, as it turns out, aren't great at that.</p>
<p>Think about it physically. If you're running toward something, you don't count your steps. You count your distance to the goal. Steps are just what legs do. If you're running and you don't know where you're going, every step feels like a waste and you start counting them, and then you start optimizing the counting, and then you're not running anymore; you're just counting.</p>
<p>We're building tools that demand exactly the cognitive pattern we're worst at.</p>
<p>That's token anxiety. It's step-counting by people who forgot where they were going.</p>
<h2>The Junior Dev Canary</h2>
<p>The fix isn't three questions before your next agent run. The fix is having an outcome before you start the run. If you can articulate what you're trying to accomplish, the tokens are infrastructure. If you can't, the tokens are a proxy for productivity, and optimizing a proxy never gets you to the real thing.</p>
<p>Stanford's 2026 AI Index dropped a staggering number: <strong>employment among software developers aged 22–25 has dropped nearly 20% since 2024</strong>, even as older developers' headcount grows. The same pattern appears in customer service and other AI-exposed roles.</p>
<p>We're not just automating tasks. We're automating the entry-level jobs that used to be the on-ramp to entire careers. The mentors who would have trained those junior devs are busy managing their agent swarms. The code reviews that would have taught them are being done by Claude.</p>
<p>Eric Weber, a former data/AI lead at Grammarly (now Superhuman), puts it plainly: "The change has happened so quickly that I think it is disorienting for people. People are like, 'Am I good at what I do? What does it mean to be good at what I do?'"</p>
<p>The industry, he says, is in a collective identity crisis.</p>
<h2>Tokenmaxxing: When Companies Weaponize Your Anxiety</h2>
<p>The New York Times recently reported that some of the biggest tech companies are <strong>"tokenmaxxing"</strong> — pushing employees to burn through as many AI credits as possible to churn out features at an ever-faster pace.</p>
<p>Think about that word for a second. It's not "being productive." It's not "leveraging AI." It's <em>tokenmaxxing</em> — a term that sounds like it fell out of a crypto bro's group chat. It treats AI usage as a metric to optimize, not a tool to wield.</p>
<p>When your company measures your value in tokens burned, you stop asking whether you're building the right thing. You just keep burning tokens.</p>
<h2>What We're Not Asking</h2>
<p>Weber's observation cuts to the core: "What is causing a lot of stress for people is that doing more doesn't necessarily create more leverage or impact. You're just doing more stuff. And so we don't spend a lot of time on the question: what should you actually be doing?"</p>
<p>That's the question the agent revolution hasn't answered. We've automated the <em>how</em> without examining the <em>why</em>. We've built systems that maximize output while ignoring outcomes.</p>
<p>A month ago, Weber stepped back from his full-time executive role. He still uses agents, but he's spending more time thinking, writing, and talking to people. He's asking the question that the token economy doesn't want you to ask.</p>
<h2>Three Questions Before You Open That Laptop in the Park</h2>
<p>Token anxiety isn't inevitable. It's a design choice — in our tools, in our companies, and in our own habits. Here are three questions worth asking before you start your next agent run:</p>
<p><strong>1. What am I actually trying to accomplish?</strong> Not "what can I automate?" — what actually matters? If you can't articulate the outcome, the agent can't help you reach it. It can only make you busier.</p>
<p><strong>2. Is this replacing work or replacing thinking?</strong> Agents should handle the work you understand well enough to delegate. They shouldn't replace the thinking that determines what work is worth doing. The moment you outsource judgment, you've stopped leading and started managing tokens.</p>
<p><strong>3. Who am I not talking to right now?</strong> Every hour spent optimizing agent workflows is an hour not spent with your team, your family, your own thoughts. Weber stepped back to talk to people. Kothari catches himself rushing his kids to bed. The agent army doesn't need you to command it constantly. The people around you do.</p>
<hr />
<p>The promise of agentic AI wasn't that we'd work more. It was that we'd work on what matters.</p>
<p>We're not there yet. But the path isn't to throw away the agents. It's to remember who's supposed to be in charge.</p>
<p>The agent revolution promised freedom. What it delivered was a new way to be busy. The difference between busy and productive has always been the same: do you know what you're building? If yes, burn the tokens. If no, close the laptop and figure it out.</p>
<p>Your tokens aren't the bottleneck. Your direction is.</p>
</div>
<footer class="article-footer">
<div class="article-cta">
<p>Enjoyed this? <a href="/blog">Read more articles</a> on AI, leadership, and the human side of technology.</p>
<p>Ready to bring this thinking to your team? <a href="https://linkedin.com/in/scottscoble">Connect with me on LinkedIn</a>.</p>
</div>
</footer>
</article>
</BaseLayout>
</BaseLayout>
<style>
.post {
max-width: 720px;
margin: 0 auto;
padding: 8rem 2rem 6rem;
}
.post-header {
margin-bottom: 3rem;
}
.post-meta {
display: flex;
gap: 1rem;
margin-bottom: 1.5rem;
font-size: 0.875rem;
}
.post-date {
color: var(--color-text-muted);
}
.post-tag {
color: var(--color-amber);
font-weight: 600;
}
.post-header h1 {
font-family: var(--font-heading);
font-size: clamp(2rem, 4vw, 3rem);
color: var(--color-brown-dark);
line-height: 1.2;
margin: 0;
}
.post-content {
font-size: 1.125rem;
line-height: 1.8;
color: var(--color-text);
}
.post-content p {
margin: 0 0 1.5rem;
}
</style>