A while back I was brought in to teach TDD to a team. I started the way I usually do, by explaining that TDD is a quality activity, not a testing activity. The goal is higher quality, both in the design and in the actual code and the tests are largely just a side-effect, albeit a very useful one.
The team listened politely and then confidently told me that they didn’t need to improve their quality. After all, they wrote perfect code.
They were modest enough to admit that their code wasn’t always perfect on the first pass but that by the time they got through all their review steps, there were no more bugs. None.
I complimented them on that. Not having reported production bugs is indeed impressive.
I said “Can I show you how TDD works anyway? If you feel it doesn’t give you any extra value then you don’t have to use it.” Absolutely, they said, so we spent the next couple of hours walking through their code and test driving some changes.
In those few hours, we found about half a dozen bugs in their existing “perfect” code base. They weren’t things breaking in production, but they were absolutely places where the code was not doing what the developers expected it to do.
The moment they saw the results, they wanted to get better at what I’d shown them. They were immediately motivated to improve, and to learn this new skill.
So let’s consider motivation, and take a look at the Self Determination Theory (SDT) motivation model.
That team had an identity: we are engineers who care about quality. That identity was real and they were proud of it. They’d built quality gates, they thought carefully about their work, they were genuinely working to ship clean code. They just had an incomplete picture of what quality meant in practice.
TDD didn’t create their motivation. It landed on motivation that was already there. Once they could see that the technique served something they already cared about, adoption was obvious.
Compare that to the engagements where TDD training doesn’t stick. Almost always, one of two things is true. Either the engineering culture doesn’t have a real quality identity (ie shipping fast vs shipping quality) or the technique has been mandated as a process requirement rather than offered as a tool.
You cannot comply your way into caring.
Self-Determination Theory describes this as integrated motivation: when a behaviour becomes part of who you are, not just something you do. It’s one of the most durable forms of motivation that exists, surpassed only by intrinsic motivation, where the work is enjoyable in its own right.
The implication for engineering leaders: before you hire someone to teach your team a technique, ask the prior question.
What do your engineers really care about?
If the answer is clear and they have a genuine identity around quality, or craftsmanship, or shipping things that work, then technique training can move fast. You’re connecting a tool to something already present.
If the answer is unclear, or if the honest answer is “they care about getting their tickets to done,” the training problem isn’t the problem. You’re solving at the wrong level.
I’ve been teaching TDD since the late nineties. The engagements where it sticks aren’t the ones where I trained hardest. They’re the ones where I found the right soil.