#softwaretesting
I have a couple of presentations/discussions coming up after the summer. The peers and colleagues to which I present are very intelligent and "on the ball", and so I thought it was time to give myself a refresher on "rhetoric" - or at least a layman's version.
With this in mind I went and picked up Dale Carnegie's classic "How to Win Friends and Influence People". This book came out in the 1930's but has many relevant topics and lessons that anyone can use today - you'll probably recognise the lessons in any of today's TV series on child behaviour or books on teambuilding.
It's not exactly a guide to presentations and rhetoric but it has some important points for anyone wanting to make a case...
Making Friends?
For the area of my interest the parts about "making friends" were not so relevant for lectures/presentations - although still useful inter-personal skills.
It's the second half of the book that is interesting - the influencing people part. Although the book is aimed more at inter-personal use I find some of the elements in it essential for anyone wanting to make a presentation or make a case for something.
Influencing
One of the most basic lessons is the "what's in it for me" scenario - most people are usually interested in themselves and their own interests. There are genuine critical thinkers, altruists and "devil's advocates" out there - but they're not always in the majority.
Don't sell anything in terms of how great a product/tool/service is, sell it in terms of the other person's issues/problems and how that will help.
Don't ask for a favour for change, "It would be really appreciated if you could do..." (unless it really is just a favour), but state the case as what the other person would get from this "favour".
A Book for Testers?
If you've ever wanted to put a case over for something whether it's trying out a new test technique, investigating a new tool, alter some methods or introduce radical changes into an existing system then these techniques are for you.
No matter how good you can describe the technical merits of something or how much of a problem you're having with you're existing tools / ways-of-working in presenting a case for the new tool/method/system you need to start out by playing "devil's advocate".
Ask the "what's in it for me?" but from the perspective of the person you're talking to - whether that's one person, a team or an audience of strangers. Why should they want to hear about your problems first?
As testers we should always expect our judgements to be open for "test", questioning and analysis. If you have put yourself in the other persons shoes (looked at it from their perspective) then you have a much greater chance of answering any and all questions.
Another point made in the book is to accept when you're wrong and admit it. This isn't any sign of "weakness", but a way of influencing people, building your brand through genuine openness to feedback and a great way to learn.
Summing-up
Don't start an argument for a new "widget" by saying "these are the problems I'm having with the current widget". Change it around to understanding how the other person is experiencing the widget today and this is how a new widget can improve that experience...
Don't make requests for change without phrasing them in terms of the other person's benefits from that change.
Do you play devil's advocate? Do you look at a problem from the other person's perspective?
No comments:
Post a Comment