By Scott Scoble in DX First Principles — 29 Jan 2026

Your DX Team Isn't a Service Desk (And That's the Problem)

Hook: You hired smart people, gave them a cool title, and turned them into glorified janitors. Here's how it happened and how to fix it.

Picture this: A company decides to invest in Developer Experience. They hire talented engineers. They create a DX team. They announce it proudly.

Six months later, the DX team is buried in tickets:

"The build is slow, can you fix it?"
"Our CI is flaky, can you look into it?"
"We need a new dev environment setup."
"The wiki is outdated, can someone update it?"

The DX team has become a service desk. They're reactive, ticket-driven, and increasingly burned out. Meanwhile, organizational soil quality continues to degrade because nobody is actually tending it.

How did we get here?

The Service Desk Trap

Most organizations understand DX through the lens of IT support. Someone has a problem. They file a ticket. Someone fixes it. Problem solved.

This model makes sense for help desks. It's catastrophic for DX.

Why? Because DX isn't about fixing individual problems. It's about changing the environmental conditions that produce problems.

When the DX team becomes a service desk:

They fix symptoms, not root causes
They create dependency instead of capability
They become a bottleneck for all dev-related issues
They never have time for systemic improvement
They burn out and leave, taking institutional knowledge with them

The organization gets worse, not better. Just with more tickets closed.

What DX Teams Should Actually Be

Here's the reframe: DX teams are soil scientists, not gardeners.

A gardener grows plants. They're responsible for the output—the tomatoes, the flowers, the vegetables.

A soil scientist studies and improves soil quality. They measure pH levels, nutrient content, drainage, microbial health. They amend the soil so that any gardener can grow healthy plants.

DX teams shouldn't be growing software. Product teams do that.

DX teams should be ensuring the soil—the organizational environment—is healthy enough that good development practice can flourish.

The Four Functions of a Soil Scientist

A real DX team does four things:

1. Soil Testing (Measurement & Diagnosis)

What's the actual state of the development environment?
Build times, deploy frequency, incident rates, turnover, psychological safety
Not satisfaction surveys—actual conditions
Diagnose root causes, not symptoms

2. Soil Amendment (Targeted Interventions)

Fix identified deficiencies systematically
Time structure problems? Protect focus time.
Psychological safety problems? Address culture.
Tooling problems? Improve CI/CD.
Evidence-based interventions, not random tool adoption

3. Ecosystem Cultivation (Community Building)

Craft talks, mentorship programs, knowledge sharing
"What good looks like" documentation
Teaching infrastructure
Self-sustaining community of practice

4. Barrier Removal (Weed Pulling)

Eliminate unnecessary friction
Surface toxic patterns to leadership
Advocate for resources
Push back on harmful decisions

Notice what's not on this list: "Respond to tickets."

The Dependency Problem

When DX teams operate as service desks, they create dependency. Developers learn: "If I have a problem, DX team fixes it."

This seems helpful. It's actually toxic.

Because now the DX team is a single point of failure. They can't scale. They become bottlenecks. And if they leave, all that implicit knowledge walks out the door.

The opposite of dependency is capability. A healthy DX team builds capability in others. They teach teams to diagnose their own problems. They create self-service tools. They cultivate practices that spread virally.

The test: What happens if the DX team disappeared tomorrow?

Bad DX team: Everything collapses. They were a crutch.
Good DX team: Practices continue. The ecosystem sustains itself.

The Power Problem

Here's the uncomfortable truth: soil improvement often requires saying "no" to leadership.

"We need to ship faster" → "Actually, we need to slow down to fix the build." "Just add more people" → "Actually, more people will make it worse right now." "Skip the refactor, ship the feature" → "Actually, skipping the refactor will cost us three features next quarter."

A service desk can't say no. They just take tickets.

A soil scientist must have the authority to prioritize long-term health over short-term pressure. This means:

Reporting to someone with real power (VP Eng / CTO level)
Having dedicated budget (not begging quarterly)
Having veto power over decisions that harm soil quality
Being able to escalate when necessary

Without power, DX teams become useless evangelists—preaching good practices while the soil degrades around them.

The Escape Plan

If your DX team is stuck in service desk mode, here's how to escape:

1. Stop taking tickets. Literally. Create a different channel for "my build is broken" requests. Those should go to platform teams, not DX.

2. Start measuring soil. What's the actual state of your development environment? Build times, retention, psychological safety? Get data.

3. Identify root causes. Slow builds aren't a ticket to fix. They're a symptom of deeper issues—maybe dependency management, maybe test architecture, maybe infrastructure underinvestment.

4. Propose systemic interventions. Don't fix the build once. Fix the system that produces slow builds.

5. Build the business case. Leadership cares about revenue, risk, and competitive advantage. Translate soil quality into those terms.

6. Demand appropriate authority. If you can't prioritize long-term health over short-term pressure, you can't do the job. Get the authority or get out.

The North Star

Here's the mission statement every DX team should adopt:

"Ensure that good development practice can flourish here."

Not "fix developer problems." Not "improve developer satisfaction." Not "ship developer tools."

Create the conditions where good developers want to work, where practitioners grow over time, where systems become more stable, where work is sustainable.

That's soil science. That's the real job.

The tickets can wait.

Next in series: "The 3-Year Mission: Why DX Teams Should Plan Their Own Obsolescence"