The importance of explaining stuff in a short and simple has been very prominent in the past few weeks. I have noticed that when I have been speaking or trying to explain current business rules in the platform that I am testing on to explaining why I have decided to run these tests, and how new feature sets should interact with the current logic that I may have been wasting time on 'wasted words. Keeping it simple and short wins every single time.
Great leaders are great simplifiers who can cut through argument, debate, and doub to offer a solution that no one can doubt - Colin Powell
Ask yourself this - Who do you listen to more closely? someone who never shuts up, or someone who utters a few words? As with most things in life, the law of supply and demand holds true: If you constantly share your opinions, no one will seek them out. If you only say what you're thinking when necessary, or just make one point instead of saying one thing over and over, your words will bare more weight. As a tester, I am not suggesting that other testers keep their opinions to themselves. Your team needs to know what your thoughts are, more importantly that it is your duty as a member of your team to mention how you feel on certain projects. Testing is a service role, if you spend more time speaking than you are listening, are you really providing a good service?
Keeping it Simple is an idea supposedly coined by Kelly Johnson, who was the lead engineer at Lockheed Skunk Works responsible for the SR-71 Blackbird spyplane in the 1960s. He noted that most battle systems work better when kept as simple as possible. This holds the same case for testing, if you have a test plan that you can not explain to your manager or your team in a few words, then you do not truly understand what you are doing.
In BBC Television's "Yes Prime Minister", Sir Humphrey is a person who loves to talk at great lengths without saying anything at all. Here is a link, how can someone say so much without any actual meaning?
Short and Snappy
In the workplace, there will be a person (gauranteed!) who will say alot of stuff without meaning much. Like everyone, I would like to tell this person "Life's too short, please get to the point". When the person in question is someone who has a higher status than you in the company, the head on approach may not be the the best way to handle the situation. Just Smile and try to avoid doing it yourself
Say what you mean and mean what you say - Dr Patty Ann Tublin
I am sure she's not the only person who's ever said this, I have spoken to a few friends of mine who work with people who feel that they have to assert their authority by continually throwing in words on anything and everything that's being discussed, when the fact is that if they don't have much value to add to the conversation. To make matters more interesting, they'd come across more intelligent by not saying anything at all. Remember the song by Ronan Keating "You say it best, when you say nothing at all". I'm not saying you should say nothing at all, but the power of silence is not something to be underestimated.
In anything I write, I make a conscious effort to condense my words in less than 200 characters. To every tester out there, we know that the summary line is the most important line in the bug report. Understand that anything longer than 2 or 3 sentences explaining an issue is way too long and is not going to hold anyone's attention. There are only so many hours in a day and working in a startup, no one has time to wade through pages and pages of ineligible words.
Larry Page of Google says that his colleagues all know that sending him anything that is much longer than a tweet exponentially increases the likelihood of him not reading something. Capturing someone's attention in writing is a process of getting some bait for the fish, once the fish is captured, then it will lead to them reading the long description. Try throwing out the huge description first without the bait, you will catch no fish.
A good summary gives the reader enough information to help him or her decide whether to ask or look into the bug more. It should include the following:
- A brief description so the reader can visualise the failure (throw in a screenshot)
- A brief indication of limits + dependencies (how big is the bug, what's affected?)
- A brief indication of impact or consequences of the bug
Use more of your words to describe the impact and consequences of the bug and watch the bugs you found get fixed.
Explaining Stuff 101
When I was a child in elementary school (or primary school as other people call it) once every month or so, my teacher would ask us to present something about anything. I remember presenting to the class about my favourite food ever sisig. Every now and then I would stutter or would be loss for words, then suddenly my homeroom teacher would slap her long ruler stick on the chalk board board and tell me to continue. To be frank, it still scares me to this day.
The truth is, I never enjoyed public speaking a decade or so later, I'd be more comfortable with public speaking knowing the simple fact that I am not on my own with this fear.
The main thing is being prepared. This means knowing the material so well that I don't have to think about it. Little notecards are helpful to make sure I've covered the main topics I wanted to discuss and do a few dry runs infront of my family to cure some anxiety. My family help me in reviewing my material and ask me questions about my speech and give me feedback.
Secondly, be real. Imagine having to present 100 slides (ew, slides) for 20 minutes infront of your colleagues, what's running through your head? Here's some of what I run through - Am I going to do it? What if I stutter? What If I can't answer the question. The simple solution I've come across is writing on a piece of paper all my fears before the presentation, writing therapy. Once I have finished writing them all down, I have a quick read telling myself "Cool, I've got this". I make a paper ball out of the paper I've used and throw it away - I don't know why, but the relief I feel is extraordinary.
What Not To Say
Notice how you get into a meeting and the presenter talks for the whole time and afterwards you ask yourself and other colleagues in the presentation that the presenter did not cover the topic you wanted to talk about. Understand that when you are presenting something, you will not cover everything, but atleast you'll cover some. Format your presentation using Q and A - I aim for me talking for around 60% while everyone is listening and 40% answering their questions.
Avoid these words. These words just drag out speaking time and adds 0 value. You need to be definitive in what you say.
- You Know
I would suggest you to try one or two of what I have experienced, I can gaurantee that your colleagues will mention how great your communication skills are.