TDHD™ Test Driven Human Design™

In the software engineering world, test driven development or TDD is the concept whereby you write tests for your code before you even begin writing the code it's self. This has some huge benefits including: More elegant code, full regression testing taking only a few minutes, no repeat bugs and the idea that more time is spent on new developments than there is going back to fix old bugs and new bugs caused by updates to code.

Since I've been learning more and more about different ways of engineering software for computers and I've come across new and different ideas, I've begun to change the way in which I think about how people operate and the different ways that we can go about doing installations in order to change behaviours.

The standard way that I’ve noticed many people within the NLP community working with people goes along the lines that the client says what they want and then the practitioner goes about their change work. There comes a point at which the practitioner does some kind of test (hopefully) to determine whether what they've been doing has worked. This type of work almost always takes the form of the practitioner going in and making adjustments to the thing the client thinks is the problem and then testing to see if the problem is gone and voalla, success. The model that this tends to follow is the TOTE model developed by G. Miller and works on the principle that you first do a test to see where the client is at right now, and then you perform some kind of operation (operation phase actions) and then test again to see if the result was gained.

To me, this seems like a long winded way of going about things and this is where the ideas for Test Driven Human Design™ came from. The concept is really simple and works on the same lines as the Test Driven Development model in the software engineering world. That is that you first go ahead and create the tests that will later show that what you've done has worked. Once you've written the tests you fire them off and hopefully, unless the client has spontaneously changed without any intervention, the tests will fail. By beginning from the point of creating tests you start to take into account the whole structure of the human being you're working with. That is to say, when you think about what would have to be true for this person to not have the issue their having and you begin to realise that when you take into account the global structure of the way the person operates and maintains their problem, it may only require an extremely small shift in one area to completely change the way the person operates and/or the problem maintains its self.

So how do we actually go about working with people in this way?

Firstly it's important to know what the requirements are. Usually this takes the form of a verbal conversation where the client tell you their problem and the practitioner then asks questions to retrieve any deletions, distortions or generalisations. This is one way of finding out about the requirement however I personally don't work along the principle that the client knows what needs to be changed. Usually the client knows about the manifestation of something and they come in talking about the manifestation it's self. This isn't the same thing as "root cause" (for those who thought that might be what I’m suggesting to go after) because what I’m suggesting is that there are other things in a person’s life structure that are holding things in place and those things may well not have ever been the cause of the problem the person is having. This process is more about gathering information about a person’s life, how they live, who they exist with, what motivates them, what gets them going and what desires, ambitions, goals and dreams they already have, and then from that, calculating what could be the smallest possible change that'll have the largest impact on the entire structure of the person’s life. It's one thing to have someone change how they feel about a specific problem and it's another thing for them to create shifts in their lives that solve multiple issues all in one go and leave them with a happier more fulfilling existence.

The second part of Test Driven Human Design™ is to create tests that will need to be passed in order for the adjustments to have had the impact desired. The reason for creating these tests is that firstly, once you know what the tests are you can start to architect a solution that passes the test. This means that when you finish architecting the solution to the problem the person is having, you'll only ever be doing so in a way that passes the tests you've set yourself already and thus the strategies you create and the installations you perform will be as elegant as possible. The second reason for doing this is that as you begin to work with the person’s entire structure and adjust different things in different locations, you'll always be able to go back and run each of the tests to ensure that new adjustments haven't reset or wrongly adjusted work that you had previously done.

Each test is created right before you architect the solution that passes the test and therefore as you begin making adjustments, new criteria will stand out and you'll create new tests and new solutions that start to work in a particular direction.

All of this probably sounds like a lot of hard work so let me give an example of how this might work in a real life scenario.

A client comes in and tells you that they're depressed and you begin by eliciting more information about how the person goes about doing what they do. You might ask questions like "How do you know you're depressed" or "how do you know when to do depressed" etc etc. This gives you the information that you need in order to architect a solution to the problem the client is reporting. Now the issue here is that most practitioners go straight in for the psychological change and start to adjust the strategy that the person uses to "do" depression. This usually works but then most of the practitioners that I know who deal with depression and anxiety will confirm that clients usually revert back to being depressed at some point and to me, this is a clear indication that the fuller structure of the human being was not taken into account. Creating psychological changes is fantastic however it's not usually my first port of call. Sometimes there are physical things in a persons life that if changed would change the entire workings of that person for example: how much sleep they get, how much water they drink, whether they're being abused at home, being bullied at school, failing at exams because they simply don't know what resources they have available to them. All of these things can be part of a person’s life that help to maintain the problem the person is reporting and although a psychological change would work here I prefer to go for what's tangible first because it just might make all the difference.

One of the first tests I'd want to set up for this kind of issue would be a large chunk test that determines whether the client feels different from how they felt when they first turned up. Often this doesn't mean that they feel amazing or suddenly happy go lucky and often that's not what's needed. The idea to me is that when someone says they're stuck, any shift is going to be as useful as you make it. Often it takes a stronger emotion to break the client out of their stuck state and this would be where other tests are set up.

Some tests I’d want to include would be: Is the clients state different in this session than it was when they came in, has the client generalised the adjustments to other areas of their life, has dealing with a specific separate issue created a change in the maintenance of the current issue, is the issue resolved, is the person’s life going to be better when they leave here than it was when they arrived, will the person be able to maintain the solution to the issue alone or are there other parts of their life structure that need something also (perhaps family need to know things, friends will need to be there for them, external things will need to happen in order for the adjustment to have an impact).

Once you've started to create tests you can then go about architecting solutions to pass those tests and here's where it gets really interesting. Because you already have the tests in place and you know that right now those tests fail (or the one specific test you're working with right now), it becomes easier to notice when you've done just enough that the test passes. What usually happens is that the practitioner throws everything they know at the client and hopes that something works. The way I’m proposing to do things with TDHD™ is that you only ever need to do as much work as fulfils the criteria of the test and thus you always end up creating the most elegant solutions possible. You can always go back to architectures you've already built that work and begin re-factoring them in order to create more elegance and that's a major part of working this way.

I think it's really important for practitioners of NLP to understand what they're doing when they work with people and to notice the difference between how they break things apart and how they build new structures and install them. To me, this is what being an engineer is all about. It's one thing to use specific techniques and to hope they work with the problem at hand and it's another thing to understand the structure of something and to know which pin to pull out to bring the whole thing down and to then begin architecting new structures to replace the old structures and to make sure the new structures are strong enough to stay standing.

NLP is very similar to Chemistry in that a lot of it revolves around the ideas of pulling things apart and putting things together. If you don’t know at what point you're doing which one, how can you begin creating new structures that create the largest change given the environment they're being installed into?

So, that's just a few ideas for a way of working that I've been playing about with for the past few months and I hope that people will give me lots of feedback on what they think, what they might add or remove or even if they completely disagree with everything I've said and have good reasons for doing so.

To read more articles like this please visit my website at Warmth on the soul

Love, Jamie

Source: TDHD™ Test Driven Human Design™ | Warmth on the soul

This process is more about gathering information about a person’s life, how they live, who they exist with, what motivates them, what gets them going and what desires, ambitions, goals and dreams they already have, and then from that, calculating what could be the smallest possible change that'll have the largest impact on the entire structure of the person’s life. It's one thing to have someone change how they feel about a specific problem and it's another thing for them to create shifts in their lives that solve multiple issues all in one go and leave them with a happier more fulfilling existence.

Hi Jamie

Great idea, for a while now I have been working with beliefs and belief hierarchies, as I think these are where the crux to change stems from. By finding out the beliefs and values the person holds about (how they view) their immediate family, dreams, friends, work and social environments is the key to discovering what multiple issues need to be shifted and the associated belief cluster or clusters responsible.

It seems our thinking is along the same lines, I am still formulating what tools are going to be the best to achieve this but at this point I am thinking something along the lines of a total quality management (TQM) model used in conjunction Jonathan Altfeld's KE, with the aspects of it that I know.

I am big on using reverse engineering to solve problems, so for me the TDD and your TDHD model are brilliant and seem very flexible and easy to work with. After reading this post, I can see how adding a test before implementing an intervention will be greatly advantageous and time saving.

I am only starting to realise that it is not only Ok but possible to cross pollinate my existing engineering and logistic management skills with NLP to make things easier for myself and others. Oooops, there goes another limiting beliefs .

One point that is still a little sticky, is that when you are working with multiple issues, how do you ensure that the test you create is going to be sufficient to not only test the issue structure you are working with but that the changes will not corrupt or interfere with another structure?

I will take my time a re read your post to fully diggest the idea and post some more in a few days.

Thanks for sharing your wonderful ideas, absolutely great.

Have a great day.


Frederic

Hi Jamie,

A lot for us, including me, to think about. Makes me think of "Solution Focused Therapy" in the first instance - but you present some intriguing and provocative new elements - as is your (admirable) style, so I'll be giving it a more than a passing thought.

For the record, the TOTE model came from the collaboration of three bright, hard-working, and innovative gents, and NLP borrowed it from them. The full credit is:

Miller, George A, Galanter, Eugene, and Pibram, Karl (1960) Plans and the Structure of Behavior, Holt, Rinehart, and Winston, New York, NY.

My other first reaction to your post is to say that I've always internally asked (about clients): "Does their whole life work?" as opposed to "What's your outcome?" - the question the early Grinder limitingly pointed people towards, and which limits weren't entirely overcome by the "well-formed outcome" frame that Dilts and Epstein modelled out of Leslie Cameron-Bandler in 1978-79 (and what a character-revealing point it is that she was concerned with the clients's whole life prospects, and Grinder wasn't).

I asked that question because of the TA "life script" idea. Eric Berne, Claude Steiner, and Jacqui Lee Schiff were pretty sharp cookies too.

I'd also add topical, that the "Advanced Therapeutic Specialist" work of Gabe Guerrero - with a workshop happening 10 days from now - covers a lot of the "problem space" you describe, and addresses many of the same concerns. But since you, yourself, have seen him work, you already know how good it's going to be.

Eric.

Hi Jamie,

As an IT man myself, I dig the way you think. There's lots of rich stuff in your brilliant post.

When I think about tests, I think criteria. (Not to be confused with hierarchy of criteria.) I mean criteria as in, "what boxes do I have to tick for this person?", or, put another way, "what evidence criteria am I testing for?".

When I think evidence, I think of the question, "How will you know things are better for you?"

Is what you're proposing along the same lines as designing your work around the 'criteria' (the "how will you know"?) as opposed to the 'outcome' (the "what do you want?")?

The other brilliant thing I get from your post is something I've also been getting from Eric and Gabe's posts, and something that's been increasingly on my mind since I first learned about the Advanced Therapeutic Specialist track.

That is: that 'outcomes' are potentially just pieces in a bigger structure and it's that whole structure we need to think about.

Much to my great regret - Chris knows knows how great! - I can't be with you on the upcoming Advanced Therapeutic Specialist to learn more about this. I am very disappointed. Not least because it'd be a chance to work with people like you again, as well as Gabe and Eric.

(I'm hoping the event will happen again some time.)

Anyway, my feelings about missing the event aside, if we shift the context from 'outcome' to 'whole structure' - and from 'outcome oriented' to 'test criteria oriented' - that, to me, suggests the question "How will you know your life is better?" as opposed to "How will you know you're getting your outcome?"

My guess is, though, that would be too "big chunk" a question to get a structured list of criteria. Or would it? I'm only playing it through in my head, I haven't tested it.

Either way, how would you involve the client in the process of choosing good test criteria for a 'whole structure' shift without hitting them with a question that may be too universal for them to answer specifically?

Incidentally, I'm taking a chance on looking like a fool with some of my questions - as I sometimes don't get things first time round and maybe I haven't here - but I'm prepared to take the chance because I know you'll forgive me if I do and at least I'll learn something if I do!

Cheers

Steve,

It's a real shame you're not going to be at the Advanced Therapeutic Specialist track. You'll be sorely missed.

With regard to the kind of tests I'm talking about above, It's less about verbal statements and more about what-has-to-be-true and this can occur simultaniously as you're interacting with the client. Remeber though that this isn't just about client work. The same principles and structures can be applied to many other types of work also.

Richard sometimes tells a story about a time when he was selling a car. A guy comes in with his 4 kids and want's to buy a 2 seater sports car. I don't know if you've heard this story but there's something in there that could direct a persons attention towards a way of working that takes into account more about the person than is initially asked for.

I mentioned the topic of depression before so i'll continue to use that example for as long as it seems of use
Lets suppose for a moment that the first peice of architecture that you're going to build is one where the client feels at ease. So you might ask yourself the question "What kinds of things will be true (what can i test for) that will let me know this first peice of architecture is doing what i expect". You might come up with multiple tests at this point which could include the clients shoulders relaxing, more blood flow to the face and neck, deeper breathing, slower eye movement patterns, relaxation of the under eye, a deeper sitting position...and so forth.

So here you know that you've already got 6 tests that you've already set up that right now, fail. The question you'll be asking yourself at this point is "What can i architect that passes as many of these tests in one fell swoop". Now, what I'm describing here is something that many people do naturally already. It's not that this is so different, but what makes it different is the idea that you're tracking what you do as you do it.
There may be a point at which when working with the client, you expect all of these previous tests to still pass, and yet they don't. This is a good indication that something happened with another peice of architecture which did something to something you previously built.

It's very similar to the way bridges are built. You can build the foundations, you can insert the rods and sement the whole lot together so that you have a base to work from, you can put in the struts and the bolts and the bars and everything can stand up just fine.
At each stage of bridge building you'd have resistence and pressure tests on each of the supporting platforms both under and above ground so that at each stage in the development you can see how well the bridge is holding together. Problems with bridges usually occur when some part of the bridge is too rigid to cope withe the environment or too slack that it ends up pulling down the rest of the structure as it sways. The idea that you can put sensors in to different parts of the bridges supports and measure at each point in the building process, how each previous peice is responding, to the continued changes in both the bridge and the environment is a clear sign that the architect knows what he's expecting otherwise the date being presented too him would be lost in the void somewhere.

The other beautiful thing about bridge building is that before any work is started, simulations of each step of the building process are run and computed in order to determine (calculate) what else might also be true.

Now the things I'm talking about here could seem quite techy or small chunk and that's sometimes what happens when you take a process that occurs in a matter of milliseconds and you slow it down enough to write a whole article about it so that you can begin to look at other experiences and notice how this structure will enable you to demolish, architect, build and install new structures that enable people to do things in ways they never thought possible.

Who'd have thought 30 years ago that it's be a reality to build a high rise office block almost entirely out of glass and in the shape of a girkin (pickle)?

That's the thing with architrcture though. One day it's only possible to build square buildings out of square bricks, the next day you discover you can build round buildings out of flat glass. What's next?

This is part of the reason I love the work Gabe is doing, Eric is doing, Chris is doing and coaches like Jenny Waller are doing. Pushing the boundaries of what we think we know is possible and finding out that on the other side of all of this, there is so much more.

I think we're only just scratching off the paint that's on the very tip of the ice berg.

Eric:

Thank you for your comments and thanks for the correction on the TOTE model credit. I'm looking forward to seeing you in 10 days time. It's going to be a lot of fun.

Here's to more learning and discovering a whole heap of things we didn't know about before.

Love, Jamie

Something I've been playing with might have utility in the way you're thinking, Jamie. While TDHD comes from your computing knowhow, this is an approach that stems from what I do as a scriptwriter.

My own mapping of global structures includes something I call 'operational assumptions'. This is a concept I came up with to help me generate characters in stories, and realised emerged from the way I explore non-fictional people...

An operational assumption is one of a person's key game rules in life. Depending on the person they'll vary in chunk size and other respects, but for instances could include 'see how someone else does it before having a go myself', 'if it feels alright to do, it probably is', and 'look at the financial implications'.

Where it gets interesting is when you realise that people have a number of operational assumptions working simultaneously. And that the interaction of those...filters, beliefs, presuppositions, whatever...creates new behaviours, possibilities, and blockages. For instance, what happens when someone whose operational assumptions include 'British is best' and 'time is money' realises that a foreign car runs more cheaply than a UK built one? Or when someone running 'change is good', 'never own more than you can fill a taxi with in ten minutes' and 'approach love with caution' gets involved with a potential partner who they know wants to settle down? You can speculate quite a bit about the possibilities there, which are modified when you take into account the operational assumptions of the partner in question, and so on.

This way of thinking is a fast and dirty way of spotting what amount to the heuristics that people live by. And the questions that their interactions raise, are -- I find -- of value in, to use Jamie's metaphor, creating suitable architecture for successful evolution.

Adrian,

Thanks for replying. You make some interesting points and it's good to see someone thinking in similar ways even if the metaphor is slightly different

Will I be seeing you next week at Gabes course?

Would love to be there with yourself, Gabe, Eric and whoever, but it's not to be...this time round. I'm hoping to make it along to Gabe's course on Installation next year, and the nearer future sees me doing Michael Breen's 3 dayer on Mastering Group Energetics.