TDR – Test Driven Relationships

TDD (Test Driven Development) seems fairly well known as a software development technique these days – even though uptake and understanding remains “patchy”. TDD purports to improve the quality of code by focusing on the intended behaviour of a piece of code before writing that code.

I believe that relationships – interpersonal relationships, relationships between people – are what really matters in work – and particularly in collaborative knowledge-work. Far more than code quality – although that’s handy, too.

One question which folks ask me regularly is “how might we go about improving the quality of our relationships?” I propose TDR – Test Driven Relationships might offer a way forward.

What is a Quality Relationship?

Psychology and psychotherapy have quite a lot to say about what makes for a quality relationship.

Gregg Henriques offers the “5 Cs” model (Conflicted -> Civil -> Cordial -> Close -> Connected)

Patrick Lencioni has his “5 Dysfunctions” model (Trust -> Positive conflict -> Commitment -> Accountability -> Results)

The Fundamentals of TDR

In improving relationships, it’s often helpful to try things out. For example, if we’re wanting to be more empathetic, it can be useful to try to guess how someone is feeling, and then ask them how close to the mark our guess is.

“In relationship, business, classroom, and parent-child conflicts, we can learn to hear the human being behind the message, regardless of how the message is framed. We can learn to hear the other person’s unmet needs and requests. Ultimately, listening empathetically does not imply doing what the person wants; rather, it implies showing respectful acknowledgment of the individual’s inner world. As we do that, we move from the coercive language we have been taught to the language of the heart.”

~ Marshall Rosenberg

Taking this principle and extending it, TDR says “define the results you expect – or desire – from an upcoming interaction with someone, plan an approach, have the interaction, and then compare the results against those expected / desired”. If the results don’t match up, refactor you approach to the interaction and try again.

As a reference and comparison, here’s the vanilla TDD four-step red-green-refactor process:

1. Add a test – the simplest possible
2. See it fail (red)
3. Make all tests (to date) pass, using the minimum amount of instructions (green)
4. Refactor

Why It Works

TDR helps us clarify our intent, and experiment in small increments with the way we relate to others, adjusting as we find things that don’t work so well, aw well as things that work particularly well.

“Every time I mess up is a chance to practice.”

~ Marshall Rosenberg

TDR also allows us to better keep the idea of “relationship quality” in our minds, and provides us with a practical means to focus on improving that quality.

For those who object to TDR on the grounds that it’s somehow fake, I offer the following advice:

“Fake it ‘till you make it.”

~ Neil Gaiman

How important is relationship quality to you? And what are you already doing about that, by way of e.g. deliberate practices?

– Bob