So I’m changing approach. From now on, a specification has to be something that runs. This post is a snapshot of my thinking at the start, so I can come back to it and report what actually happened.

The idea: Acceptance Test Driven Development

The approach comes from Dave Farley. What set me on this path was one of his videos, and this passage in particular:

When a machine writes the code, the human’s job is to say precisely what the code should do in a form that can be checked automatically. Not a prompt, not a markdown document, a specification that runs and verifies that the system does what you want it to do. If you don’t know what you want it to do yet, you aren’t really a programmer. You’re just along for the ride.

“Not a markdown document” was aimed squarely at how I’d been working. His short ATDD how-to guide sums it up. An acceptance test is a “business facing” test that also “supports programming”. You write it before any code, and it acts as an executable specification: the work is done when the test passes. Developers then use ordinary, finer-grained TDD underneath to get there.

The guide lists the properties of a good acceptance test. It:

• is written from the perspective of an external user of the system,
• runs in life-like scenarios, in a production-like environment,
• talks to the system only through its public interfaces, with no back doors,
• says what the system does, never how it does it.

Two of its tips stuck with me. First, imagine the least technical person who understands the problem domain reading your test, and make sure it makes sense to them. Second, imagine throwing the system away and replacing it with something completely different. The tests should still make sense. So no “fill in this field” or “click this button”: say “pay by credit card” instead.

Four layers

The structural idea is a four-layer separation of concerns:

If you know the Page Object pattern, protocol drivers will look familiar, but they’re broader. The DSL sits above them, so a scenario written against the web UI can later run against an API driver without changing a word.

Each test also starts from a running system that holds no data of its own, and shares no test data with any other test. My implementation does this by having each test onboard its own practice and giving every name a unique per-test suffix. Tests can then share one running instance and run in any order.

Why this matters more with an AI agent

The guide makes a point that I think is underrated: well-written acceptance tests are a precise language for prompting an AI, and a way to verify what it produces. Here’s the arrangement I’m aiming for:

• I own the test cases. The agent can draft one for me to review, but it can’t change an accepted one without my agreement.
• The agent has full autonomy over the code, including the protocol drivers and how the system is started.
• The tests run outside the coding phase, in the pipeline, as a gate the agent can’t move.

There’s a catch I didn’t see at first. Farley says developers own the DSL and the drivers. Here the “developer” is the agent. If it can change the DSL, it can weaken a check while my test case reads exactly the same. The same goes for test wiring: a pytest hook or a config flag can quietly skip a test without touching it.

The ownership lines therefore have to be drawn more carefully than “specs are mine, code is yours”:

• Test cases: mine, and locked against the agent’s writes.
• DSL and test wiring: the agent writes them, I review every change. Every assertion lives in the DSL, so this is where the meaning is.
• Drivers and system setup: the agent’s.
• The pipeline checks that a new test fails on main before it passes on the branch, which catches a hollowed-out check. It also fails the run if any test was skipped.

Failing first isn’t ceremony. A test that fails before any code is written tells the programmer what the goal is: make this pass. That was true when the programmer was a person, and it’s just as true now that it’s an AI agent. A test that has never failed hasn’t told anyone anything. We all learn by failing first.

Choosing a language

I considered staying in Rust, which is what the app is written in. I also considered C# with FluentAssertions, which I’ve enjoyed using before, and Python. I chose Python with pytest, for three reasons:

1. Optional, named parameters. The guide asks for “optional parameters for nearly everything” in the DSL. Python’s keyword arguments do that directly. Rust needs builder types, which make test cases noisier.
2. A language boundary enforces the public-interface rule. Python code can’t reach into the Rust internals, so the tests can’t take a back door.
3. No new toolchain. C# would have been fine for the DSL, but it would add a third language to the repository for no real gain.

I also moved away from Gherkin. I already had a cucumber suite, and its .feature files read nicely. But their meaning lives in step definitions matched by regular expressions, and those are exactly the files an agent would be editing. A DSL in plain code is more precise, and the line between “spec” and “plumbing” is easier to see.

Here’s the first test case, a port of one of those Gherkin features:

def test_a_rule_matched_payment_with_no_unpaid_invoice_offers_drafting_one(practice):
    practice.has_clinician()
    account = practice.has_bank_account()
    client = practice.has_client("Priya Patient")

    first = account.import_feed(payment(100, payee="PAYMENT RECEIVED", on="2026-04-01"))
    first.payment.link_to(client, save_rule=True)
    first.reconcile()

    feed = account.import_feed(payment(100, payee="ANOTHER PAYMENT RECEIVED", on="2026-04-05"))
    feed.payment.should_be_classified_as_payment_from(client)
    feed.should_not_be_reconcilable()
    feed.payment.should_offer_to_draft_invoice()

    invoice = feed.payment.draft_invoice()
    invoice.issue()
    invoice.should_be_issued_and_unpaid()

    feed.should_be_reconcilable()
    feed.reconcile()
    invoice.should_be_paid()
    client.income_balance_should_be(200)

There’s no URL, selector or button in it. Behind it, a Playwright driver does the clicking, and the suite starts a fresh server with empty data for each run.

One early lesson: my first version of the balance check tested whether the ledger row contained “$200.00”. That would have passed for “$1,200.00”. Precision has to be designed into the DSL.

The why comes first

An executable specification captures what the system must do. The agent decides how. But neither of those makes sense without why. Purpose and context come before the what, and they frame the how.

This is task assignment as described in Systems Leadership, which I’ve written about before. In Ian Macdonald, Catherine Burke and Karl Stewart’s Systems Leadership: Creating Positive Organisations, a well-formed task states its context and purpose, then the quantity and quality expected, and the resources and time available. Within those limits, the person doing the work has discretion over how to do it. That maps closely onto this setup:

• Context and purpose are the why. They sit above any single test.
• Quantity and quality are what the executable specification pins down.
• Resources and time are the limits of the assignment.
• The how is the agent’s discretion, inside those limits.

So the why has to be written down somewhere, and both the agent and I need to be able to read it. Where it fits in the repository, that’s where it should live, next to the specifications that serve it. Some of it sits at a higher level of work, though: a plan or strategy that ties many whats to a single why. That may live elsewhere, but every specification should be able to point back to the purpose it serves. Building software is a system too, and it only works when it sits within a context and has a purpose at each level of work. That’s probably a post of its own.

Questions I’ll come back to

• Does the DSL stay small and domain-shaped, or does it grow into a second application?
• Is reviewing every DSL change sustainable, or does it become the bottleneck?
• How often does the agent push back on a spec, and is it right when it does?

References

• Dave Farley, Acceptance Test Driven Development: How-To Guide, continuous-delivery.co.uk.
• Dave Farley, Modern Software Engineering, Addison-Wesley, 2021.
• Jez Humble and David Farley, Continuous Delivery, Addison-Wesley, 2010.
• Steve Freeman and Nat Pryce, Growing Object-Oriented Software, Guided by Tests, Addison-Wesley, 2009.
• Gojko Adzic, Specification by Example, Manning, 2011.
• Kent Beck, Test-Driven Development: By Example, Addison-Wesley, 2002.
• Dan North, Introducing BDD, 2006.
• Ian Macdonald, Catherine Burke and Karl Stewart, Systems Leadership: Creating Positive Organisations, Gower, 2006 (2nd edition, Routledge, 2018).
• Martin Fowler, PageObject.
• Dave Farley, the video quoted above, Modern Software Engineering on YouTube.
• Modern Software Engineering on YouTube, especially Requirement Specification v User Stories and 5 Common Mistakes in User Stories.

There is a simple test comprising of the following questions we can borrow from Systems Leadership:

1. Do they have a common purpose?
2. Do they have to interact to complete their individual tasks?
3. And do those tasks achieve the common purpose?

Answering no to any of these questions, will predictably lead to effectiveness issues. Because mutual interdependency will not be present. If I am on a train with a group of other people, we share a common purpose, get to work, but we do not need each other to get there. We aren’t a team, we don’t need to collaborate for mutual benefit to get to work. We are only a group.

In an organisation its hard enough to hold a team accountable for their work, its even harder to hold a group. And I’ve seen many teams as poorly constructed groups. Because it is so hard to hold a group to account, the outcomes are often disastrous.

A reality I see is that you can only hold an individual accountable for their work. So when you have a team, it makes sense that a leader is that person we can hold to account. But, and only but, that they then have full authority over how the team works. If they have this authority then they can potentially hold each team member to account.

There are those that believe that a leader is not required. Found in the ideologies of self-managed, self-organised, organic, empowered, non-hierarchical groups. It sounds appealing to advocate freedom to choose work and be autonomous. It is appealing precisely because the alternative is the lack of freedom and autonomy. Often labeled as command and control, bureaucracy, or top down. In my experience, most perceived issues with the management of work is simply mad, bad or stupid leadership.

Many of us have had experiences of poor management and leadership. When that becomes shared it is temping and completely normal to look for the polar opposite. We start believing an idea that we don’t need leaders. This is a dangerous, because an unofficial leader will emerge anyhow.

Under times of stress, complexity, or critical decision making, the team will look to someone to carry the mental load and have the sorts of courage to make difficult decisions. It is in our social nature to discharge this anxiety through someone. If this person doesn’t exist as a clarified and authorised role, an unofficial invitation is up for grabs for someone to steer the team. This is where power rather authority comes to take grip. In some cases this might be ok, often referred to as “rising to the challenge”, but what often happens is problematic uses of power over team members, generating potentially unproductive behaviours. Before we know it infighting is so great that soon there is a team no more.

When a team is operating well the leader is actually hard to spot, not because it is “self-managed”, but because the leader has a developed set of social processing skills that consciously distributes clarity in a productive way. They are fair in holding team members accountable to a social process that maintains a productive bond. On top of this they understand their role and the limits of their authority that come with it. They have clarity of context that surrounds the team and the work they need to do. They understand their purpose and the team’s purpose.

In turn a team member can understand their role and the authority it entails. Understanding and clarifying context is a responsibility of all team members and a team leader is first and foremost a team member to help do this work in a positive manner. It is the quality of the “working” relationships between members, their level of social cohesion, that gets quality work done. Counter intuitive to many of us, it isn’t the technical processes that gets work done. People do. Quality working relationships lead to quality work done.

I’ve experienced some negative feedback from other devs around the track, raising statements that some of those things aren’t cool, or not a pure fanciful functional paradise. From my perspective, I don’t care, so what. It’s the hand that has been dealt. I don’t mind, something like C# is a good OO language. And OO is still cutting it. C# feels like a cross between Java and C++.

I hear Kotlin is rocking along and all the cool kids are doing JavaScript, TypeScript, Go and eat Rust for breakfast, and oh, don’t forget the Python maple syrup. It doesn’t matter what your logic apparatus is, it’s rather the case of what’s appropriate for the job and fits the culture. If you can code with it, solve some real problems with it, get some sense of contribution from it, sounds like it is probably doing its job.

All languages we know of are human inventions. And a company is a collection of those humans emitting a culture. It’s the culture that accepts or rejects a coding language. Programming languages are very rarely chosen for their pure technical wonderment. Someone ultimately makes an arbitrary choice in a political melting pot and it begins. It really doesn’t matter what language it is, they all riff off each other. What matters is your own self-discipline, how you judge your capability and capacity to think, encode that thinking into lines of that software language and learn from it. Software is soft, so be flexible with it.

The problem with just that view is it doesn’t explain what has happened between the gaps over the last 33 years of my working career. I am going to experiment with what I am calling a perspectives CV in my GitHub Repository.

It will be stylised different from my website to denote that its an experimental draft of sorts and then I’ll work out how to incorporate it, or maybe its a simply a silly idea. Let’s see!

I don’t mind trying, my best thoughts at this moment is to split it into the following perspectives:

• Engineering
  • All things software
• Consulting
  • When I’ve been called upon for advice and change work
• Management / Leadership
  • Lead teams, running an area

The common thread in this research was React.

Although I must admit I have a strong interest in Python and Data Science related things, but I figure I’ll come to that down the road.

React comes as no surprise, Lexicon is heavily involved as many other Australian consultancies in this area. Clients are generally going through an upgrade to React cycle.

There are two courses I am aware of:

1. Udemdy coursework
2. Epic React course

I’ve chosen to delay doing them just yet and carefully read through reacts.org, from my Java days I tended to judge the utility of a framework based on the structure, principles, and rationale captured in the Javadocs. Have a good read first, then dive into working on examples. Spring framework and Jetty Servlet container where good examples of this back in ‘00 for me.

At the same time, I’m using ANKI to build a set of flash cards to represent and memorise the core concepts from React.

And thankful the documentation is great! You will need to go deep on the modern concepts of JavaScript, to keep up. So I’ll also build a set of ANKI cards on what I need to absorb with current JavaScript concepts.

My plan is set up an early morning routine of refreshing from flash cards and learning next steps. I’ll capture these efforts also.

No organisation can escape the truth that it can only exist if the things it does is valuable. For value to exist someone has to consider it to be so. So who does? Is it the customers? The shareholders? The board? Leaders or the workers? It is true they all have a view of what value the organisation has. But is it consistent

W. Edward Deming once wrote, “The aim of the system must be clear to everyone in the system”. He was, in part, talking about the purpose of an organisation. In conjunction with his further statement, “The aim is a value judgement”¹. He highlights the link between purpose and value. Purpose has a strong role to play in determining what is valuable. Value is the judgement that validates action and builds cultural norms. Thus it is a thinking construct of leaders and workers. Value is in the mind of the doer.

But value isn’t something that exists in our heads born out of pure purpose. It’s constructed from behaviour. Frederick Herzberg makes a point that, “values are not precursors to behaviour. They are the results of behaviour.” For instance if we look at the Agile Manifesto. Those chaps didn’t construct the values from pure imagination. But from their experience developing software. The behaviour they exercised lead them to a view of what they considered to be valuable. Herzberg can confirm this in a further in his statement. “You develop a behaviour pattern, then you develop an attitude and a value system that justify your behaviour. All values do is enable you to read an environment to see whether your behaviour is acceptable.²” The Agile Manifesto then acts as a high level set of rules to see if your behaviour is acceptable. As we can see values are the building blocks of culture.

Double Meaning

As a word value does not have a single meaning. Which often lends itself, in reference to things, to be used in abstract or concrete ways. For an organisation that poses a problem. If the values of its people are not congruent, productive action will be impossible.

Value also appears as a universal in organisations as money. Not an invention of the organisation, but a civilised way of placing value on goods and services, and therefore on things that are done or made; revenue and costs. Here value is a number, a monetary unit that can have all arithmetic and statistical operations applied. A thing that can be counted.

We can now say there are broadly two meanings of value. The first being a social in nature, what is valued by an individual or group. The oxford dictionary defines it as the regard that something is held to deserve; the importance, worth, or usefulness of something.³ The second, a number; quantity, that is derived from a measurement representing how much on a scale. Both technical and commercial in nature. In the context of organisations these two meanings have something in common, they drive judgement.

Judgement

People have value (qualitative) systems to make judgements about their situation, decide if things are ok or not, raising the intention to take action of some sort. Organisations are made of people and they have to make judgements in their work, about other’s action⁴, and be judged by others. Its essence is about distinguishing important things from unimportant.

Values as quantities are often referred to as data; symbols representing objects and events. A basis for information, much of it stored in IT Systems. In organisations we want useful information on things that are valued; not just any information. But the capability and capacity of these IT Systems has lead to the capture of everything and anything that can be stored. Almost with little regard for why it should. And with that comes claims that it is valuable because of its untapped potential.

Information helps answer questions like who, what, when, where, and how many. For example: How many items are in stock, how many people do we have, how long do they take, percentage of types. Presented in forms like dashboards, reports, charts, alerts, spreadsheets, custom software applications and the like. This information gives us an opportunity to compare. Numbers help rank or order things according to a scale but it doesn’t decide what or why something is important. They are only facts.

In this context of value a philosophical question for organisational decision making emerges. Should we act on what is important or should we act because there is more or less of something? Importance and volume are clearly different. They appear to some as opposite ends of a judgment continuum. What do the numbers say or go with your gut? Numbers hide unknowns.⁵, facts without a story, as explained in the previous paragraph. Using your gut is a metaphor for invoking your value system, albeit unconsciously. In both cases you don’t know why, as much as you might rationalise it. For organisations this judgement can only be derived from purpose. When an organisation knows it’s why at all levels, it becomes simpler for leaders and everyone to decide what is important and what is not.

Exchange

Value is often associated with exchange. Between people we can model an exchange in simple terms of there being a giver and a taker of the thing being exchanged. The giver has a view of value that it produces towards the taker. And the taker assesses the value of what it has received. At each end of the exchange exists a value system held by the people involved in the exchange. The thing of value is exchanged but value does not; it is realised by the beholder. Sometimes the giver will try to validate value with the taker to ascertain compatibility. This can only be achieve at the end of the exchange. What the taker transmits is a semblance to the giver of what they valued. And because of the givers perceived ideals of value, they will never truly approach perfection. What tagoochi called Nominal Value. Simply put, there is much variation in what is and was valuable in any exchange.

Transferring this model to organisations. We can identify he giver as the organisation and the taker as the customer. What is different is that the value system of the organisation is cultural; a social construct. In Mark Schwarz’s book, “The Art of Business Value”, he concludes that business value, simply put, is what the business values. If we assume the organisation is the business, it makes sense to call the value system of the organisation “Business Value”. Further, If we take Mark’s conclusion we can infer that the value system of a customer is called “Customer Value”.

Business and Customer Value

If Business Value is what the organisation values and Customer Value is what the customer values, these value systems must have a symbiotic relationship. But there is a catch. There is no Business Value without Customer Value. No business can be successful without a customer valuing what it produces or the organisation will suffer financial death. Customer Value can live on, finding an organisation that values it. This then leads towards a certain logic. Customer Value is an attitude of Business Value. Business Value must in some minimum way have a view of Customer Value operating within its value system. What a business values has to comprise of elements of what it believes to be valuable to their customers.

A good example of this I found in Edgar Schein’s, Organisational Culture and Leadership.⁶ At Digital Equipment Corporation (DEC), engineers built up certain standards (Business Value) about what customers valued in computers; their attitude to Customer Value. Over time what customers valued in computers shifted as examples of potential computers emerged from other organisations. But the engineers of DEC didn’t alter their attitude toward customer value. As Schein put it: “they (engineers) used their own standards for evaluating what a customer expected; they over-designed them and built in far too many bells and whistles, which made the computers too expensive and too hard to use. The DNA of the DEC culture never changed.”⁷

DEC found out the hard way, that what it valued wasn’t sustainable. With in it Customer Value was frozen. It also demonstrates that what the customer views as important changes over time. It appears then for an organisation to remain viable a primary principle of Business Value must exist: “Value the building of knowledge about what the customer values over time”

Agile

Much of Agile’s commentary has been towards the idea that value is delivered incrementally. And that in Scrum the Product Owner is the arbitrator of value; what is worth working on and what is good enough. The team as such is subjected to proxy to value. This is a combination of what the product owner believes and what they have interpreted from the user. They have to submit to the product owner’s own values and this seems to come about easily. For example I’ve been part of many inceptions where 30 or more stories are produced representing a future wish that has the potential to be valuable not to the product owner but the users of the it. Yet a product owner decides what is most valuable at any given moment.

Conclusion

Value is a critical element of organisational purpose. Without it people who work in them will have to make up their own values leading to misguided effort. Leaders are best positioned to establish and course correct value systems.

1. Unfreezing the current level.
2. Moving to the new level.
3. Freezing the new level.

Edgar augmented this in the following manner (page 299):

1. Unfreezing: Creating the motivation to change.
2. Learning new concepts, new meanings for old concepts and new standards for judgement.
3. Internalising new concepts, meanings and standards.

While reflecting on these observations I started to think about the application of jobs-to-be-done theory, in particular the concept of progress making forces. It led me to ponder that the observations of people change and customer switching are closely related for they have one thing in common, being involved in a situation; the realisation that there is a problem causing motivation to be established. When a person decides to stop doing one thing and start doing another we call this a Switch in jobs-to-be-done language. Combining this thinking with Lewin/Edgar’s stages of change caused me to think that a customer appears to go through three distinct stages within a Switch:

1. New situation arises in their life.
2. Work towards resolving it, leveraging products and services
3. Establish a new way.

To navigate these stages we think of it within jobs-to-be-done as a set of forces. They can be broken into 4 distinct areas and have an impact on each other:

1. Push of the situation.
2. Attraction of the new.
3. Anxiety of the new.
4. Habit of the present.

Forces 1 and 2 are progress generating (pushing forward) whilst 3 and 4 are resistive in nature (pulling back). Edgar Schein groups these forces in anxiety terms:

1. Survival Anxiety - Must do something, learn what it is.
2. Learning Anxiety - Unlearning something so it can be learned.

My perception is that the progress generating forces in a Switch are the same components we can find in Survival Anxiety. In that for a person (customer) to survive they must actually learn something and likewise the resistive forces are akin to Learning Anxiety; the confrontation that a person will have to unlearn something. In social or group settings this threat is quite alarming. It’s easy to learn new things when there is no unlearning and explains why it is easier when we are younger to learn as we simply have nothing to unlearn! We tend to find it hard to give up present habits, for those very habits are learned and must be unlearned if we are to make the Switch. Unlearning can generate a complex set of emotions which can cause all sorts of defence mechanisms to kick in.

When studying the four forces through the perspective of jobs-to-be-done we learn that the progress generating forces always come with a side-effect; the more you focus on them the more resistive forces you potentially generate. It is as if you are stretching the customer further and further away from their old habits that has them unconsciously more and more concerned. Edgar Schein describes the same relationship between Survival and Learning Anxiety, outling two principles for transformative change aka Switching:

Principles

1. Survival anxiety (progress making forces) or guilt must be greater than learning anxiety.
2. Learning anxiety (resistive forces) must be reduced rather than increasing survival anxiety.

I believe these schools of thought overlap and blend nicely so I have created a hybrid diagram displaying the dynamics of change for a person which in turn is a customer.

Some background to our situation; we are staying in Sydney with my sister and her family in Bondi Beach. We all wanted to be together at Christmas, by the end of the first day my partner asked if I would go shopping with her for paternity clothes. We are 6 weeks into our first pregnancy and I thought it was a little early to be purchasing clothes when the oven hasn’t really expanded yet. I’m a confused partner, we just arrived in Sydney, great weather, at the beach, we had both talked about wanting to relax during the break and stay away from the crowds. So I wasn’t going to ask any confronting questions, merely listen and observe for the day.

I remember hearing a podcast with Clay Christensen talking about how Jobs-to-be-done had help his relationship with his wife, instead of having a confrontation on matters between them try and understand the causality of it.

Leading up to this moment of standing around was lunch, I suggested if we are going to look at clothes for the rest of day let’s get something to eat. We ended up at the David Jones food bar in the basement, it was a great experience she was happy I was happy, all is good. We then wondered up through the other floors and for some reason my partner was keen for myself to try out some new clothes, but I thought we had recently talked that I have enough at the moment. Initially I went along with it but then I had to say something, “I can’t see anything I need I’m not in that frame of mind, I’m here to help you.”

So I’ve been standing around while my partner is selecting clothes to try out, answering her questions, do I like this one or that one, I noticed the clothes aren’t paternity type and the amounts she is eying off we definitely haven’t budgeted for, from my outside perspective it looks random, but something is driving it. I ask politely “It seems like you have quite a few non-paternity clothes there.” She stopped and smiled at me, “But I get time to spend with you, you know how to help me so well, but I did need to get out of where we were staying, being with your family brings back a lot of emotions for me, I’m not with my family in Brazil, and you seem to give your family a lot of attention and forget about me.”

“Oh no! Now I know why we are here”, I thought. We aren’t here to buy clothes, we are escaping from something, perhaps a remedy to the feeling of a lack of attentiveness on my behalf? Maybe I’ve been doing something wrong or simply emotions are running high at this time of year, is this what we might call retail therapy? So I decided to tweet:

At the shops looking at clothes with my partner today, why we are here has nothing to do with the function of clothes #JTBD

When I posted the tweet I realised I was doing something I recall Ryan Singer mentioned in a tweet:

What if Twitter is just a place to say things that nobody in your actual vicinity is interested in hearing? #JTBD

We did end up buying some clothes, but I think that it was more out of a need to complete the day. Being aware of your situation is definitely nothing new in human nature, but I do find jobs-to-be-done has s

In the day to day of getting things done There are those times when you happen to trip into an argument over a point, process, strategy, technique or idea. You don’t mean to come across this way, it’s just that you feel like you have something to bring to the table and don’t want to miss the opportunity. A feeling of confidence, quite rightly so, you think you’re the expert, been there before, you know what to do.

But wait a moment, did you just notice the body language of the client. They’re showing little interest in you and what’s being said, defensive to your suggestions, they cut you off. So you try harder, get a little emotional about their lack of interest or position; maybe you think “Can’t they see what I see? Just do what I say?”

It’s a frustrating moment, so how could we avoid these types of situations?

A method I use is an invitational check, simply put I ask myself; “Do I have an invitation to talk through the advice I have in mind?” The invitation is a metaphor for trust and without it your advice is worthless. I’ve learnt this the hard way in my early days assuming that because the client hired me, surely they trust me already? In reality the client has only opened the door to building trust. Advice to a client is only valuable if it comes from a trustworthy source. To avoid the above scenario is to be conscious of your trust building methods and not how cool your advice is.

What does building trust look like?

They are many possibilities to what this would look like, context will be the determining factor. However a model I have found universal and independent of contexts is the Skilled Helper Egan Model

In this model building trust is to focus on the problem and the connected opportunities, as seen by the client, it’s important that you empathise with what the client knows and feels about that knowledge; perspective is key. I’ve learnt that it helps, as a starting point, to get things out on the table, ask them about what they are seeing.

It then opens the door for the client to talk about their stories in relation to the problem. Quite often story telling around the problem leads to new truths for the client as related stories pop up, your understanding and empathy to these stories will strengthen your relationship. As the stories emerge ask for situational specifics, thoughts, behaviours and emotions. Here you are seeking clarity, replaying what you understand and using the client’s language, remembering to stay in their world without correcting them; let their own words emerge onto the opportunity canvas.

The more clarity in the story the sharper the actions will be on what to do next. The “what to do next” is where you can ask great questions like “So what might be keeping you from doing what you want to do?” and “What options have you considered?”. I have found, surprisingly, these open helpful like questions will generate invitations for advice to get your expertise leveraged.

Trust doesn’t happen overnight, but I would rather a client have my trust than risk appearing arrogant and unhelpful to their situation.