Soil Scientists, Not Gardeners: What DX Teams Actually Do
Hook: You've been told DX teams "improve developer productivity." That's like saying farmers "make plants grow." It's technically true and completely misses the point.
A gardener grows plants. They plant seeds, water them, prune them, harvest the fruit. They're responsible for the output—the tomatoes on the vine.
A soil scientist studies and improves soil quality. They measure pH levels, test for nutrients, analyze drainage, assess microbial health. They don't grow plants directly—they create conditions where plants can thrive.
DX teams should be soil scientists, not gardeners.
This distinction matters more than you think.
The Gardener Fallacy
When DX teams act like gardeners, they focus on the plants (developers) and the fruit (code shipped). They try to "increase productivity" directly—more output, faster delivery, higher velocity.
The problem: you can't actually make developers productive by focusing on productivity. That's like trying to make plants grow by pulling on them.
What you can do is improve the soil—the environment in which developers work. Give them better conditions, and productivity emerges naturally.
Gardener thinking: "How do we get developers to ship more features?" Soil scientist thinking: "What environmental conditions are preventing good work?"
Same goal. Completely different approach.
The 8 Components of Organizational Soil
Just as agricultural soil has measurable components (nitrogen, phosphorus, potassium, pH, drainage), organizational soil has measurable components too.
1. Time Structure (Aeration) Is there space for deep work? Or is the calendar so compacted that nothing can breathe?
- Healthy signal: 4+ hour focus blocks available daily
- Toxic signal: Fragmented calendar, constant interruptions
2. Psychological Safety (pH Balance) Can people admit mistakes without punishment? Can they ask "stupid" questions?
- Healthy signal: Mistakes discussed openly, learning happens
- Toxic signal: Blame culture, CYA behavior, filtered bad news
3. Lineage Holders (Microbiome) Are there experienced practitioners who teach and mentor?
- Healthy signal: Active mentorship, craft transmission
- Toxic signal: No seniors, no teaching, every person for themselves
4. Economic Substrate (Nutrients) Is there investment in quality? Good tools? Time for craft?
- Healthy signal: Time for testing, refactoring, learning
- Toxic signal: "Too busy for tests," inadequate tools
5. Feedback Loops (Water Cycle) How quickly does information flow? From code to production? From problems to awareness?
- Healthy signal: Fast CI, truth flows upward
- Toxic signal: Slow builds, filtered news, delayed feedback
6. Purpose & Meaning (Sunlight) Do developers understand why their work matters?
- Healthy signal: Work connects to impact
- Toxic signal: Pointless features, no connection to users
7. Structural Stability (Bedrock) Is there clear ownership? Institutional memory? Consistent structure?
- Healthy signal: Clear ownership, decisions documented
- Toxic signal: Constant reorgs, nobody knows who owns what
8. Constraint Balance (Drainage) Are constraints helpful (guiding good behavior) or harmful (just adding friction)?
- Healthy signal: Right thing is easy, wrong thing is hard
- Toxic signal: Process theater, useful constraints absent
The Soil Assessment Process
Soil scientists don't guess at soil composition. They test it.
Week 1-2: Quantitative Data
- Build times, deploy frequency, incident rates
- Turnover rates, especially among strong performers
- Time structure analysis (calendar fragmentation)
Week 2-3: Developer Surveys Not satisfaction surveys—condition surveys.
- "How many hours of uninterrupted focus time do you get?"
- "Can you admit mistakes without punishment?"
- "Is there time budgeted for quality work?"
Week 3-4: Ethnographic Observation
- Shadow developers. Watch them work.
- Attend meetings. Observe dynamics.
- Review artifacts. Read code, PRs, post-mortems.
Week 4: Synthesis Score each component: healthy, warning, or toxic. Map the patterns. Identify root causes.
Output: a soil assessment report that shows exactly where the problems are—not guesses, data.
Targeted Remediation
Once you know what's wrong, you can fix it systematically.
Compacted Time Structure?
- Institute no-meeting blocks (Tuesday/Thursday afternoons)
- Enforce 15-20% slack in sprint planning
- Ban routine death marches
Toxic pH (No Safety)?
- Train blameless post-mortems
- Celebrate learning from failure
- Protect truth-tellers
Sterile Microbiome (No Mentors)?
- Formalize mentorship (explicit pairings, protected time)
- Create teaching infrastructure
- Value teaching in advancement decisions
Nutrient Depletion (No Investment)?
- Build business case for quality time
- Justify tool investments
- Advocate for learning budgets
Each intervention targets a specific deficiency. Track improvement over quarters, not weeks.
The Cultivation Phase
After remediation comes cultivation: building a self-sustaining community of practice.
Craft talks: Developers teaching developers. Technical knowledge spreading.
Mentorship programs: Formal pairings that transmit practice and judgment.
Standards documentation: "What good looks like here"—not rules imposed, but patterns discovered.
Code review pedagogy: Review as teaching, not gatekeeping.
The goal: practices that sustain themselves without DX team intervention.
Why This Metaphor Matters
"Soil scientist" isn't just a cute reframe. It changes what you measure, what you prioritize, and how you think about success.
Gardeners measure fruit. "How many features did we ship?"
Soil scientists measure conditions. "Is the environment healthy for growing developers?"
Fruit can look good while soil degrades. You can have a bumper harvest while depleting the soil—next year, nothing grows. Organizations do this all the time: ship tons of features while burning out developers and accumulating debt.
Soil scientists catch this before it's too late. They track leading indicators—conditions that predict future outcomes—not just trailing indicators like velocity.
The Bottom Line
If you're on a DX team, stop thinking about developer productivity.
Start thinking about soil quality.
What are the conditions? Are they healthy or toxic? What's the trajectory—improving or degrading?
The plants will take care of themselves—if the soil is good.
Next in series: "The Sponsor You Need But Don't Deserve"