The Claes Test
06 Feb 2026In a previous post, I talked about Kurt Lewin’s equation: \(B = f(P, E)\).
Behaviour is a function of the Person and their Environment.
When a team is struggling with missed “deadlines”, burnout, or shipping bugs, management usually looks at the Person. They hire “rockstars” or mandate “accountability”. They try to change the \(P\).
But changing the \(P\) is an exercise in futility. The \(E\) (the Environment) is the lever we actually control.
In 2000, Joel Spolsky gave us the Joel Test. It was a brilliant, 12-question metric for the engineering environment. But back then, the environment was mostly about tools: Do you use source control? Do you have a bug database?
Today, the tools are table stakes. Our modern bottlenecks are no longer technical; they are cultural and systemic.
I’ve spent some time thinking about what the Joel Test looks like if we apply Lewin’s Equation to 2025. I call it The Claes Test, or more formally, The Developer Culture Test.
Claes, as in /klaːs/
Beyond Intentions
Most companies “value” psychological safety. Most companies “believe” in growth. But values and beliefs aren’t tangible or directly visible. Behaviour is the real litmus test.
The Claes Test doesn’t ask what you believe. It asks what you do.
It’s divided into four environmental pillars. If you can’t answer “Yes” and provide evidence for these 18 points, your \(E\) is likely working against your \(B\).
1. The Foundation (The Safety Net)
If the environment is built on fear or financial instability, you won’t get innovation. You’ll get self-preservation.
- Psychological Safety: Are post-mortems blameless? Can anyone raise a “stop the line” concern?
- Market-Fair Pay: Is compensation transparently benchmarked and regularly updated?
- True Flexibility: Is work measured by outcomes, or by “active” status on Slack?
2. Clarity & Alignment
Autonomy without clarity is a recipe for chaos.
- The “Why”: Can every engineer explain the customer impact of their current sprint?
- Visible Roadmap: Is the backlog prioritised, visible, and linked to business goals?
- Direct Communication: Is there a documented process (like RFCs) for technical dissent?
- Cross-Functional Unity: Do Dev, Ops, and Product solve problems together, or “pass the ticket”?
- Recognised Initiative: Is work that improves the “commons” (refactoring, tooling) rewarded?
3. Sustainable Engineering
This is where we measure the “friction” in your environment. High friction = low throughput.
- Operational Readiness: Is there a mandatory “Definition of Done” for production safety?
- Quality Gates: Are code reviews and automated testing non-negotiable?
- Continuous Delivery: Can you deploy safely multiple times a day?
- Humane On-Call: Is the rotation compensated and followed by a learning review?
- InnerSource: Is the “silo” gone? Can any team contribute to any codebase?
4. Growth & Progression
If the environment doesn’t offer a path forward, the best people will find one that does.
- Technical Management: Do leaders have the depth to be credible partners to the team?
- Transparent Ladder: Are promotion criteria objective and public?
- Parallel Tracks: Can a Staff Engineer earn/influence as much as a Director?
- Feedback Loops: Is feedback regular, peer-to-peer, and focused on growth?
- Investment: Is there a dedicated budget and time for professional development?
How to Use the Test
The Joel Test was binary. You either did it or you didn’t.
The Claes Test is a mirror.
If you want to understand why your team’s behaviour isn’t meeting expectations, stop looking at the people. Run this test and be honest.
A “yes” requires evidence. “We try to do this” is a “no.”
When you find the “no”s, you’ve found the friction in your environment. Fix the environment, and the behaviour will follow.
If you want a practical way to do that, run the Claes Test with your team.
It’s designed to surface where your culture is helping, and where it’s holding you back.