Skip to main content

Express, Listen, and Field

Last weekend I participated in the LLandegfan Exploratory Workshop on Testing (LLEWT) 2024, a peer conference in a small parish hall on Anglesey, north Wales. The topic was communication and I shared my sketchnotes and a mind map from the day a few days ago. This post summarises my experience report. 

Express, Listen, and Field

Just about the most hands-on, practical, and valuable training I have ever done was on assertiveness with a local Cambridge coach, Laura Dain. In it she introduced Express, Listen, and Field (ELF), distilled from her experience across many years in the women’s movement, business, and academia. 

ELF: say your key message clearly and calmly, actively listen to the response, and then focus only on what is relevant to your needs. I blogged a little about it back in 2017 and I've been using it ever since.

Assertiveness

In a previous role, I was the manager of a test team and organised training for the whole team in our office during working hours to help people to use their training budget, which most did not take full advantage of, and let the team spend time in each other's company not working. 

I blogged about it in Talking Shop, noting that I never wanted training to feel like something imposed on the team, so (a) I attended too, as a peer, and (b) the whole group had input into the topics we wanted to cover. 

We usually ran training workshops on a single day but, when it came to the assertiveness course, Laura asked if we could instead do two half-days so that she could equip us with communication tools in the first and then come back to review how we'd been getting on with them, and provide additional feedback and advice, in a second. This worked well for us.

Two aide-memoires from the training have stuck with me:

  • ABCDE: assertiveness is about being calm, direct, and equal
  • ELF: remain assertive by expressing, listening, and fielding

Tactics

Assertive behaviour is expressing yourself in a calm and clear way, regardless of your relationship with the other person, and standing up for yourself without being defensive, aggressive, or manipulative. It tends to be most applicable in conversations where something important is at stake, such as a pay rise, a difficult decision, or when delivering or receiving bad news. Being assertive can prevent conversations getting derailed or blowing up in unproductive ways.

ELF is a micro framework for implementing assertive behaviour. It has three steps:

  • Express: say your key message briefly, clearly, and with a justification. Note that your key message can change during an interaction, depending on what the other person says.
  • Listen: actively listen to the other person, and more generally observe their tone and body language too.
  • Field: Take only what is relevant to your key message from their response. Acknowledge the rest, but put it in the conversational bin.

Getting to your key message is, well, key and fortunately it is something that you can practice outside of any conversation. Any time you want to express anything, you can ask yourself: what is the thing I want to say, and how can I explain the essence of that thing briefly and simply without compromising it? This works for verbal and non-verbal communication and sometimes the answer is to change your mode and e.g. switch from talking to drawing or highlighting patterns in a table of data.

Over the years I have come to think of ELF as a tactical tool, one which helps me to deliver my wider strategy. I realise that I probably sound calculating when I write it this way. In practice it's rarely so clinical or coldly functional but I definitely do not underestimate the value of being intentional with communication. 

Strategy

If ELF is tactical, for the strategy I rely on the notion of congruence where, as I interpret it, the aim in interactions is to balance the interests of yourself, the other person, and the context. I first came across this in the writings of Jerry Weinberg, and found it an extremely handy guide, or perhaps meta-guide. 

As a manager I found myself having many interactions with people that required tough choices and typically played off those three interests against each other. When someone asked me for something at work I might break down the considerations this way:

  • other: they want some privilege and their reasoning is sensible. Giving it to them would make them happy while turning it down might affect them adversely.
  • self: giving a privilege to one person might cause pain to me in having to justify it today or argue that it's not a precedent tomorrow.
  • context: the rest of my team might feel let down by me, jealous of the person with privilege, angry that their own previous requests were not granted.

If, over time, I tend to sacrifice self in this kind of equation I risk affecting my own mental health, opportunities, or self-esteeem. Alternatively if I prioritise self  I will tend to be thought of as selfish. If I regularly give most importance to other I might be thought of as a soft touch, but if I don't I might get a reputation for being inconsiderate.

Congruence doesn't give me an algorithm for making the decision, but it helps me to remember to consider a range of important factors and pushes me to a look for equitable paths through the solution space. 

I additionally slot in the Satir Interaction model, due to Virginia Satir, a four-stage pipeline which overlaps with ELF at the express/respond and listen/intake steps but adds a couple of "internal" steps: meaning and significance. These help to break down the information we have in two important ways: what information do I perceive, and how does that make me feel?

These are important in deciding what to do next towards whatever the right-now goal is — including changing the goal if the information merits it — governed by the overall, general, goal of congruence. 

The Whole

If this looks overcomplicated, it's worth remembering that it is only a fragment of the full communication story ... and it's happening on both sides at the same time all the time. The picture below tries to reflect that and also represents biases and the external channel through which messages must pass. 

 

This picture doesn't attempt to represent other absent features such as the fact we'll naturally miss some of the incoming information, mistake some of it for something else, not translate our thoughts to words precisely, and so on. For what it's worth, I think of the noisy channel as covering all of the other stuff to some approximation. 

In Practice

In spite of any shortcomings due to oversimplification, I have found the E, L, F, E, L, F, ... cycle incredibly easy and beneficial to keep in mind during interactions. Visualising it as fitting into the other two models increases the value for me, if only by encouraging me take a beat to consider my response before expressing it.

Here's a fictionalised interaction that reflects my experience. The scenario is that Robert has been on my team for a while and is present at work and appears to be busy, but is not delivering finished work on time or to a reasonable standard. 

We have spoken about this, he appears to understand the situation, he has agreed to make improvements and has been given time for that. At the time of this exchange, he knows that he is close to being sacked but he has not obviously changed anything nor made any obvious effort to change.

Me: Hi Robert, thanks for coming to the meeting. I outlined the topic in my email and we've spoken about this many times already so I'll get straight to the point: your performance has not improved in the way we agreed that it needed to, and so we're letting you go.

Robert: That's a surprise to me, I have been trying really hard to do the things you asked of me but they are totally unreasonable in my opinion. It is not easy to get up to speed in this complex environment, the product is documented poorly, and the rest of the team don't help me. I think I have improved and I can improve more you just need to give me more support and more time. It's really unfair how I have been treated and I told you this several times before but you're not listening.

Me: I accept that you feel you are trying to improve and I'm sorry about the other things that you mention, but we are now past the point where this is negotiable. I'm afraid that we are letting you go. Your last day will be tomorrow.

Robert: What kind of company is this? You are the one who should be being let go. You should never have permitted me to get into this situation. It is your lack of support for me that has put me in this position in the first place. I can do much better than this but your attitude and working practices stop me from doing a good job. You need to change. You suck!

Me: That may be true and we have talked about some of those things already, but unfortunately it's too late now to discuss them further. You are sacked and you should tidy up anything you are currently working on. Tomorrow I will need you to return your laptop.

Robert: But what about my family? My partner is not earning at the moment because she has been finding it so hard to get a job and we have a baby to feed and clothe.

Me: I understand that this is a serious and difficult situation, and I hope I have shown over the last months that I am sympathetic, but unfortunately you have not done what we agreed and so tomorrow will be your last day here.

Robert's points may be valid — although none of this should have been a surprise — but, given where we are, they are not going to change my mind. ELF helps me to not be distracted from what I need to say on this occasion. 

In earlier conversations, my key message might change based on what Robert says, for example to explore some of the issues that he perceives. That's OK. ELF does not force you to stick to one line throughout an interaction. In fact, the active listening encourages you to really hear what the other person is saying in case it can make a difference to you.

But ...

... ELF does not always work for me. I have a difficult family situation which leads to many constraints on us, a great deal of tension, and regular difficult conversations. I have discovered various reasons for times when ELF can't or doesn't add anything for me:

Physical condition: I find that there are times where I am just too tired to engage well and I apply ELF sloppily or not at all, even though it would be possible and appropriate to use it. We have mitigated this risk by scheduling a couple of times each a week to talk. This does not mean that no conversation can take place at other times, but does mean that we can be prepared to talk, and not drop big topics on each other at unhelpful times.

Emotional involvement: I found that I have not always been congruent and in particular I have deprioritised myself. Initially I did this unconsciously which lead me to an unhelpful place, but it is interesting the mechanics of ELF were still functioning despite that. The problem was that my key message was not a good message for me. I had therapy which gave me some coping strategies and this is no longer such a problem for me.

Communication channel: for various reasons I ended up doing the therapy by phone and was interested to observe that the narrow channel did not seem to compromise the communication and may even have enhanced it. Without the richness of visual cues and high-resolution sound when speaking and listening there was more focus on simply hearing and expressing. However ...

Conversational context: ... it occurs to me as I write that I rarely thought about ELF during therapy. I mentioned it to my therapist as an approach I find valuable, but it was not something that I was deliberately employing during sessions. Maybe because I was doing a lot more expressing than listening most of the time.

Unreliable participant: if the other party cannot be relied on in their communication, then the meaning and significance steps become difficult to process. ELF can operate but the foundations of the interaction are shaky.

Uncooperative participant: if the other party is not communicating at all then there can be no listening and the cycle breaks. In this situation, ELF has no opportunity to provide a way to navigate the communication effectively. In my family we've resorted to other means, such as asynchronous written notes.

Summary

So that's ELF for me: Express, Listen, and Field. It's a tactical mechanism for greasing conversational wheels, particularly in situations where assertiveness is important, but there are scenarios in which it might not apply, might be applied poorly or without effect, or will have no opportunity to be applied. Through intentional practice you can begin to get a sense of where and when it can make sense for you.

Disclaimer: I am not expert in any of the models I have described. I have consciously taken from them the pieces that feel helpful and composed them in a way that I find intuitively comfortable. This is an informal reading that works for me at the moment. I hope it can be helpful for you in some way too.

Acknowledgements

I'd like to thank and credit the organisers and other participants at LLEWT: Christ Chant, Joep Schuurkes, and Elizabeth Zagroba; Maaike Brinkhof, B Mure, Duncan Nisbet, Vernon Richards, Oliver Verver, Ash Winter, and Neil Younger. 

Special thanks to Maaike and Oliver for lending me the iPad and pencil to sketch along while I talked. Readers should be relieved that the images in this post are not the scribbly messes I made on the day.

Extra special thanks to Laura who provided me with the ELF handout that she uses in her training and references she has used extensively herself and recommends to others who want to improve their communication skills:

Comments

Popular posts from this blog

Meet Me Halfway?

  The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "Stop answering my questions with questions." Sure, I can do that. In return, please stop asking me questions so open to interpretation that any answer would be almost meaningless and certa

Can Code, Can't Code, Is Useful

The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "If testers can’t code, they’re of no use to us" My first reaction is to wonder what you expect from your testers. I am immediately interested in your working context and the way

The Best Programmer Dan Knows

  I was pairing with my friend Vernon at work last week, on a tool I've been developing. He was smiling broadly as I talked him through what I'd done because we've been here before. The tool facilitates a task that's time-consuming, inefficient, error-prone, tiresome, and important to get right. Vern knows that those kinds of factors trigger me to change or build something, and that's why he was struggling not to laugh out loud. He held himself together and asked a bunch of sensible questions about the need, the desired outcome, and the approach I'd taken. Then he mentioned a talk by Daniel Terhorst-North, called The Best Programmer I Know, and said that much of it paralleled what he sees me doing. It was my turn to laugh then, because I am not a good programmer, and I thought he knew that already. What I do accept, though, is that I am focussed on the value that programs can give, and getting some of that value as early as possible. He sent me a link to the ta

Beginning Sketchnoting

In September 2017 I attended  Ian Johnson 's visual note-taking workshop at  DDD East Anglia . For the rest of the day I made sketchnotes, including during Karo Stoltzenburg 's talk on exploratory testing for developers  (sketch below), and since then I've been doing it on a regular basis. Karo recently asked whether I'd do a Team Eating (the Linguamatics brown bag lunch thing) on sketchnoting. I did, and this post captures some of what I said. Beginning sketchnoting, then. There's two sides to that: I still regard myself as a beginner at it, and today I'll give you some encouragement and some tips based on my experience, to begin sketchnoting for yourselves. I spend an enormous amount of time in situations where I find it helpful to take notes: testing, talking to colleagues about a problem, reading, 1-1 meetings, project meetings, workshops, conferences, and, and, and, and I could go on. I've long been interested in the approaches I've evol

Not Strictly for the Birds

  One of my chores takes me outside early in the morning and, if I time it right, I get to hear a charming chorus of birdsong from the trees in the gardens down our road, a relaxing layered soundscape of tuneful calls, chatter, and chirrupping. Interestingly, although I can tell from the number and variety of trills that there must be a large number of birds around, they are tricky to spot. I have found that by staring loosely at something, such as the silhouette of a tree's crown against the slowly brightening sky, I see more birds out of the corner of my eye than if I scan to look for them. The reason seems to be that my peripheral vision picks up movement against the wider background that direct inspection can miss. An optometrist I am not, but I do find myself staring at data a great deal, seeking relationships, patterns, or gaps. I idly wondered whether, if I filled my visual field with data, I might be able to exploit my peripheral vision in that quest. I have a wide monito

ChatGPTesters

The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00--  "Why don’t we replace the testers with AI?" We have a good relationship so I feel safe telling you that my instinctive reaction, as a member of the Tester's Union, is to ask why we don&

Postman Curlections

My team has been building a new service over the last few months. Until recently all the data it needs has been ingested at startup and our focus has been on the logic that processes the data, architecture, and infrastructure. This week we introduced a couple of new endpoints that enable the creation (through an HTTP POST) and update (PUT) of the fundamental data type (we call it a definition ) that the service operates on. I picked up the task of smoke testing the first implementations. I started out by asking the system under test to show me what it can do by using Postman to submit requests and inspecting the results. It was the kinds of things you'd imagine, including: submit some definitions (of various structure, size, intent, name, identifiers, etc) resubmit the same definitions (identical, sharing keys, with variations, etc) retrieve the submitted definitions (using whatever endpoints exist to show some view of them) compare definitions I submitted fro

Vanilla Flavour Testing

I have been pairing with a new developer colleague recently. In our last session he asked me "is this normal testing?" saying that he'd never seen anything like it anywhere else that he'd worked. We finished the task we were on and then chatted about his question for a few minutes. This is a short summary of what I said. I would describe myself as context-driven . I don't take the same approach to testing every time, except in a meta way. I try to understand the important questions, who they are important to, and what the constraints on the work are. With that knowledge I look for productive, pragmatic, ways to explore whatever we're looking at to uncover valuable information or find a way to move on. I write test notes as I work in a format that I have found to be useful to me, colleagues, and stakeholders. For me, the notes should clearly state the mission and give a tl;dr summary of the findings and I like them to be public while I'm working not just w

Make, Fix, and Test

A few weeks ago, in A Good Tester is All Over the Place , Joep Schuurkes described a model of testing work based on three axes: do testing yourself or support testing by others be embedded in a team or be part of a separate team do your job or improve the system It resonated with me and the other testers I shared it with at work, and it resurfaced in my mind while I was reflecting on some of the tasks I've picked up recently and what they have involved, at least in the way I've chosen to address them. Here's three examples: Documentation Generation We have an internal tool that generates documentation in Confluence by extracting and combining images and text from a handful of sources. Although useful, it ran very slowly or not at all so one of the developers performed major surgery on it. Up to that point, I had never taken much interest in the tool and I could have safely ignored this piece of work too because it would have been tested by

Build Quality

  The Association for Software Testing is crowd-sourcing a book,  Navigating the World as a Context-Driven Tester , which aims to provide  responses to common questions and statements about testing from a  context-driven perspective . It's being edited by  Lee Hawkins  who is  posing questions on  Twitter ,   LinkedIn , Mastodon , Slack , and the AST  mailing list  and then collating the replies, focusing on practice over theory. I've decided to  contribute  by answering briefly, and without a lot of editing or crafting, by imagining that I'm speaking to someone in software development who's acting in good faith, cares about their work and mine, but doesn't have much visibility of what testing can be. Perhaps you'd like to join me?   --00-- "When the build is green, the product is of sufficient quality to release" An interesting take, and one I wouldn't agree with in general. That surprises you? Well, ho