Keynotes are something to be earned and rightly so. Typically a keynote comes from someone who likes to speak, who is good at speaking, and has something interesting to talk about.
I know many women testers who meet the above criteria. They have the requisite ‘merit’ required to be a keynoter. They have thoughtful ideas, are good speakers and are well respected in the testing community.
So why are they not keynoting?
Could it be that to be a keynote takes more than ‘merit’? Could it be that keynoting is also about your place in the community and your connections within that community?
My experience as a conference organiser and being on program committees is that ‘who you know’ is equally as important as ‘what they know and how they speak’. I don’t apologise for that. It’s important for me to base my decisions not only on an abstract but on a speaker’s reputation.
A keynoter needs to have some of the following:
1) They have interesting topics to talk about
2) They are practiced/skilled at speaking
3) They are involved in some way in the community
4) They network within and outside of their ‘tribe’
5) They make a point of asking for keynotes
I know many practised women speakers with fresh and innovative talks and we are well covered on points one and two.
And we’re not so bad at organising and volunteering for conferences & community either, so….
Could it be, points four and five is what’s holding us back?
Keynotes are typically by invite. That means, the program committee gets to decide who keynotes. Those on the program committee tend to have a good network. It’s probably one of the reasons they’ve been chosen to be on the program.
How are your networking skills? I’m not talking about card swapping nonsense, but ask yourself: do you have a genuine interest in engaging with people who you respect? Importantly, do you know your network will openly advocate on your behalf? Which brings me to point number five…
Be open to asking to keynote. Is it just me, or is there’s this weird unwritten rule in our community that prevents us asking to keynote? It seems to me that to ‘make it’ we have to Marlene Dietrich like, sit nonchalantly in the corner waiting to be asked for our moment in the spotlight.
Maybe that’s just me and not a general experience. But for those of us who are less direct I’d like to suggest you make it clear to your close network that you want to keynote?
What’s more, go direct to the program committee and ask them for a spot. If the say no, ask why not? and what does it take to keynote,? Who knows you might gain some valuable insights into the process.
Because no matter what skill you have, or how good you are at speaking, or how charismatic you are, there’s dozens of great speakers who can do what you do. It takes more than merit to get noticed. It takes courage to ask and you need allies who will support you along the way. Have you got what it takes?
If you’re reading this post, and you’ve keynoted in the past with a story to share about how you got to keynote, Speak Easy would love to hear it as it may help us understand what it takes to ‘get there’. I’d post a link to your blog post on the Speak Easy website (or I can post a blog).
*Title misappropriated from a book I found useful on this topic “nice girls don’t get the corner office’
One question I often ask a tester in an interview is what they believe are the essential skills that differentiate a good tester from a great tester. One of the common replies is “Paying attention to detail”. But what does that really mean?
Start with detail. What do you mean by detail? Mrs Google offers the explanation “an individual fact or item”, but what sort of detail? Visual detail? Detail from a coding perspective? Any detail or only detail that matter? Is it detail as in ‘small stuff’ as in the Devil is in the detail?
Also what exactly does “paying attention” mean?
Maybe it’s one of these interpretations:
- A tester is attentive as in a teacher saying “pay attention!”? As in be alert?
- A tester is only observing detail?
- A tester is observing detail exists and then noticing they are problems?
- A tester is noticing detail without a conscious attempt to observe in a methodical manner?
Going deeper, why ‘pay attention to detail’ in the first place? Is it because you’ve been told to, or because the tester genuinely wants to? Your motivation and purpose play important roles in bug finding. For example what’s your ‘attention to detail’ on being told to complete 40 test scripts in one day, compared to your attention to detail if you get made handsomely for finding a bug or winning a prestigious competition?
Yes, paying attention to detail is important, but so is understanding what you are doing when ‘paying attention to detail’.
In my book, there’s not enough meat on that answer to figure out if someone’s a good fit for my team. I want more. I want my testers to suck the marrow out of that question, to boil it until the flesh falls away from the bone.
Professional testers¹ consciously observes systems using a multiple of models. Their maxim is “the more you see, the more you see”. And that’s only the beginning. Following observation comes evaluation. Now testers get to interrogate information by asking (either explicitly or implicitly) is there a problem? Not content with relying on one oracle they may consciously use many different oracles in their evaluation process.
They then report this information in a way that’s meaningful to the people who want to hear it.
So if you are a tester coming for an interview on my team and I ask you this question, please have fun with it. Show me your testing process, demonstrate it with diagrams and models and show me a bit of your testing flair. All testers pay attention to detail to some degree. What in particular do you pay attention to?
¹ by professional tester I mean someone who makes an attempt to understand and then improve their personal testing process. They tend to develop a unique approach and style to their testing through years doing, thinking, talking & writing about testing.
This post is a result of a tweet I made which many testers. An interesting aside, my poor spelling was explained away by many as a purposeful trap designed to snare the unwary tester. It wasn’t, though I’m flattered that you would think that of me.
Testers, its not so much 'paying attention to detail' that makes you skilled in testeing, but more knowing how to observe in the first place
— Anne-Marie Charrett (@charrett) March 18, 2015
One of my first recollections of physics is the image of Archimedes running down the street, dripping wet from his bath and shouting: “Eureka I found it!” on discovering his principle of fluid displacement to measure the force.
Add to that Isaac Newton who quietly sat under an apple tree, musing the day away until he discovered his laws of motion, one which states;
For every action there is an equal and opposite reaction..
Many companies want to improve their testing, particularly if that improvement is translated into reduced time or cost.
To achieve this, there’s a big trend to embed testers into development teams. There’s no longer ‘us’ and ‘them’ but an harmonious ‘we’. The wall of independence is torn down replaced by a gleaming whiteboard emblazoned with the banner ‘Quality is a team responsibility’.
The reality though is that just like Archimedes in his bath, or Newton and his Apple, embedding testers into a team of developers is going to create displacement and cause a reaction.
This is common sense. Put one tester into a team of multiple developers and it’s going to change the team dynamics. Add to the mix, that the tester will most likely become a point of constraint disrupting what was perhaps a seamless flow of stories into the Done column and it’s no wonder the apple cart gets upset.
For example, developers discover they need to get more involved in testing and decision making.That can be a big mindset change if traditionally developers are used to handing work over to testers (as opposed to receiving it from them).
Testers need to change and adapt too. They have to let go control over all the testing and entrust the developers to help them test. Again big mindset change for testers who traditionally rely on empirical evidence than a developers word to evaluate quality.
Why then, do we seemed surprised when we face resistance and/or confusion when these changes are attempted?
This is our brave new world. I wonder where we will all end up? Wether a team develops a true and meaningful relationship or simply an uneasy alliance is I guess up to how much both testers and developers are prepared to appreciate each other’s challenges.
One way we can help each other out is to be supportive as opposed to defensive when people face the impact of changes and perhaps feel displaced and confused. How much we are prepared to let go our assumptions and prejudices about each other will also play a big part in how ‘successful’ these experiments are deemed to be.
Exciting times indeed!
It’s not only engineers that need to deal with S/N (Signal to Noise Ratio).
Test Managers have to deal with lots of noise, in managing projects, dealing with stakeholders, identifying potential future risk, maintaining test environments, hiring testers, and meetings,meetings & meetings. Traditionally that’s what the role has involved. We deal with the noise, so testers can get on with doing their job – testing.
But is this really what is required? The reporting, the stats, the work allocation, the test strategy work and did I mention the meetings? It’s all STUFF. There’s always STUFF to do as a test manager. If we don’t have STUFF to do, we go out and look for STUFF. We roll our eyes at all the STUFF we have to do, but secretly we like it. It makes us feel important and keeps us busy.
Recently, I did a peer review with my team. I asked them to anonymously review my work. One question I asked them was “what I should start doing more of?”.
The resounding signal was loud and clear. They wanted me to increase the amount of coaching and training within the team.
So I stopped doing STUFF. I dropped meetings that were optional, I’ve distributed recruitment and I worry less about planning for ‘the future’.
Instead I test and I encourage other testers to pair with me as I test, or to invite me over to test with them.
That way I’m sharing my knowledge and expertise.
It’s been hard to let go the high level STUFF but in some ways, these management type activities can be performed by most managers. Very few people can train and coach testers.
How’s your S/N ratio going?
If there is ever one word that highlights the difference between a tester and a developer’s mindset it has to be the word done.
Developers¹ tend think of done as a form of sign off. A story is done when the code is complete. For many developers, it’s when the code is complete, tested and deployed. Done is a sign of completion, of moving onto something else.
Testers² look at Done as the beginning of a quest, an exploration. Done is to be prodded, probed, explored and dissected. Under what conditions can ‘done’ fail? What data tests the limits of Done? How about if two Done’s are put together, how will they behave?
With these two different mindsets it’s no surprise that at times there is conflict and disagreement.
Most testers (most people for that matter) shy away from conflict in order to maintain team harmony. Instead, they try to gain agreement upfront on Done. The goal is clarity and scope definition. Make done clear upfront (before coding begins) and it lessens the conflict later.
In many companies, conflict is seen as a ‘bad thing’. Being in conflict suggests that you’re not a team player. But conflict is a not always bad. According to the 5 dysfunctions of a team by Patrick Lencioni conflict is healthy indicator of trust and ought to be encouraged.
And testers must not forget that our primary role in a team is to raise uncertainty about Done. This has to come ahead of wanting to be everyone’s friend and being accepted. The reality is, if we are doing our job we will be testing the limits of preconceptions of Done.
Because as appealing as it is to think of Done in terms of black and white, zero and one, the reality is a lot different. Done is subtle and muted with hidden dimensions and unknown crevices. Exploring and shining a light³ on these dark corners generates new information. That information helps mould and develop our understanding of Done. The more we test, the better this becomes. Whether this new information turns out to be accepted or rejected is to some extent irrelevant, both contribute to fleshing out our understanding.
So sure, have your discussions on ‘Done’ before code is written, but let’s realise that it’s only the beginning not something final written in concrete. Allow testing and testers to expands that understanding.
In fact, I would go as far to say that true harmony is having a mutual goal of building our understanding of what Done means. Who knows? Maybe through that mutual goal can real trust and respect be built within a team.
¹ ² generalisations
³ kudos James Bach
Oh tester why dost thou despair?
The code is right
of this we are aware!
We verify. We know what we do know
No need to doubt and think of all this woe!
Instead be bright and bring us certainty,
Let Done be Done, thus ends this homily!
One of the morals of the Back to The Future series is be able to walk away from a fight. It took three movies for Marty McFly to learn this self control.
One thing that the scriptwriters failed to predict was the birth of speaking your mind in 140 characters, aka Twitter. If they had, it would be easy to see how Marty might have been pulled in to a twitter diatribe and feel unable to resist responding.
It’s easy to engage on Twitter. It’s fun and easy to throw out ideas, thoughts and its mildly useful for debate. My personal experience though is that its much harder to disengage. I feel compelled to reply to a challenge. It’s as if each tweet directed at me is a personal call to respond (sometimes it is). As much as I want to ignore and avoid, I find myself compelled to return and <sigh> to respond. My reasoning mind tells me, desist, desist, but my ego overrides this. I must have the final word!
There comes a point in any twitter engagement when you realise the conversation is little about debate and more about chest beating. When I’ve come to this realisation, I’ve lost the battle. I’m no longer in control regardless of having the last word or not. There’s little dignity in wining such a battle.
We need to learn the art of disengagement, the ability to walk away without feeling somehow less of a person. It’s important to engage, but its also important to be able to disengage.
I’ve come up with some heuristics to help me battle the McFly syndrome.
Yes, And Heuristic
I got this from Lynne Cazeallys book Create Change. Instead of think ‘yes but’, think ‘Yes and..’. .it goes some way to appearing collaborative, perhaps reducing the antagonism in the twitter conversation.
How about this? Heuristic
Another Lynne Cazeally suggestion. It uses a lot of characters but you can apply the sentiment to help sound more congenial.
Rule of Three Heuristic
Sometimes, attempting to understand other reasons why someone might write something helps you to walk away. Taken from Jerry Weinberg’s rule of three.
Out to Lunch Heuristic
I’ve seen people use this occasionally where they excuse the challenge to go out and walk the dog, feed the kids etc. I haven’t tried it myself but its a method of walking away with some grace. Even better if the reason is valid.
Simply don’t respond. Oh to have the will power to apply this, especially in the heat of battle!
A crude yet highly effective way of not knowing is someone is responding to you or not. You are now blissfully unaware. The downside is that you will never hear anything that this person has to say. You may consider this a good thing.
Turn off Twitter
The ultimate solution and something a few people have resorted to. Not only does twitter seem to bring out the worst in people it’s incredibly time consuming. Ask yourself do you really need it?
What tactics do you use to help you disengage from a twitter war?
We’ve placed a ban on crappy work within my test team. From now on, we declare that the testing team will refuse to do crappy work.
The challenge is in knowing how your doing good work or crappy work? This is why I’ve created this simple 5 minute ‘Crappy Work’™ ² test to help any tester to figure out if you’re doing crappy work or not. ¹
1) Do I fully understand what I’ve been asked to do?
2) Why am I doing this task?
3) Who will benefit, and I have spoken to them ?
4) Am I doing this task simply because its part of the process?
5) If I think it’s crappy work, how can I make it valuable?
I’m sure there are plenty more ‘crappy work’ questions that would be useful to add, but my 5 minutes is up.
Why not share your ‘crappy work’ litmus tests?
¹ Maverick Tester takes no responsibility if you take this quiz and continue to do crappy work
² It’s a 5 minute quiz because it took me 5 minutes to think it up. It’s trademarked so I can sell you a certificate in passing the ‘Crappy Work’ test, thereby making a whole lot of money out of it.
I was recently in New York and had a chance to walk along the High Line. The High Line is a disused overhead train line converted into a walkway and park. It’s a really lovely walk.
I was interested to learn that the train line had been built in the 1930’s but had become disused by 1980’s. It’s main purpose had been to transport meat and produce to manhattan from the upper west side. With the advent of trucks the train line fell into disuse. It was about to be torn down when a small group of inspired locals advocated it be turned into a park. The movement grew and now the disused train line is a lovely walk and respite from the busy traffic.
I think it’s interesting that the train line fell into disuse in the first place. Why were so many companies eager to drop the train line in place of trucks? My guess is they wanted the ability to freight cargo when they wanted. Rather then delivering in one bulk they delivered smaller amounts more frequently. That way they could become more responsive to their customers needs.
That’s what we’re aiming to do with continuous delivery. We want to be able to deliver in a faster way, to be more responsive to our customers needs.
I wonder if our existing network will be able to handle it though? Look at the traffic jam that is NYC and it makes me wonder that with the ability over faster and more frequent delivery comes the cost of greater traffic on our networks. Remember, if it was just your company wanting to deliver, of course there’s sufficient bandwidth, but when everyone has the same idea will our current network be able to handle it? I guess only time will tell!