feat: add 4 article pages (AI Brain Fry, Surveillance, Gallup, DevEx Shift) + link blog cards
All checks were successful
Build and Deploy to Storj / build-and-deploy (push) Successful in 10s

- ai-brain-fry.astro: full article with Gallup/HBR data, cognitive load patterns
- surveillance-extraction.astro: extraction vs cultivation product critique
- gallup-disengagement.astro: 80% disengagement crisis for eng leaders
- devex-shift.astro: DevEx as human sustainability, not tooling quality
- blog.astro: convert article cards to clickable links pointing to new pages

CI will deploy to scott.scoble.me via Storj on push.
This commit is contained in:
Scott Scoble 2026-05-05 10:08:09 -07:00
parent a4c14c95ab
commit 1f10c1a9c3
5 changed files with 1458 additions and 28 deletions

View file

@ -2,11 +2,11 @@
import BaseLayout from '../layouts/BaseLayout.astro';
---
<BaseLayout
title="Blog — Scott Scoble"
<BaseLayout
title="Blog - Scott Scoble"
description="Articles on AI, leadership, cultivation, and the human side of technology."
>
<section class="hero">
<div class="hero-content">
<p class="hero-kicker">Writing</p>
@ -19,16 +19,57 @@ import BaseLayout from '../layouts/BaseLayout.astro';
<section class="posts">
<div class="posts-container">
<article class="post-card">
<div class="post-meta">
<span class="post-date">May 3, 2026</span>
<span class="post-tag">AI</span>
</div>
<h2>AI Brain Fry Is a Workforce Crisis, Not a Productivity Story</h2>
<p class="post-excerpt">
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>
<a href="/blog/ai-brain-fry" class="post-link">
<div class="post-meta">
<span class="post-date">May 3, 2026</span>
<span class="post-tag">AI</span>
</div>
<h2>AI Brain Fry Is a Workforce Crisis, Not a Productivity Story</h2>
<p class="post-excerpt">
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>
</a>
</article>
<article class="post-card">
<a href="/blog/surveillance-extraction" class="post-link">
<div class="post-meta">
<span class="post-date">May 3, 2026</span>
<span class="post-tag">Leadership</span>
</div>
<h2>The Surveillance Dividend Is a Lie</h2>
<p class="post-excerpt">
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>
</a>
</article>
<article class="post-card">
<a href="/blog/gallup-disengagement" class="post-link">
<div class="post-meta">
<span class="post-date">May 3, 2026</span>
<span class="post-tag">Leadership</span>
</div>
<h2>80% of Your Team Is Disengaged. It's Not Their Fault.</h2>
<p class="post-excerpt">
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 &mdash; it's structural.
</p>
</a>
</article>
<article class="post-card">
<a href="/blog/devex-shift" class="post-link">
<div class="post-meta">
<span class="post-date">May 3, 2026</span>
<span class="post-tag">Engineering</span>
</div>
<h2>The Developer Experience Shift &mdash; And Why Tooling Alone Won't Save You</h2>
<p class="post-excerpt">
Companies will spend $60B+ on developer tools in 2026. But the real DevEx crisis isn't tooling — it's autonomy, mastery, and belonging. As code production becomes commoditized, the human dimensions of engineering become the only competitive advantage that matters.
</p>
</a>
</article>
<article class="post-card">
@ -38,7 +79,7 @@ import BaseLayout from '../layouts/BaseLayout.astro';
</div>
<h2>Three Questions That Changed How I Mentor</h2>
<p class="post-excerpt">
The simple mentoring framework that actually gets used — three questions that unlock real growth.
The simple mentoring framework that actually gets used - three questions that unlock real growth.
</p>
</article>
@ -49,7 +90,7 @@ import BaseLayout from '../layouts/BaseLayout.astro';
</div>
<h2>Three Signs Your Team Is Being Strip-Mined</h2>
<p class="post-excerpt">
The mindset shift that separates thriving teams from burned-out ones — cultivation over extraction.
The mindset shift that separates thriving teams from burned-out ones - cultivation over extraction.
</p>
</article>
@ -60,7 +101,7 @@ import BaseLayout from '../layouts/BaseLayout.astro';
</div>
<h2>The Soil Beneath The Code</h2>
<p class="post-excerpt">
A three-layer framework for understanding what makes engineering organizations healthy — or not.
A three-layer framework for understanding what makes engineering organizations healthy - or not.
</p>
</article>
@ -75,12 +116,12 @@ import BaseLayout from '../layouts/BaseLayout.astro';
text-align: center;
background: var(--color-cream);
}
.hero-content {
max-width: 600px;
margin: 0 auto;
}
.hero-kicker {
font-size: 0.875rem;
font-weight: 600;
@ -89,25 +130,25 @@ import BaseLayout from '../layouts/BaseLayout.astro';
color: var(--color-green);
margin: 0 0 1rem;
}
.hero h1 {
font-family: var(--font-heading);
font-size: clamp(2.5rem, 5vw, 4rem);
color: var(--color-brown-dark);
margin: 0 0 1rem;
}
.hero-description {
font-size: 1.125rem;
color: var(--color-text-muted);
margin: 0;
}
.posts {
padding: 4rem 2rem 6rem;
background: white;
}
.posts-container {
max-width: 800px;
margin: 0 auto;
@ -115,42 +156,48 @@ import BaseLayout from '../layouts/BaseLayout.astro';
flex-direction: column;
gap: 2rem;
}
.post-card {
padding: 2rem;
border: 1px solid var(--color-border-light);
border-radius: 12px;
transition: all 0.2s ease;
}
.post-card:hover {
border-color: var(--color-amber);
box-shadow: 0 4px 12px rgba(0, 0, 0, 0.05);
}
.post-link {
text-decoration: none;
color: inherit;
display: block;
}
.post-meta {
display: flex;
gap: 1rem;
margin-bottom: 1rem;
font-size: 0.875rem;
}
.post-date {
color: var(--color-text-muted);
}
.post-tag {
color: var(--color-amber);
font-weight: 600;
}
.post-card h2 {
font-family: var(--font-heading);
font-size: 1.5rem;
color: var(--color-brown-dark);
margin: 0 0 0.75rem;
}
.post-excerpt {
color: var(--color-text-muted);
margin: 0;

View file

@ -0,0 +1,335 @@
---
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."
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>
</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>
<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>
<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>
<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>
<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>
<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>
<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>
<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>
<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>
<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>
<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>
<h2>What I'm Doing About It</h2>
<p>
I'm building two things in parallel:
</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>
<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>
<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>
<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>Seeing AI brain fry on your team?</h3>
<p>
Higher error rates, faster turnover, quieter standups — I run a 90-minute workshop on shifting from extraction to cultivation metrics. No slides, just conversation.
</p>
<a href="/contact" class="cta-button">Get in touch</a>
</div>
</footer>
</div>
</article>
</BaseLayout>
<style>
.article {
padding: 8rem 2rem 6rem;
background: var(--color-cream);
}
.article-header {
max-width: 720px;
margin: 0 auto 3rem;
text-align: center;
}
.article-meta {
display: flex;
justify-content: center;
gap: 1rem;
margin-bottom: 1.5rem;
font-size: 0.875rem;
}
.article-date {
color: var(--color-text-muted);
}
.article-tag {
color: var(--color-amber);
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.article-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);
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);
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>

View file

@ -0,0 +1,369 @@
---
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."
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>
</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>
<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>
<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>
<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>
<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>
<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>
<h2>Why This Matters Now</h2>
<p>
We're at an inflection point where two forces are colliding:
</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>
<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>
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>
<h2>The Leadership Test</h2>
<p>
Here are three questions for engineering leaders:
</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 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 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>
<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>
<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>What's the DevEx initiative that missed the mark?</h3>
<p>
I'm collecting stories for a longer piece on what real Developer Experience looks like — the initiatives that worked and the ones that made things worse. DM me with your experience, or reach out if your team is wrestling with DevEx, autonomy, and meaning in an AI-augmented world.
</p>
<a href="/contact" class="cta-button">Get in touch</a>
</div>
</footer>
</div>
</article>
</BaseLayout>
<style>
.article {
padding: 8rem 2rem 6rem;
background: var(--color-cream);
}
.article-header {
max-width: 720px;
margin: 0 auto 3rem;
text-align: center;
}
.article-meta {
display: flex;
justify-content: center;
gap: 1rem;
margin-bottom: 1.5rem;
font-size: 0.875rem;
}
.article-date {
color: var(--color-text-muted);
}
.article-tag {
color: var(--color-amber);
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.article-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);
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);
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>

View file

@ -0,0 +1,350 @@
---
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."
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>
</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>
<h2>The Engagement Industrial Complex</h2>
<p>
We've spent two decades trying to fix engagement with the wrong tools:
</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>
<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>
<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>
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>
<h2>What Gallup Actually Found</h2>
<p>
Read past the headline numbers and the story gets sharper:
</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>
<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>
<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>
<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>
<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>
<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>
<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>
<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>
<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>
<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 move past engagement surveys?</h3>
<p>
I speak on the cultivation approach to leadership — keynote-friendly, 30-45 min, data-backed, no platitudes. If your organization or conference is looking for something that actually changes how leaders show up, let's talk.
</p>
<a href="/contact" class="cta-button">Get in touch</a>
</div>
</footer>
</div>
</article>
</BaseLayout>
<style>
.article {
padding: 8rem 2rem 6rem;
background: var(--color-cream);
}
.article-header {
max-width: 720px;
margin: 0 auto 3rem;
text-align: center;
}
.article-meta {
display: flex;
justify-content: center;
gap: 1rem;
margin-bottom: 1.5rem;
font-size: 0.875rem;
}
.article-date {
color: var(--color-text-muted);
}
.article-tag {
color: var(--color-amber);
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.article-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);
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);
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>

View file

@ -0,0 +1,329 @@
---
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."
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>
</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>
<h2>The Extraction Pipeline</h2>
<p>
Here's how it works in practice:
</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>
<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>
<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>
<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>
<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>
<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>
<h2>What Cultivation Looks Like Instead</h2>
<p>
Here's the alternative. It's not complicated, but it requires leadership courage:
</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>
<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>
<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>
<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>
<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>
<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>Feeling the surveillance squeeze?</h3>
<p>
I help engineering teams navigate the AI transition without strip-mining their people. If your team is struggling with AI surveillance culture, let's talk about what cultivation looks like in practice.
</p>
<a href="/contact" class="cta-button">Get in touch</a>
</div>
</footer>
</div>
</article>
</BaseLayout>
<style>
.article {
padding: 8rem 2rem 6rem;
background: var(--color-cream);
}
.article-header {
max-width: 720px;
margin: 0 auto 3rem;
text-align: center;
}
.article-meta {
display: flex;
justify-content: center;
gap: 1rem;
margin-bottom: 1.5rem;
font-size: 0.875rem;
}
.article-date {
color: var(--color-text-muted);
}
.article-tag {
color: var(--color-amber);
font-weight: 600;
text-transform: uppercase;
letter-spacing: 0.05em;
}
.article-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);
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);
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>