Should TDD be Mandatory? Why are so few teams using it?

Note: This is a scheduled email series of our previous webinars that I've prepared for your summer break while I’m on vacation 🏝️ I’ll be back soon for our regular streams and coaching.

We dig into:

• Why TDD shouldn’t be forced but still needs cultural buy-in

• The real reasons engineers resist it (and why that’s okay)

• How TDD aligns with faster, safer delivery not just testing

Mandatory TDD misses the point. So does banning it.

This session explores what actually makes TDD adoption succeed or fail . It’s about mindset, safety, and whether your team has space to improve. You’ll hear stories from the field about what happens when teams fake the motions without believing in the practice and how genuine adoption begins with letting go of control.

The question isn’t whether to enforce or ban TDD but whether the team has room for experimentation at all. Lack of safety or buy-in matters more than the technique itself.

Teams asking for TDD training without buy-in often just waste time. First solve the cultural bottleneck of lacking autonomy to improve.

TDD forces engineers to confront things they’re not good at—decomposition, architecture, even time management. Many prefer to gain confidence through coding, not testing.

If you release late, feedback arrives too late to act on. TDD encourages earlier, smaller releases that line up with when feedback actually matters.

TDD improves your ability to deliver safely under change. The tests are a side effect of design clarity and delivery flow.

👉 Watch the full recording above.
✉️ Subscribe to get the rest of this 5-part vacation deep dive series.
💬 Got a team that struggles with mocking, testing, or testability?

Reply to this post — I’d love to hear your challenges.

Thank you to everyone who tuned into my live video! Join me for my next live video in the app.