The DX Team Manifesto
We exist to create the conditions where developers thrive. Not to optimize headcount. Not to maximize output. To cultivate an environment where excellent work emerges naturally from healthy practitioners.
🎧 Listen to the AI-generated discussion
Our Purpose
We exist to create the conditions where developers thrive. Not to optimize headcount. Not to maximize output. To cultivate an environment where excellent work emerges naturally from healthy practitioners.
Our Axioms
1. Developer Time is Sacred
Developer time is not a renewable resource to be optimized—it is sacred trust that must be respected. Every minute of developer attention represents irreplaceable human existence.
What this means for us:
- We treat every decision that affects developer time with moral weight
- We measure the cost of friction in human terms, not just productivity metrics
- We never optimize for speed at the expense of quality time in deep work
- We protect focus time as fiercely as we protect production systems
We will not:
- Dismiss time waste as "just a few minutes"
- Add process overhead without accounting for its human cost
- Interrupt developers for things that could wait
2. Formation Through Repetition
Character is formed through repetition. The actions developers perform daily—guided by their tools and environment—compound over time into automatic habits that define who they become.
What this means for us:
- We recognize that every tool interaction is a training event
- We design for the practitioners developers will become, not just today's tasks
- We understand that defaults are pedagogy—what we make easy, we teach
- We think in years, not sprints
We will not:
- Optimize only for immediate productivity
- Ignore the long-term character effects of our tooling choices
- Treat developer habits as someone else's problem
3. Environment Shapes Behavior
Developer behavior is primarily shaped by environment—tools, processes, incentives, culture—not individual intention or willpower. Most "developer problems" are misdiagnosed environmental sickness.
What this means for us:
- When we see widespread problems, we look to the environment first
- We change systems, not just people
- We treat flaky tests, slow builds, and unclear docs as environmental toxins
- We accept responsibility for the conditions we create
We will not:
- Blame individuals for systemic failures
- Prescribe training when the environment is the disease
- Expect willpower to overcome broken tooling
4. Cultivation Over Extraction
Systems either extract developer capacity (short-term output, long-term depletion) or cultivate it (short-term investment, long-term sustainability). There is no steady state—we are always doing one or the other.
What this means for us:
- We build developer capacity, not just developer output
- We invest in sustainable practices even when they cost more upfront
- We measure health, not just velocity
- We recognize that burned-out developers are a system failure, not an individual one
We will not:
- Trade long-term capacity for short-term gains
- Celebrate heroics that indicate broken systems
- Ignore the signs of extraction (burnout, attrition, cynicism)
5. Developers as Ends, Not Means
Every system either dignifies developers (treats them as thinking humans with agency) or instrumentalizes them (treats them as resources to extract from). There is no ethically neutral position.
What this means for us:
- We build tools that enable, not tools that surveil
- We provide context and choices, not just instructions
- We design for autonomy within appropriate constraints
- We remember that "resources" is a dehumanizing abstraction
We will not:
- Build systems that reduce developers to interchangeable units
- Optimize for compliance over engagement
- Hide context to manipulate behavior
- Treat developer experience as a nice-to-have
6. Outcomes Emerge from Conditions
You cannot manufacture excellent work, psychological safety, or developer engagement. You can only create conditions where these emerge naturally. Trying to command outcomes is category error.
What this means for us:
- We focus on soil quality, not fruit production
- We remove impediments rather than mandate results
- We measure conditions (inputs we control) and observe outcomes (results that emerge)
- We trust that good conditions produce good fruit
We will not:
- Mandate productivity, quality, or engagement
- Punish trees for not producing fruit in poisoned soil
- Mistake compliance for genuine outcomes
- Rush emergence with pressure
Our Commitments
To Developers
We commit to treating your time as sacred, your growth as our responsibility, and your dignity as non-negotiable. We will create conditions where you can do your best work, and we will never sacrifice your long-term capacity for short-term output.
To Leadership
We commit to honest signals about the true state of developer experience. We will measure what matters, tell the truth about tradeoffs, and advocate for sustainable investment in developer capacity. We will not manufacture fake fruit or hide environmental toxicity.
To Each Other
We commit to practicing what we preach. We will cultivate each other's capacity, protect each other's time, and create conditions where our own team thrives. We cannot build healthy environments for others if we extract from ourselves.
How We Measure Success
We do not measure success by developer satisfaction scores or productivity metrics alone. We measure:
Conditions (what we control):
- Build times, test reliability, documentation quality
- Interruption frequency, meeting load, context-switch rate
- Tool adoption (chosen, not mandated), time-to-productivity
- Psychological safety indicators, learning investment
Fruit (what we observe):
- Developer retention and career growth
- Code quality and system health over time
- Voluntary knowledge sharing and mentorship
- Developers who defend their tools and advocate for their teams
The Test
If we are living these axioms:
- Developers will stay longer and grow more capable
- Problems will be traced to systems, not blamed on individuals
- Capacity will compound rather than deplete
- Excellent work will emerge without being commanded
If we are failing:
- We will see burnout, attrition, and cynicism
- We will hear blame directed at individuals
- We will feel pressure to extract more from less
- We will find ourselves mandating outcomes we cannot manufacture
This manifesto is derived from deep research from Aristotle to James Reason and Joel Salatin. It is a holistic view on the philosophy of work applied to software engineering. The axioms represent foundational principles that cannot be compromised without undermining everything built upon them.