TDR – Test Driven Relationships

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

3 comments
  1. Tobias said:

    I like the intent of this, very much. I wonder about this idea though: “If the results don’t match up, refactor you approach to the interaction and try again.” This is where the analogy with TDD falls down. The interaction occurred. It’s over. It is not refactorable, only recreatable. Our first attempt may result in hurt feelings, annoyance, resentment, or any number of undesired consequences. We can’t simply start again and do it over. We’ll need to reconceive the situation and perhaps find a different approach altogether. Getting back to coding… sometimes the code is so crappy we have to simply throw it away and start again—maybe using a new language. Interesting post. Gets me thinking…

    • Hi Tobias,

      Thanks for joining the conversation on this post. I had in mind an interaction (plan) as “code”. And thus refactorable. I had consciously excluded the idea of the “execution” (the interaction itself) leaving a “footprint”, but of course that can happen – especially if we’re at all incautious or unskilled.

      Happy to hear it gets you thinking. My core intention.🙂

      – Bob

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: