How do you do, Head of Testing? Vol. 2

Thanks for asking. Still tired but I made some good progress on a project I’ve been working on for about 6 months. I actually slept better after finishing this draft. But that’s not today’s topic…

Today I want to reflect on jam and systems. Jam systems. Jammed systems. Systemed jam. Systems of jam. I need to stop before I can no longer say “jam” and still understand what it means.


I really like raspberry jam. Even if the seeds get stuck in my teeth, it tastes like summer. If you are a manager and have not heard of the Law of Raspberry Jam, I’m sure you have felt it. Jerry Weinberg writes about the Law of Raspberry Jam in his book The Secrets of Consulting: the more you spread it, the thinner it gets. I learned this as a team lead at my previous job where I tried to build up testing and fix everything and anything that was wrong with quality.

As a competence head, I’ve now learned that the higher you go vertically, the more you are in danger in spreading yourself too thin. It’s an asymmetry that probably can’t be helped and that C-level executives probably know better than I do: the higher you go, the more there are people who place demands on your time so that your time becomes extremely fractured. It’s just there’s still one (jar) of you (to spread across those demands).

Managing one’s energy is important to be able to work on and achieve stuff continuously and in sustainable manner. Managing your energy well also means you know your priorities as you will spend it only on important things. If only it was easy to identify priorities when all opinions are different and contradicting… But there’s always something you can observe that can tell you what’s important to achieve and whom to get support from to succeed.

Being a manager, I’ve found systems thinking to become increasingly important for uncovering organizational dynamics. Combined with sketching it allows to visualize the system and its parts which is a great exercise for clarifying your own thinking. So after a couple of months, I was able to sketch the organizational dynamics that I considered detrimental to its strategy and goals (and to my goals), and the visualizations helped me discuss it with others. Making changes to the organization at this level was not in my scope or under my influence but at least I could express my concerns, and point at potential obstacles.

There was a downside. Once I understood (or thought I understood) how the organizational dynamics worked, I also saw how all the things I thought of trying to bring about change would fail. It’s entirely possible that someone with a different mindset would have only seen opportunities not obstacles.

I see opportunities too. I’m simply pessimistic about overcoming some of them. Especially those that get perpetuated in the organizational structure and behaviors. This is quite abstract but here are a few heuristics to use:

  • what gets talked about in all-hands-on-deck meetings held by C-level management
  • how managers handle requests for collaboration coming to their team or going out of their team
  • how much awareness and knowledge there is in one team about what kind of practices are used in other teams
  • how much slack people have to attend trainings (either internal or external)
  • how much energy and time are people willing to spend on internal educational or social activities
  • how much time do people spend talking about each other’s work (and in what tone) at the coffee machine
  • what kind of objectives are managers driven by primarily
  • how many spontaneous initiatives you see popping up without having to use a stick to get someone do something

The list could go on. Some of these observations can be made within a couple of weeks if you’re new to the organization. Some of them may take longer. Eventually, by observing these behaviors and then investigating the sources of them, you start getting the hang of the system.

For example, if you keep hearing how people “don’t have time” for this or that, then in addition to listening their stories (and justifications), it’s worthwhile looking at how the system structures the use of time, what kind of actions control it, and what kind of other behaviors are related to it. I find that “lack of time” mostly comes down to priorities and preference, hence, it’s informative to learn what drives those.

In systems thinking language:

  • where are the flows and what is their direction;
  • where are the stocks and what’s their relation to each other and the flows
  • what are the feedback loops like in terms of strength
  • and so on

In case you’re new to systems thinking, check out Thinking in Systems: A Primer by Donna H. Meadows. I think it’s a wonderful introduction to systems thinking.

I had an understanding of how the structure of a system affects the behavior of the system and its parts. I mean.. .isn’t it obvious when you observe any kind of system, especially one that contains humans? Reading Meadows and getting more into systems thinking in general, has helped to make my thinking clearer and has helped me understood the system within which I am operating.

As Meadows has elegantly put it, “System structure is the source of system behavior. System behavior reveals itself as a series of events over time.

This sums up quite well why I think it’s essential for managers to be skilled systems thinkers. Surely you can affect the behavior of some humans in the system who may then help you change the system (maybe you end up being a bunch of revolutionaries on the chopping block, who knows). However, without understanding the system, it will be hard to direct your efforts. Remember the spread jam? Exactly.

I see my work mostly to be about affecting the system and some of its structures so as to help change in behaviors to emerge that would improve the system, and that would make it sustainable and resilient. (It could also be that I attempt to remove jam from systems or get them “un-jammed”).

But how to do that? I don’t have a magic bullet but I’ve tried and failed and tried, so that is what I’ll cover in my next post: change and a context model for affecting behavior.


Now where’s my raspberry jam…


How do you do, Head of Testing? vol. 1

Thanks for asking. To be honest, the answer depends on the type of day I’m having. Downward spiraling direction can be found in my days more often than not recently. Ah, I should finally take the lesson from Benjamin Zander about those spirals and ditch them. And also remember rule #6.

A bit more than a year ago I started out with the goal to help testers in the company do a great job. It looks broad and sounds idealistic but it was as good as any mission to take as a starting point. I believed I could find a way to rally people behind initiatives, ignite their belief in change, and help them engage and drive testing and its development. At the same time, I had to figure out what the role of a competence head means…

I couldn’t be everywhere and put my hands into and onto everything, I knew as much. Some groundwork needed to be done or so I thought. Understanding the people and the system, its influences and boundaries was my first goal. So I set out to have long discussions with almost all testers in the company. I didn’t believe in picking and choosing just a few because, naive as I am, I believe all people matter and play some sort of role. So I did that, spent quite a lot of energy and didn’t get much of it back.

I gathered a lot of information in notes, impressions, memories, stories by doing so but then trying to analyze and systematize it ended up being a painful and somewhat confusing process. So I learned that sometimes there can be too many different answers to a limited set of questions. Some patterns may emerge but it may only be your own biases that make you see what is not there. But interpretations you make are very real in your mind. Piecing the information together to describe a big picture of the status of testing in the company through the eyes of testers took me a lot of energy and didn’t give much back.

It also made me think of how I chose the questions. I tried to cover a vast spectrum: understand the person’s history in testing, their knowledge and habits in testing, evolution of testing in this company through their eyes, problems and issues they see, changes they hope for, etc. Looking back, I’d still talk to every single person but be more careful and selective in the questions. I could easily come up with a convincing rationalization why I needed each and every one of those questions, what kind of information they would yield and why I deed this information… My mind is really great at such things. However, excess of stories will make the load heavier than it needs to be. This takes energy and it’s difficult to get it back.

As a systems thinker, I’d been noticing signs of barriers between people. Detecting barriers in an invisible system of people in an organization and off the org chart goes like this: you run face first into something, scream in pain, curse and cuss, and try to determine the culprit. It’s just that you can’t see it but can trace your fingers across air and lightly touch… something. Imagine navigating a glass labyrinth where there are people almost within your reach, only to brush your fingertips against the glass. Some cold drafts sweep past you. Eventually you determine that the actual office layout has an uncanny similarity to the labyrinth. Why, both have glass walls through which you can see people but not interact with them very well. So you turn your back to others and mind your own business with the people next to you. Observing this is emotionally taxing and takes energy that I can’t get back.

So I sketched the organization on paper to visualize issues, and discussed it with some people. In addition to all the other things on my plate, I started trying different things to see what could increases osmosis…

More on that in the future. I’m starting to ramble and wax lyrical about glass walls. That ain’t gonna give me the energy back.


Takeaways from a Pitching Masterclass

Pitching is 95% practice and 5% inspiration. -Annette Kramer

A couple of weeks ago I attended a pitching masterclass by Annette Kramer. It’s part of this strange habit I’ve developed that I watch masterclasses on Youtube to pick up ideas for my own coaching sessions. Now I decided to watch a live one. But more on that in some other blog post…

I learned things about conducting a live masterclass including interaction with the audience. In addition, I also picked up a few ideas that I believe would be useful for testers. Communication skills are among the core skills of testers and I’d say pitching is a subset that could be useful to have in your toolkit.


This masterclass focused on the 3-5 minute pitch format which, according to Annette, is the hardest pitch to do. This is because talking for longer is easier – you have time to expand on your points (though you may water down the content this way…). The masterclass was mostly targeted at different business representatives who need to do pitching to investors or potential business partners. We had a good mix of people: from a startup pitch to looking for partners for school software to a showroom rep. Therefore, it was great to see exampels of pitches for different audiences.

Annette live-coached the pitch makers starting from how they walked to take their spot, to how they stood, how they expressed themselves, and she also re-engineered the flow of their pitch on the fly while also including the audience in giving feedback. It was inspiring to look at how she worked with people.

Selective Hearing: Lessons in Communication

Annette says that when an investor listens to a pitch, they hear “blah blah blah will I make any money on this blah blah blah when will I earn money back blah blah”. When a potential business partner listens to a pitch, they hear “blah blah blah will this make me look good blah blah will I make/lose money with this blah blah”.

How does your audience listen and what is important to them?

Do you focus more on what you want to say or what they want to hear?

During the past year I’ve dealt with C-level and other directors and managers more than I previously have, so this one hits home and is a good reminder. I know I frequently fall into the trap of thinking more about what I want to say and what I hope the effect to be, rather than doing more listening to be able to target the message better. And understand the people I work with better.

From observing a number of testers over the past year, I think there is an important takeaway/reminder here: when talking to your manager (or some other stakeholder/decision maker) about testing, don’t focus so much on your specific testing problem but on the impact of the problem. When focusing on the impact of the problem, you can think of what that manager/stakeholder sees and what they’d like to hear. I bet it won’t be some testing-specific talk about the issue you want to address or the idea you want to introduce. I bet it would help you if they heard “blah blah solving this will make us look good blah blah blah solving this will mitigate the risk of not fulfilling financial goals that  a director somewhere set me blah blah blah”.

That being said, I really liked and I agree with Annette’s proposition that you can’t sell or push ideas on people – it’s much more liberating to think of pitching as a way to offer people an opportunity. So this is why you need to know what your audience cares about and is interested in.

I don’t do pitching on the stage to my managers but I treat some hallway conversations or situations at meetings as micro-pitching opportunities. I have a lot of ideas and I keep looking for ways to get buy-in or traction to take the ideas further. I don’t always know which ones get better traction which means I need to pitch them several times to different people. Which takes me to the next takeaway…

Process. Process Everywhere.

Annette emphasized that it’s useful to think of pitching as a step in the process, and to keep the process in mind (not the result). The goal of the pitch isn’t to close the deal because hey, that hardly happens so easily (or right after a pitch).

The goal of the pitch is to get people asking questions, to keep the conversation going. When I later talked to Annette about it, she said that we do this outside work all the time. And I said, “Oh, this is why we have friends… because we keep the conversation going and this is a process”.

When trying to approach a decision maker with an idea (which probably will take up time (=money) and money, so there are considerations in their mind you may not know about), don’t think of it as a “make or break” situation at the first try. I find myself sometimes doing this exact thing and then getting frustrated. Well, that’s not helpful, is it? And it’s not helpful because if I focus too much on the result, I forget about the process of getting the result. Introducing new ideas in organizations can be difficult, so focusing on the process, focusing on starting and keeping the conversation going is helpful.

Mean It. Clearly.

It was fascinating to watch Annette pick up the difference between when the speaker really meant and believed in what they said and when they didn’t because they focused on what to say (or remembering what to say…). I observed a significant difference in this person’s body language and facial expressions in the pitch after Annette had made some adjustments and asked them some questions to help them discover what they actually meant.

And I mean if I could pick it up, so can you. And other people will pick it up about you. Here’s another takeaway: don’t be abstract, be specific. It will be hard for you to say it like you mean it if the concepts you use are too abstract (and it will be hard to grasp).

Annette did a great job helping people to be specific and get the real meaning out from behind the words. I think this is also a process: you start with an idea, and through practicing a pitch for it, you peel away layers and arrive at the core that will be specific and clear.

We also addressed the issue of using jargon and how this makes attempts at being specific revert to being abstract (“What do you mean by [this thing]?”). I’ve also observed in testers that they tend to use testing jargon when talking to stakeholders who don’t know anything about testing (or don’t care about it…). It’s a similar point to that above: think about the audience you have and what they can understand and want to hear (probably not jargon). Focus on the problem that they feel related to. Annette pointed out why TED talks are so great: among other things, the speakers avoid jargon (so that everyone can understand what they’re talking about).

And don’t talk on autopilot!

Autopilot leads to not really putting yourself in the words you’re saying and you end up “just talking” not delivering a message.

Annette had a great tip for this: remember why you care about what you do/say BEFORE you say it.


I’ll blog a bit more on the pitch structure and other takeaways in another post.

A Hot Pink, Feathery, Blistering TestBash


When walking down the street in a bright blue Ministry of Testing T-shirt, hot pink feather boa, and grey Crocs in Kemp Town in Brighton on a Friday night, you blend right in. Nothing to worry about.

TestBash is one of the events that feels more like a community gathering or even a family get-together than a conference. Of course, this really depends on what your definition of a conference is… Having just got back from my second TestBash as a volunteer, I’m happy to report that TestBash stands for everything a good testing conference is about for me – passionate professionals, curious newcomers welcomed to the community, meetups, family vibe, top-notch talks and workshops, high energy, a little bit of cool and flair and craziness, great humor, fountains of inspiration…

However, the beginning of TestBash was worryingly blistering for me. Quite literally, I arrived in Brighton only to limp to the hotel in pain.  Newish shoes caused serious damage to my left heel. Never have I ever seen such a big broken blister on myself. I was sitting in my hotel room thinking I had to stay there for the whole time… But then it’s all about problem solving and reaching out to people, right? So I cleaned and patched it up, took a taxi to the pub where the pre-pre-TestBash meetup was supposed to take place, and was so happy to hug Rosie that I cried.

And then I got to talk to some friends in the pub and things were looking up. The next day Rosie brought me a pair of Crocs as I couldn’t wear my own shoes. And I was good to go running around in Crocs to facilitate the two workshops, make sure things run smoothly, problems get solved, and workshop leads can focus on their work.

The Workshop Day

First happening of the morning – taxi tried to take me to some other location than that of the workshops.

Ash Winter’s workshop on system architecture and testing the bigger picture contained lots of group work and exercises that layered models through learning cycles. Ash asked participants to visualize a system architecture through some analogy. For example, authentication got visualized using the analogy of a party – who’s allowed to get in and who’s not, and how this system works. There were quite a few others. Even though this analogy is yet another model and does not represent technically what authentication does, it helps to familiarize the concept and some elements of the system. As someone who still needs to learn the ropes of such things more deeply, I find this exercise helpful.

Then it was time to build a model of the architecture based on snippets of information from different sources. Then we learned about FIBLOTS by Scott Barber to layer it on top of the model. And then the heuristics of testability by James Bach were used to identify places in the architecture where testability could be improved. Overall a great workshop by Ash, so if he happens to run it elsewhere, surely check it out!

The second workshop of the day that I facilitated was by Alexandra Casapu and it was focused on examining testing skills. I attended this workshop at Let’s Test 2015 and found it to be an excellent balance between individual reflection and reflecting in a group – all focused on understanding skills. There are exercises that direct you to dig in the past and exercises to observe and discuss skills in an actual problem solving situation. I recommend you attend this workshop when you have the opportunity. Meanwhile, you can work on mapping your skills on the website Alexandra created: testing skills map repo.

In the evening we went to Brighton beach and had some beers, had some fun, talked about stuff, got tattooed, too. Radomir Sebek spent some time on the pen challenge with his colleague from Berlin. I had some great conversations with folks. As a result, I’m looking forward to a blog post from Kim Knup about the “5 minute feature pitches” they do at Songkick and, hopefully, a talk by Beren Van Daele at a conference (through Speak Easy) who accepted the challenge. He already completed another challenge: he did a 99 second talk at TestBash! Also had a very nice chat with Phil Harper. And Danny Dainton. And… oh, you know the meetup stuff🙂

TestBash Day

I woke up bright and early and it was going to be a beautiful day. I enjoyed a rose&pistacchio mocha, then waited at the Brighton Dome’s backstage door while observing a pair of seagulls sharing the remains of a pear (it looked like it), and watched an unassuming squirrel go about its stuff.

Once Rosie and other volunteers and helpers arrived, we got signed in, got our backstage passes, and we made our way to the sweet spot. Emma and me did some prep for the Lean Coffee session we were going to host. It would’ve been more work for us but there were some experienced “lean baristas” at the tables who knew the process and could help folks for whom it was the first encounter with such format. I already figured a cool visual guide would help in this case as it wasn’t a space where you could yell instructions, and people were spilling in continuously for a while. The list of topics collected from the post-it notes is available on GitHub.


As far as the conference talks were concerned, I found the content of talks to be consistently strong throughout the day. The videos will be posted at the Dojo site later and I recommend to watch them all. Probably the most emotionally moving talk for me was Nicola Sedgwick’s about thick skin and caring about what you do which somehow makes everything much more stressful. Since I was on mic duty, I was trying to maintain dry eyes.

Bill Matthews made us feel a little discomfortable as he shared the challenges of testing smart algorithms. Lisa and Emma had packed a lot of wisdom and practical advice into the talk about building the right thing. Michael “Wanz” Wansley masterfully delivered a somewhat controversial talk about gatekeeping, and we could get a wiff of Grammy dust along with it. A totally non-grumpy Patrick Prill talked about ignorance, knowledge, and the Mount Stupid (and it was his first conference talk!). John Stevenson broke out some techno to remind us of model fatigue, encouraging us to be more creative with models we use. Katrina and Nicola made sure the Kiwi front was strong by talking about a pairing experiment, and being the sole tester in the team respectively. The lovely Dan Billing discussed the importance and necessity of security testing. Anna and Andrew discussed how “testers doing the coding” is the least of your problems when trying to move to test automation.

Sometime during the day I contracted a hot pink feather boa. You know, just to make sure everyone knows I’m a volunteer not some normal person attending the conference. Others were seen toting tutus around different body parts.


Photo: courtesy of Jokin Aspiazu, my favourite Spanish tester (from left to right: Guna, Huib, me, Pekka).

I’m sure there was something for everyone to take away. The crowd was supportive and emotional, there was a great vibe throughout the whole conference.

As the final event, there was a gathering at another pub, and also a poetry slam to which I arrived somewhat late (sorry, I was having a convo downstairs). But I delivered my post-apocalyptic stream-of-consciousness poem anyway. Well, at least Mark was blown away😀 And then I had other good conversations (some brief, some longer) with Noah, Rhian, Mike

It was also incredibly great to meet my PSL buddies Chris, Lim and Ioana again. Gotta say – “PSL buddy hugs” are of a special kind!

Then I took a stroll in my aforementioned outfit, got a bit of sleep and headed to train station through foggy Brighton.

All the love to Rosie for having me (and for the Crocs!). All the love for the community that came together. All the love to Brighton for being wonderful.

I hope to be back.

TestBash Poetry. Post-apocalyptic Stream-of-consciousness: A Project Wasteland

By Mark Tomlinson’s request, here’s the poem I wrote for the post-TestBash meetup’s poetry slam.

Recommended soundtrack: Pendulum – Another Planet

Curiosity crawls across

the craquelure wasteland

crows peck at the empty casks of bugs

hollow echoes report

passes in passing

failing at failures

nitpickety checking machines

trawling and harvesting ungrown

premature fetuses of bugs

a scrum master was seen

scrambling to escape the

creepy crack in craqueluresque surface

of the planet known as The Pisshole

he was never to be seen, we lost the visual

herders cajoling lines of code

snappy whips and contraptions

squeezing petrified lambs of code

faster harder

towards the horizon of deadline always

always too close

fearfully frightened of falling

into darkness

sliding over the edge of the known land

finding solace in the abyss of failed  projects

curiosity turns into dust

fat rolls of dust

waves of dust in an ocean of boredom

and certainty

silence slithers hand in hand with hopelessness

nothing new, nothing arousing

appears until a barometric change

rolls across

swish! swirl!

feathering swarthy faces and ghostly white eyes

’tis coming! ’tis coming!

lo and behold! dark and full cloud

in need of emptying rumbling

over the dry forgotten land

trickling, tinkering, letting go

torrents of inspiration

penetrating the craquelure

transforming, filling up

impegrating immortality

thunder approaches, voices distinguished

and nurtured by desert ears

tickling neurons, zapping grey matter

praise the voice of the community

we might be out of the woods


I’ve been writing stuff – short stories and poems – since I can remember myself. When I was 11 years old, I stumbled across Sylvia Plath’s poems (The Colossus and Other Poems in English with Estonian translations) and these changed how I wrote poetry and how I perceived what’s possible in poetry. Sylvia’s poems liberated me from trying to rhyme and showed me the power of imagery and word play, contrasts and emotions.

2015: A Bipolar Year

I mostly write this review of 2015 for myself because I’m good at forgetting the good stuff. There shall be personal stuff in the post, so you’ve been warned it’s not only about testing.

The Darkness

2015 was a weird year. There were some great things that happened in my (testing) life and career but also some things that really stretched my capacity for grief, that ended some traditions, that ended my family as I’ve known it for a long time. I woke up in New York in the middle of the night after TestBash to learn that I have no more grandmas left. I lost both of them within less than a year. And cancer ate up a close family member. He was a couple of years younger than me. It’s one thing to lose someone suddenly, it’s entirely different to see your loved ones suffer and turn into people you don’t know, to see them in this state and realize their life is over very soon, or hear “there is nothing we can do anymore” from a doctor. I’ve been to many funerals in my life. You’d think it gets easier but it’s tougher in a way because you know exactly how you will feel and you still have to go through it. The nice charts of stages of grief are a load of bullcrap anyway…

The Highlights

There were some great highlights for me in 2015 beside the darkness (which is why I call 2015 a bipolar year).


I started my job as Head of Testing in February 2015. That was a step in a different direction for me as I’ve previously worked as a team lead. So now I’m the competence lead for testing in a 600 people organization.


I spoke at Copenhagen Context and TestBash New York.

You can listen to the podcast where I discussed my talk with Mark and you can listen to my talk here:

I was the program chair for Nordic Testing Days. Technically, I put the program together already in 2014 but I was involved in marketing and different kind of activities behind the scenes up until the conference (and then ran around frantically while my testing friends tried to tell me to calm down). I was a nervous wreck for the fact that quite a few speakers had to be replaced during the months leading up to the conference as they dropped out for one reason or another, and one of them dropped out the night before… I was extremely grateful for having three presenters immediately offer to do a talk, and great kudos go to Katrina Clokie who ended up doing one. In the end I was satisfied with how the program turned out because my goal was to help create a conference that I would like to go to. The theme “Agents of Change” was close to my heart and it looks like it touched other people, too.

Erik and me got accepted to Let’s Test 2016 and we’ll be doing a workshop there!

I attended Let’s Test 2015 which was awesome. After that I visited Erik’s class of future testers in Örebro.

I was invited to TITANconf by Kristoffer Nordström and spent a couple of wonderful days in Karlskrona discussing leadership and testing in the company of a bunch of great testers across Europe. I mean we had a dedicated conference beer! What could be better…

I also attended the fifth PEST (Peers of Estonian Software Testing) where we enjoyed the workshop Kristjan Uba had set up for us. We were trying to figure out if testing craft was social or technical.

Problem Solving Leadership

A very important highlight not only because I met Jerry Weinberg and ravaged the bookshelves in his house (twice!) but because I learned a lot of useful stuff that I keep going back to (this must be the PSL-ers’ mantra). I definitely don’t look at the world the same way after learning from Esther and Jerry.

It’s also no less important that I could attend PSL with my friend Erik. I’m pretty sure we doubled the ROI between the two of us by having discussions and analysis sessions during the workshop. In any case, he’s one of the people who kept me sane last year.


I learned about how to figure out what my job is supposed to be (a surprisingly unobvious thing that I hope to blog about). I learned that doing research and collecting data can be useful but also incredibly frustrating if you can’t make sense of it, and can’t find a good way to make sense of it. I also learned how it feels to be somewhat afraid of your research results

I learned about designing and carrying out workshops and retrospectives. I ran a couple of workshops alone in the offices where I travelled to. In collaboration with my colleague Siim Sutrop we designed and carried out a workshop for tutors who would be teaching a batch of newbie programmers. We also designed special retrospectives for the tutors and the newbies separately to gather their feedback. And now we are on to designing and testing a framework for helping the tutors to learn to tutor. Since Siim has been experimenting with retrospectives in his team, I got to sponge on his experiences.

I learned how to run a Lean Coffee. I’ve run the events internally and also facilitated the first public Lean Coffee in Tartu.

I learned about change management and change patterns. Some of it I knew, some of it was new. I want to drive some changes, so I need to know how this works. Luckily, I have a new colleague now who is the change management manager and I can learn from hear (trust me, I’m like a sponge now) and we make a great team, too.

I learned to look at testing and testing problems in a 600 people organization spread across 6 countries. I love systems thinking because without it I’d still have blinders on (or maybe I still do, who know…). I’m not sure I advanced my knowledge very much about testing topics this year but I did learn a lot about how testing looks like to a wide variety of people on different places in the hierarchy.

I learned about understanding my skills from Alexandra Casapu in her wonderful workshop at Let’s Test. I had some discussions with her afterwards and shared my thoughts on the workshop. She also created a prototype webpage for building your skills map. I’m planning on creating a similar workshop for testers in my organization.

I learned about career development and job descriptions. It’s difficult. Really difficult. I will have to write about this at some point to explain. When it comes to the seniority levels, my instict says “RUN!” because people are different and “cookie-cuttering” them doesn’t make sense. I don’t personally care for the junior/senior distinction because I’m looking at the content of my work and the value it delivers (and I look the same way at others’ and I don’t care that much about seniority). But it looked like these things are important for other people, so I tried to document the skills and knowledge for each level so that it still makes sense to me. There’s still work to be done.

I learned to hate the word “guidelines”.

I learned about how HR works as I supported them throughout the year.

I learned that (internally) consulting a project that was messy is hard. I need to go back to Weinberg’s “Secrets of Consulting”. I guess the good thing was I was able to identify someone to take the lead in testing matters and help her enough so that she succeeded and is still going strong.

I learned that joining sketchnoting skills and systems thinking can be nifty. I sketched the organization from different angles to explain to C-level where and why I saw problems that they could help to solve.

I learned that I really like to work with people to help them grow. But hey, I actually knew this before🙂

I observed that if I keep thinking and sharing my thoughts, chances are I will hear them repeated at some point. Not sure what I would learn from this but hey…

I learned… probably many other things but these have already been incorporated with my existing body of knowledge.


I travelled to 3 new countries for work purposes (Lithuania, Serbia (2x), Romania (2x)). In Romania I had the pleasure of having some beers with some folks from Tabara de Testare. In Belgrade, I managed to meet Predrag and talk testing next to some great Serbian food. And I guess we’ll have some great Estonian food and beer in Tallinn as Predrag will be speaking at Nordic Testing Days in June.

I travelled to the US twice (for TestBash and for PSL). I also travelled to Denmark and Sweden (Copenhagen Context, TITANconf).

I travelled to 3 new countries for vacation purposes (Slovakia, Austria, Hungary).

And in the process I had layovers in Finland, Germany and Latvia. That makes 12 countries visited… Yes, at some point people asked if I was still working or only flying around because it looked like I was departing somewhere every few weeks. Last autumn it was somewhat true…

Testing Stuff

I signed up with Testlio to do some hands-on mobile testing and to understand how their platform works. That was fun and also allowed me to polish my self-organization skills because one has to be efficient to get the most testing time out of the 1 or 2-hour slot.

Other than that I did very little hands-on testing. Which is why I this part of my brain gets itchy and I need to find some way to scratch the itch this year (and also to not let my skills atrophy too much). Helping other people to solve their testing problems is one thing but I don’t feel like it would keep me very fresh.

I guess that’s it. Sorry for another mammoth post but that’s the way I roll.

Here’s to 2016! I know you will be awesome.

Writing Conference Proposals

I have had some success with speaking at conferences (Nordic Testing Days 2013, Copenhagen Context 2014, TestBash NY 2015). That being said, I’m in no way on the plus side when you deduct the rejected proposals from the accepted ones (and then there are those I was on the brink of submitting but never did). I do have some experience with reading a couple of hundred proposals being part of different program committees. So here are some thoughts on writing conference proposals that I have developed based on the experience I’ve described. I’ve also critically looked back at my own earlier proposals and winced a lot. I hope I can offer some useful pointers to aspiring conference speakers to make something good come out of my wincing wrinkles. I assume you bring good content because I’m mostly going to cover the form.

I feel like I’ve developed some sort of a way of writing conference proposals that I’m comfortable with. It has taken me about 3 years, rejections, self-doubt, and reading a lot of proposals. As far as the latter is concerned, I’ve been lucky to have been on 2 different program committees and I’ve been the program chair for Nordic Testing Days 2015 which has helped me develop some insights that I’ve found useful when writing conference proposals.

Read Fiction

One of the basic premises of learning to write well is to read a lot. Preferably, you should read a lot of fiction, even if you’re primarily writing non-fiction texts such as blog posts, articles on testing, or conference proposals. There are several articles available about the benefits of reading fiction if you look around the internet. In my experience, fiction gives you access to different kinds of worlds which is good for your imagination.

Reading fiction also gives you access to different textual worlds where to pick up subtle cues about

  • style,
  • syntax, and
  • vocabulary.

Of course, it also makes sense to read non-fiction texts. If you read a good article on testing and  an article you don’t fancy so much, try to describe to yourself what you liked or didn’t like, which one flowed better, what kind of weaknesses you noticed.

Read Other Proposals. Many of them.

I feel like reading a large number of proposals has given me a fairly good list of things that make a good proposal and has helped me learn which proposals aren’t convincing. If you’re not on a program committee, you still have access to conference pages where you can read the selected proposals. It’s a filtered pool, of course, but you will still find some proposals to your liking, and also ones that don’t touch you in any way.

  • Can you notice patterns in the proposals you like? What kind of patterns are they? What about patterns in proposals you don’t like?
  • What kind of structure do the “good proposals” have as opposed to the “bad” ones?
  • Can you spot differences in language, idiom and style between proposals you like and dislike?

The questions above are the ones I’ve used when I’ve done close reading of fiction or philosophical texts.

Study the Genre

If you study a set of proposals closely, you will also learn about the genre of conference proposals. I argue that conference proposals could be looked at as a genre within non-fiction texts. Typically, genres (such as science fiction, romance, fantasy, etc) have certain traits that help you differentiate between texts and categorize them.

Some characteristics for conference proposals (according to my unscientific impressions):

  • appellative function – a conference proposal is meant to convince the reader (that this proposal is worth being selected and presented at the conference) and also the participants (to attend the session once the proposal has been selected). I’ve seen proposals where the author must have forgotten about this function and has focused on explaining their idea to themselves not to others.
  • characteristics of content – conference proposals typically attempt to answer the why, what, and how about the talk or workshop and also reference expecred outcomes for the participants
  • structure – a conference proposal tends to have some sort of introductory paragraph, and another paragraph that contains key takeaways (inline list or bulleted/numbered list) or other information

Brevity and Clarity are Your Best Friends. How to befriend them?

Thou shalt not shackle your tidings in the seductive fumes of adulating idioms and menacing metaphors that shan’t betray the apple of your eye for the epochs to come.

Even if you don’t use excessive metaphors, don’t try to sound like one of those LinkedIn titles (“The FIVE THINGS You Are Doing Wrong”, “The Seven LIFE-CHANGING Ideas to CHANGE YOUR LIFE Today”) that give you all the thrills but none of the content. If you’re too secretive about the content of your talk and cannot concisely summarize your key points in terms of content, then all you leave me the reviewer with is the decision between trusting or not trusting the sensationalist claims. Why would the participants trust you and come listen to the talk? People want to know what they can get (for their money). I will write about reliability at another time…

Read your proposal to yourself out loud. If you stumble or stop, that’s a heuristic for a potential problem. Thinking and speaking are related in our brain and actually activating the muscles to form words with your mouth can change how you think and feel about the words and the ideas behind them.

Pitch your talk in a minute. Now pitch it in 30 seconds. A mirror will do and your countenance shall be your partner. That’s how I test the conciseness of my message and the clarity of my thinking.

Getting your proposal reviewed is a good tactics to employ (and a good exercise in getting over yourself). I’ve noticed that sometimes I’ve written the draft in one way but when I show it someone and they ask some simple questions, and I start explaining the content again, I end up with better focus and a better nutshell.

You can use rhetorical questions as a device but don’t go crazy with them and develop a whole paragraph with wandering thoughts peppered with questions. It’s normal to have such a version in the draft form. I typically try to write more at first to clarify my own thinking. However, later it’s time to cut the fat and make it lean. Simplify, refine, and clarify.

Don’t overdo brevity so that your proposal is just three short sentences and I’m left wondering…

“Why” is your “Bestest” friend

Whichever way you start out writing your proposal, at some point you have to address the “why” behind your message. I’ve seen plenty of proposals lacking the clear answer to “why this talk matters to some people” (or even to the author). You can address the “why” in different forms, such as key takeaways.


This is something you’ve heard before: practice makes (you) perfect great enough. If you study others’ proposals, you may feel like emulating someone’s style when writing your own proposal. Actually, this can be a good idea. Don’t get frightened that you’d be plagiarizing their work – you’ll just be practicing by copying their work. One of my favourite authors Hunter S. Thompson copied “The Great Gatsby” to get the feeling for how it must be to write like Fitzgerald. He also copied Hemingway. There are other writers who’ve done that, too. This is a different kind of practice when you’re developing your own voice and style for writing proposals.

Some Well-worn Advice

Related to copycats, there’s another piece of forlorn well-worn advice: be yourself. Whatever is truly unique about you will shine through the short piece of writing that a conference proposal really is. So you may end up writing proposals that aren’t quite like you because you’re still learning from others or you get affected by your reviewers. But… over time the conference proposals will emerge that look like you, feel right, and, potentially, get accepted (I haven’t talked about the content but have assumed your content is also relevant and interesting). The only way to get there is to keep writing the proposals. Look back on the ones you’ve written, ask for feedback after they were rejected, and see if you can come up with something else.


I’m nowhere near scoring a speaking engagement every time I submit but I personally feel like I’m finally getting a grip on how it feels TO ME if I write a proposal that gets accepted. I’ve taken note of how the accepted proposals are different from the rejected ones (both in terms of content and form) and I’ve done it in the ways I’ve described above.

Let me know in the comments if you have some great tips that you’ve found useful. I’m sure I’ve left stuff out as I wrote about things that came to mind right now.