Mark Needham

I recently came across a really cool blog post by Dr Nic titled ‘How to stop killing people with your public speeches‘ where he talks about the importance of practicing our presentations so that they actually make an impact on our audience.

Towards the end of the post he suggests joining Toastmasters as a useful first step for getting used to speaking to a group of people and as an added bonus you get feedback after each speech you give.

When I finished university in 2005 the one thing that I feared above all else was speaking in front of a group of people.

At the time I was an avid reader of Steve Pavlina’s blog and in one of his posts he recommended Toastmasters as a way of overcoming the fear.

I attended Toastmasters sessions every fortnight for about 18 months in 2006/2007, getting through 7 of the 10 speeches, before I decided to go off and learn open mic standup comedy, but that’s another story.

It’s a really safe environment to practice in because it doesn’t matter if you make mistakes and the other people are there to help you improve.

Apart from getting comfortable speaking to a group, the main thing I learnt from Toastmasters is that it’s much more fun doing a speech if you can see that the audience is engaged.

In order for that to happen that meant that I needed to write a speech which I found fun to deliver, an approach which can be applied to any presentation that we give.

In my case this means that there has to be some sort of humour in the talk but I imagine this may be different for other people.

A couple of years ago while I was preparing for a presentation I was going to give to the Sydney ALT .NET user group, Erik Doernenburg suggested to me that the talk would be more interesting if I put a personal spin on it and told it as a story.

I found that it was actually much more interesting to prepare the talk once I took this approach and it was easier to present since I was framing the talk as being about my experience rather than (implicitly) claiming to be an expert of some sort.

When I started at Toastmasters I used to write out my whole talk word for word but now I tend to have a rough outline in my head which leaves some room to ad lib depending on how it’s going.

I now feel really comfortable in front of a group of people so I’d certainly second Dr Nic in recommending Toastmasters as an excellent way of overcoming any fears of public speaking and honing the skill.

Useful resources

When I was a trainer at ThoughtWorks University presentations Sumeet recommended the following books which I think are worth reading:

• The Presentation Secrets of Steve Jobs – How to be Insanely Great in Front of Any Audience
• The Naked Presenter – Delivering Powerful Presentations With or Without Slides
• Brain Rules – 12 Principles for Surviving and Thriving at Work, Home, and School

In Discussing the Undiscussable William Noonan describes the ladder of inference, a tool which can be used to help us achieve double loop learning with respect to our interactions with other people.

Ladder of Inference helps people identify what information or facts are used as the basis for their reasoning process.

It also helps people understand how they interpret that information and how they apply their interpretation to the issue or problem at hand.

Essentially, the Ladder of Inference is a metaphorical tool designed to help people understand and describe their use of inductive reasoning. Given what we see, what conclusions do we draw?

The book mainly describes the ways that we end up climbing the inference ladder ourselves but I’ve been thinking recently that it’s quite interesting to know that in all likelihood that’s how other people are thinking about the things that we do.

One of the main examples of people climbing the ladder of inference in an ‘agile’ context is when somebody comes late to the standup in the morning.

The other members of the team often jump up the ladder and come to the conclusion that the late person is lazy/doesn’t care about the project or their time and is generally a bad person, all before finding out why they were late!

The ladder climbing gets even worse if the person is a serial offender and even though it’s unfair to that person, it’s unlikely that you’re going to be able to get all the other people in the team to change their way of thinking.

It therefore makes sense to be aware that people may be making these inferences about our behaviour and perhaps adjust the way we act accordingly.

Sumeet and I were recently discussing the difference between the use of Google Groups for internal communication compared to the Jive platform which we’re now moving to and I suggested that I found the former more intuitive to use.

Sumeet suggested that the word ‘intuitive’ is quite overloaded and later pointed me to an article on the Moodle website which advocates the same thing:

Intuitive is a word you should avoid in discussions of usability as its meaning is often confused.

It is generally accepted that a large part of usability is based on familiarity and experience.

Using ‘intuitive’ as a short-hand for something that is familiar often gives the impression that if something is ‘intuitive’ then it is so regardless of prior learning or experience and therefore equally true for everyone.

While the article is technically correct, from my experience it’s very difficult to get people to change the language that they use and to tell them to not use certain words is likely to provoke a defensive reaction.

I’ve found it more useful to look beneath the language used to work out exactly what is meant by the word since that’s what you’re really interested in.

In my case the use of the word ‘intuitive’ means that the way Google Groups works is exactly the same as other mailing lists that I’ve used previously.

Therefore when we moved to using Google Groups internally about 15 months ago it was really easy for me to understand how to use it.

The steps are pretty much:

• Search for mailing list I’m interested in
• Subscribe to mailing list
• Messages on that mailing list come to my inbox
• Job done!

With Jive the ‘algorithm’ has to be a bit different because you’re initially met with a new feed which contains absolutely everything that people have posted.

It’s conceptually the same as being met with the twitter stream for every single person using twitter.

The only difference I can really see between twitter and Jive is that twitter doesn’t default to having every single item on your stream, you have to build it up yourself.

That was pretty similar to the metaphor being used by the Facebook news feed which I was already familiar with and could therefore get the hang of very quickly.

On the other hand I’ve found it more difficult to work out how to reduce the noise on Jive so that it would only contain information I’m interested in.

It would probably be possible to find some documentation that would explain what I need to do but I like it better when I can work out how to use something myself without external help.

Maybe it’ll just take me a bit longer to work out how to use Jive and then it’ll be as intuitive to me as Google Groups and twitter are.

For further reading, Jared Spool has an interesting article where he goes into much more detail than I have about what makes a design seem to be intuitive.

The first time I came across the Pecha Kucha style of presenting was at the XP 2010 conference during the Agile Suitcase session where Pat Kua and some others talked about the practices, principles and values they most favoured.

I’ve never done one before but as part of the preparation work for ThoughtWorks University each of the trainers had to prepare one which we then presented to each other yesterday.

Despite the format being different than a normal presentation I still think the general idea of presenting any information applies – if you can tell it as a story then you have a much greater chance of keeping people’s attention.

This was advice that I first got from Erik Doernenburg almost 2 years ago when I was preparing to give an F# presentation.

I guess everyone has their theories and guidelines of what makes a good presentation but for me the underlying idea is that it has to be fun for me to present.

If it isn’t then it’s going to be really difficult for it to be fun to listen to.

These were some of the things I learnt from the whole process:

Preparation

• I generally don’t like rehearsing exactly what I’m going to say because I think it makes the presentation a bit less fresh when you actually do it. In this case however you need to have a reasonably good idea of how much you can talk in 20 seconds so it makes more sense.
• A side effect of doing this was that I realised how much I had originally planned to cram into some of the slides and was therefore able to split some of the narrative out onto another slide.
• Most of the ideas around slide design came from the Presentation Zen presentation that Sumeet gave us earlier in the week. I haven’t read the book but from what I’ve heard it seems to give some pretty good ideas for making slides engaging.

Delivery

• I tend to improvise quite a bit when presenting so I often throw things in that I think of at the time. The problem with doing that in a Pecha Kucha is that it can ruin the timings that you’ve practiced beforehand!
• I looked back at the slides way too much which I only realised from watching the video that Sumeet had recorded.

  I think it’s a bit of an instinct because in a lot of presentations I’ve done you want to point out something which is on the slide.

  In this style of presentation it was unnecessary.

• People interpret images differently – even with an audience of just 7 or 8 it was noticeable across the different presentations that some people understood or could relate to the images used by the presenter and some couldn’t! I’m not sure exactly how you get around that problem.

Overall I think this is a really cool presentation style and one that I think should be used more often.

Someone actually suggested we should get the ThoughtWorks management to give their monthly update reports in this format which would certainly be fascinating to see.

Earlier in the year I wrote about Chris Argyris’ espoused theory and theory in action and one of the interesting aspects to it which I hadn’t previously considered is how we treat people when their espoused theory and theory in action don’t match.

My tendency is to think that these people are hypocrites but Benjamin Mitchell pointed out in a conversation on twitter that it’s not really helpful to think that way:

Benjamin:

I find it hard to accept that other’s can’t see the ‘obvious’ gap I can between what they say and what they do (cf fund. attribution error)

Me:

@benjaminm I have the tendency to believe they are a hypocrite but I think it’s just an espoused theory/theory in action gap

Benjamin:

@markhneedham I think that’s the challenge I’m finding: allowing that people have a gap they are blind to, and not punishing them for it

A typical example where I’ve seen this happen is where someone (we’ll call them person A) teaches a group of people how to give effective feedback, probably by following some of the ideas from Pat Kua’s ‘Tightening the feedback loop‘ presentation.

The implicit assumption in the people being taught is that since person A taught them how to give feedback, person A should be able to give feedback perfectly every time.

Almost inevitably that tends not to be the case and there will be a time when person A ends up giving feedback which isn’t effective and is more a reflection of them than the person they’re supposedly trying to help!

If person A is working in a reflective mindset then hopefully they’ll realise their mistake and work on closing the gap between their espoused theory and theory in action.

If that doesn’t seem to be happening then we need to describe our observations to person A, discuss those observations and help person A improve.

A substantial part of William Noonan’s ‘Discussing the Undiscussable‘ is devoted to coming up with ways that we can deal with these conversations more effectively.

The learning from this for me is that just because someone teaches you something or talks about a topic very passionately that doesn’t mean that they’ve have to be perfect at it!

I realised a couple of weeks ago while pairing with a colleague that I’ve become quite bad at interrupting people while they’re speaking.

I did have an inkling that I’d let my ability to properly listen to someone drift a bit but I hadn’t seen any evidence until my colleague pointed it out.

Somewhat ironically I actually wrote a post about active listening when I first started working at ThoughtWorks in 2006 and reading back over the listening barriers that I listed I realise that there are a few that I tend to break:

Filling-in: You don’t let the other person finish her sentence; instead you finish it for her.

Daydreaming: You get triggered by something the other person says and you’re off in your own world. You don’t have a clue what the person said to you.

Rehearsing: Rather than listening, you are mentally preparing what you are going to say. You might look interested, but you’re really concentrating on planning how you’re going to respond.

I find it really hard to understand what someone is saying purely by the words so I create images in my head based on what’s being said.

My tendency is then to just say what I’m thinking without actually realising that I’m going to interrupt the other person.

Of course that’s because I wasn’t totally listening because I was visualising what they were saying.

I feel that I still need to do this in order to understand what someone is talking about but I’m practicing keeping my thoughts to myself and then vocalising them if necessary when the other person has finished speaking.

The challenge for me is that when I try really hard to not break any of these barriers I’ll often end up being pretty silent when the person is speaking to the point where it might seem that I’m not interested in what they’re saying.

Something which I’ve noticed recently in particular when interviewing people but also in some other situations is that frequently posing a question which begins with ‘why’ results in quite a defensive response.

While discussing this with Priyank he pointed out that asking a question in this way can often be construed as a criticism of the idea being questioned.

Admittedly it is often the case that I’m questioning something which has been done differently than what I might have done but I’m still curious as to the reasoning behind it.

Unfortunately this style of questioning often stops any reasonable discussion from happening which isn’t my intent.

I’ve been reading Sleight of Mouth recently which suggests the following:

Why questions, for instance, often presuppose other judgments, which can lead back into conflict or disagreement.

…

In general, ‘how’ questions are most effective for refocusing on an outcome frame or feedback frame.

William Noonan has a similar thing to say in Discussing the Undiscussable:

Quality inquiries generally don’t use Why questions because such queries tend to make listeners feel pressured to prove their point or justify their position.

…

Asking questions starting with “What,” “Where,” and “How” elicit more descriptive responses, and result in more concrete information.

To give a recent example, in India people are currently collecting feedback and one part of it requires the feedback giver to rank the other person in terms of how well they ‘performed’ compared to what the feedback giver expected.

I asked why it was necessary to do that and didn’t really manage to discover the intention very successfully.

Priyank suggested that I might have been more successful if I had asked ‘what’ the intention of ranking the person was instead.

Hopefully I’ll remember that the next time I want to inquire about something but at the moment the ‘why’ question is the one that comes to the fore when I want to do that.

I don’t think it is necessary to use what is a bit of a convoluted style of communication with everyone.

A lot of the people I’ve worked with are quite comfortable with ‘why’ questions being thrown around and I think this style of inquiry is more acceptable when you have trust with the other person.

If the conversation isn’t about something which could be construed as criticism of either person then asking ‘why’ seems to be fine as well.

One of the things that has been puzzling me during my time in India is the amount of time that is spent in meetings pushing information to people rather than them pulling it.

In previous projects that I’ve worked on a lot of the knowledge was moved between around as a result of osmotic communication

Osmotic communication means that information flows into the background hearing of members of the team, so that they pick up relevant information as though by osmosis.

This is normally accomplished by seating them in the same room.

Then, when one person asks a question, others in the room can either tune in or tune out, contributing to the discussion or continuing with their work.

After thinking about it a bit more I’ve identified a few reasons why I think this approach doesn’t work so well on my current project.

The ability to ignore background noise

The ThoughtWorks Pune office is pretty much one big room with over 100 people in it so the amount of background noise is fairly constant.

When we’ve tried to run our standup near where we sit it’s been impossible to hear people standing 5 or 6 metres away from you.

You therefore end up getting into the habit of blocking out anything going on around you as was evident when there was drilling being done in the office.

The side effect of doing this, of course, is that there could be relevant discussions going on around you and you’d be much less likely to notice.

Team size/distribution

The second problem is that the team is distributed which means that we’re never going to overhear any conversations in Chicago and vice versa.

To add to this our team is now 25+ in size so it’s spread out over 3 tables one of which is only within shouting distance.

Martin Fowler wrote an article about team rooms quite recently and while the ideas make sense I’m not sure how they scale as team size increases.

Overlap of roles

Although this by no means applies to everyone that I’ve worked with I’ve noticed a tendency for people to stick to their role much more than I have in other countries.

Therefore a developer will only do ‘developer tasks’ and a QA will only do ‘QA tasks’ for example.

When you have overlap such that a developer may be ‘pairing’ with a QA or BA on something then the types of conversations that are head seem to lead to information moving around the team more effectively.

I’ve been reading some of the articles written about the disruption caused by the snow across Europe and I found one quote in The Daily Telegraph by Phillip Hammond particularly interesting

“I think whilst people are obviously deeply upset about the inconvenience, particularly at this time of year, of having their travel plans disrupted, most of what I am hearing is a sense of outrage about the way they were then treated when they were stranded at Heathrow airport.”

I was stuck in Brussels Airport for almost a day and the communication by just about everybody there was as non existent as it sounds like it’s been at Heathrow.

I think part of the reason for that was that the people in charge didn’t know what was happening and part of it was because they didn’t want to give people bad news.

I’ve noticed the same type of thing happen in organisations when there there’s something bad to be communicated or an unpopular decision has been made and needs to be explained.

Often in this situation there will be no further communication because it’s assumed that people won’t react well to that communication.

I don’t think that’s actually an accurate assumption and in addition not communicating is actually quite a dangerous thing to do because it then puts people in the position that they will now guess why certain things are being done.

More often than not those guesses will be more damning of people in leadership positions than they deserve.

Whenever I’ve seen someone in a leadership position explain what’s actually going on (and the thinking behind it) the response of the people receiving the message has always been much more reasonable than they expect it to be.

I think the people in charge of communicating what was going on in the airports would have had similar results if they’d only communicated something!

One of the problems I’ve noticed in several of the ‘agile’ communication mechanisms (such as the standup or dev huddle) that we typically use on teams is that they focus almost entirely on verbal communication which only covers one of our learning styles – the auditory learning style.

The Learning Models

The VAK learning style model describes a simple model covering the different learning styles that people have:

• Visual – seeing and reading.
  • Involves the use of seen or observed things, including pictures, diagrams, demonstrations.
• Auditory – listening and speaking.
  • Involves the transfer of information through listening: to the spoken word, of self or others.
• Kinesthetic – touching and doing.
  • Involves physical experience – touching, feeling, holding, doing, practical hands-on experiences.

My own learning style is predominantly visual so I tend to find that a well drawn diagram will help me understand something far more quickly than a colleague spending 10 minutes explaining something using only words.

If the latter happens then I either find myself totally zoning out or mentally trying to sketch out what the speaker is saying.

In a team environment this would translate into ensuring that we use the whiteboard when trying to explain problems.

Sometimes just going to the whiteboard isn’t enough and we need to cater to the kinesthetic learning model which in software development terms would involve walking through the code.

I’ve never been involved in a team session where we went through a part of the code base together but I’ve heard from colleagues that it can be very helpful in some situations.

I think it’s important that we know what our favoured learning style is so that we can guide any discussion in such a way that it plays to our strengths.

In terms of software development

Although people tend to have different learning models my general observation is that we can move through the models from auditory to visual and finally kinesthetic depending on the complexity of what’s being explained.

I think it also partly depends on the experience of team members. For example, I’m now able to understand many more discussions which are purely verbal where previously I’d have needed a diagram or someone to show me what they meant in the code.

I think it’s important to look at the implicit feedback we’re getting from colleagues when explaining something to see whether or not the model we’ve used has been effective.

If it hasn’t then at least we know we have some other approaches to try which might be more successful.