Harnessed Tester

We watched Everything Everywhere All at Once a few weeks ago, just around the time I was starting my new job and career. Unlike most people I’ve spoken to who seem to think highly of it, we enjoyed it but didn’t exactly find it Oscar-worthy, but it’s the title that’s most stuck with me since.

As I’ve written before, I’ve left the world of being an engineer and have become a full-time coach, which is a big enough change on its own. But that’s not all – with a new company comes new (wonderful!) people, new systems, new processes. On top of that, there’s an unfamiliar language, different technologies and even a new operating system. While I might leave “Harnessed Tester vs MacOS” to another post, it’s feeling like everything everywhere is new to me, and it’s happened all at once.

Everything new? All at once!? How do I cope…

Seemingly tangentially: I do not have the widest range of household tools. I suspect until home renovations and decorations start to become a thing, that’ll be unchanged, but despite this I’m still able to help put up a perfectly horizontal curtain rail in someone else’s house or fashion together a shelf for fancy tea in our kitchen. I have enough familiarity with DIY, the tools and materials that I can fairly confidently branch out into similar but new things.

At work, I’m in an alien world, but many of my tools still work here too. I’m able to draw upon previous experiences, approaches, oracles and everything else, in order to learn more about my role, the company and how I can best add value.

In a recent tweet from Jenny Bramble (@jennydoesthings) in reply to a question about testers “starting from scratch” she says:

You’re not starting from nothing. Everything you’ve done has led you to this point and will influence your testing career. Your curiosity, willingness to learn, any jobs you’ve had…they’ve all prepared you for this.

This is hugely insightful and relevant, and not just for me. I’m working with apprentices in both software development and quality engineering for whom much, if not all, of what they are seeing is new as well. Crucially though, they too are not starting from nothing. They also have a set of wide-ranging tools from different disciplines and backgrounds that they’re bringing to the mix and using to help learn and gain footholds in the new materials.

I’ve been very careful to say to them from the start that “I’m new here” and to not even vaguely pretend I already know everything nor immediately have all the answers. I want to coach by example when it comes to learning something new. I will learn as I go and will show that I’m learning as I go, doing it myself, hopefully demonstrating that none of us are starting with an entirely empty toolbox.

After 213 months, my exciting news is that I’m switching careers and have got a new job as a Quality Engineering Coach.

I’ve written before about this being a very deliberate change. I had been looking for opportunities to use the skills I’d been developing over quite a few years – mentoring, teaching, onboarding, interviewing and the like. Perhaps naturally, perhaps naively, I’d assumed that the next appropriate job title in my path should be something like Test Manager or QA Director, but I’d found many of the available opportunities to be lacking in the one thing I found I really wanted – interaction with and the development of people.

A number of the jobs whose Manager or Director titles I saw seemed to want something (in my professional opinion) that I wasn’t and something other than what the job title looked like, such as a senior automation engineer. They certainly weren’t talking about the team, the people on it, testing as a thing running along the core of that part of the company. I found myself unsure – was I looking for the right thing? Had my plan of managing a test team been the wrong one? Did I have some rose-tinted or just very optimistic view of how test teams could or should be?

Then the Fates conspired one evening to show me a coaching role at the very top of the Ministry of Testing job board. I applied quicker than a greyhound out of the traps. It offered a chance of applying the skills I’d developed, still with that testing basis, but was also a breath of fresh air – a new direction and an opportunity to give something back to the industry I love by educating and introducing new busloads of people to it.

Truthfully, it’s a somewhat nervous time! I’ve been an engineer for a lot of years and have spent 12 and a half years in the same company too (sure, with different roles and responsibilities and directions, and a new owner). As with almost all new jobs, I’m leaving behind the known and heading off to the slightly-unknown.

But there’s something else there too, amongst the nerves. It feels like I’m fuelled by some heady mix of anticipation and eagerness.

Like most new jobs, while I do have some idea of what I’ll be doing day to day and working on once I join, I’ll have more details – and things to write about – once I get under way. As I write this, I’m a bit over two weeks away from my start date and have one week left of being an engineer. The coach will be setting off shortly – enjoy the journey…

Next month will see the end of almost 18 years of me being a test engineer.

It’s a scary prospect in many ways, not least for the realisation that it’s a very long amount of time generally, let alone in a single career – the vast majority of people starting university next month either hadn’t yet or had only just been born when I started out on this path. It might seem a long time to dedicate to one thing, but it helps that the testing profession is one that’s incredibly varied and rarely dull.

I’ve been involved in at least: customer support, operations, working with suppliers, demos, training, writing documentation, project management, development (as in, I wrote code and then deployed it to live when someone was away), auditing, electronics, hiring, IT, and probably double that amount of other things I can’t immediately think of off the top of my head. This is all before getting onto the varied roles within testing itself, from performance to security and a thousand others.

It’s been an exciting ride with exposure to lots of other things, as well as a surprise – when I started out, I never thought it would bring so much breadth of experience both within and outside of one profession.

I’m not sure I thought I’d still be a test engineer after so much time, but I’m not really sure I put much thought into any of it when I started out – I’d struggled with having a Computer Science degree but little programming skills (which seemed to confuse hiring managers who assumed everyone would be a rockstar developer after such a course) and was looking for something that would be a slightly better fit for me than what I had been doing. I feel lucky that I “fell” into this career with little information and no real guidance, at a time when a lot of things were starting to change in the world of testing as well, with no real plan or idea where it could take me.

This time, I’m not “falling” into anything. I’m not changing career because I stopped loving testing nor am I choosing this new path with uncertainties and a lack of a plan. I’ll still be in and around the testing profession and community, so this (sometimes infrequently updated) blog pleasingly continues and I may even rediscover my mojo for writing topics.

I’ll write more about my future role nearer the time, as a separate piece to my current and old role.

Given a tester’s professional endeavours to look anywhere and everywhere for problems in a product, is there a risk that we’ll be more liable to turn this fault finding upon ourselves?

I think testers have to work in a surprisingly tough world. We’ve often got tight timescales, insufficient information or resources, changing or diverse demands, an ever-present issue of never being able to find all the bugs… and yet we can still be at the heart of an issue found in production – “why wasn’t that tested?” some (less well-informed folks?) might ask.

On the face of it, it could be a reasonable question warranting reflection to see what could be improved across an organisation. But how many among us testers have felt a twinge of personal responsibility? Maybe even a lot more than a twinge? Feelings of guilt, questioning ourselves, our decision making, our core fundamental abilities of being a good tester.

Having been there myself, on more than one occasion, I’ve ended up with three distinct reactions to this that work as a group (and make a fair assumption about how we’re doing our job):

• We are professionals and we’re striving to do a good job – it’s not like we’re sat back twiddling our thumbs, staring out the window. We work, and worked, hard.
• We did find other issues with the product before it made it into production. Recognise that we did contribute through our testing, and we did add value.
• We made justifiable, sensible, informed decisions at the time – whether that’s what to test or what not to test. Just because a decision turns out to be wrong in hindsight, doesn’t make it wrong at the time we made it.

While these could be used in discussions with other people or teams, they’re aimed more at the individual tester who may now be doubting themselves and/or their work.

There’s also a risk of feeling held back when doing the testing in the first place – “What if I miss something?”. I have little comfort here but do have words of advice: you will miss something – some day, some product or feature, it’ll happen. Understanding that and recognising the bullet points above beforehand, I find goes some way to helping deal with that fear. Be professional, add value, and make justifiable decisions about our testing.

Being kind to ourselves and recognising that, very much like our products which we’re testing, we are not and can never be perfect, is a very important and lifelong lesson.

I was rummaging through some paperwork the other day and rediscovered a notebook from my first testing job, all the way back in 2005. (Aside: yes, in a couple of months, I’ll have been testing in my job for 16 years!) I was a hardware and software tester, working on things like vehicle telemetry and positioning, and we were tracking a lot of (sometimes very badly behaved) truck drivers around the country.

In that massive A4 notebook of mine were pages of “To Do” lists, from things like registration plates of vehicles I needed to check/upgrade/debug, units needing production testing, support calls to follow up on and the like. These were often migrated from one list to the next, with “done” things not being copied across and then more things added at the bottom over time, struck through when done, until a time when the list was migrated again to yet another page. I’ve seen others do similar and I found myself still doing things that way about 10 years later.

Why did I keep doing it that way for so long? I guess it was convenient as it was something I always had to hand, quick to add to, allowed for some extra scribbles and notes alongside and gave that satisfying feeling of crossing something off the list after having completed it.

But there were drawbacks too. How many times must I have rewritten certain items across lists, or missed things? How much time did it take rewriting them? How awkward were the annotations of things that were waiting on someone/something else, or needing updating or replacing with a different task? There were only so many combinations of struck-through asterisks alongside underlined but since crossed-out items that were possible and I’m not sure it all made much sense at times.

I grew tired of the inconveniences and started looking for a better, digital, way of having a To Do list. This was a struggle though – either things were too basic and didn’t cover everything I wanted, or were too cumbersome and tedious. Some, like Wunderlist, lasted for a while and I sensed I was onto something… only to discover I’d forgotten to use or update it for a couple of weeks, which was pretty damning evidence that something wasn’t working.

The revelation was that I had multiple, specific requirements for a To Do list and its items:

• What is doable and what is blocked
• What are my priorities
• What have I successfully done
• Needs to be quick to edit, annotate/expand, etc.
• Needs to cope with things changing e.g. something becomes blocked or unblocked, something becomes a higher priority

and that all the items on the list fell into five simple categories. I initially had four, but the fifth in this list served an extra purpose:

• Now: high priority things that need doing ahead of anything else
• Next: medium to low priority things that can be tackled when the Now list is empty
• Stretch: (named after Kickstarter stretch goals) things that are on the list and could be done, but for whatever reason they’re bigger or more complex or just not quite ready to be started or a bit out of reach right now
• Blocked: anything that’s not currently with me and blocked by a date, a person, another task, etc.
• Done: where to put the things once they’re completely finished with, which provided a great weekly summary of my “Done” list to report

Using something like a Trello board and the five lists above completely altered my management of tasks. Not only had I worked out that everything fitted into just five lists/categories, but the quick drag and drop functionality between lists, quick addition/amendment of items, and occasional coloured tagging gave me control over my tasks. Having it in a browser, alongside key high-usage tools of email and calendar, made it front-and-centre and something I was more likely to use.

While this approach won’t work for everyone, as we’re all wonderfully different, it changed my daily working world. I had more visibility of what I had to do and could be doing, it gave me a way to react to changing situations/requirements, and not only made remembering what I’d done in the week easier but the increasing set of “Done” items made me feel good about progress.

I’ve been using it for around 4 years now, non-stop, and that’s a strong sign of something that’s really working for me, and how I work.

I don’t write about books I’ve read. In fact, I don’t even really like talking about books I’ve read, either. Part of that comes from schooling and an expectation that I’d be able to do stuff like analyse a book as part of English Literature, and discover a clever allegory the author has inserted. I remember nodding along with a deer in headlights look, not really understanding and certainly not feeling brave enough in my early teenage years amongst peers to stick my hand up and exclaim “wait, what?”.

The other part of it is also embarrassing, for me, and that’s: I read what I think some would consider to be seriously lowbrow stuff. There’s fiction, and then there’s fiction. Completely unrealistic rogue warrior/survivalist/ninja heroine fighting back against the CIA? Yep. Alcoholic, torture device tester who hires circus performers to infiltrate a compound. Uhuh. End of the world with both a pandemic and an invasion? Of course. End of the world followed by the embodiment of evil arriving? Oh yes. In fact, there’s a lot of end of the world stuff… And these are not from fantastical fiction authors like Terry Pratchett which might make my reading selection seem more respectable.

I read them for their ridiculous escapism and for the fact that I’ve been obsessed with the end of the world for much of my life and am thus drawn to any new interpretation of it that comes along. That’s where most of my books sit on the spectrum – firmly in a “I don’t want to talk about it on a favourite book list” (#6books6people) kind of way, even if I absolutely thoroughly enjoy them.

So I feel woefully under-equipped and in no position to properly write about any book, let alone a non-fiction book from someone who is famous and writes stuff that’s really good, filled with humour and I’d be really happy recommending to friends. (I’m reading it, and others, in order to broaden my horizons from a work and management perspective.)

Except the book by Michael Lopp (a.k.a. “Rands”) called Managing Humans contains a chapter called NADD (Nerd ADD, chapter #36) which wouldn’t have been written differently if he’d spent the day chatting to me about who I am, what I’m like, what I like and how best I work. I’m aware of the bias here too (cf. https://en.wikipedia.org/wiki/Barnum_effect), but I’ve spoken about the things in that chapter and they relate precisely to me. So, for once, I really felt the need to write about a book, albeit very briefly. I can highly recommend Managing Humans, especially that chapter, and I’m grateful to Rands for writing it.

And from that, I found out that I am a “nerd”. Mind you, I could’ve worked that out from looking at the other sorts of books I usually read…

If you’d like to read the original post by Rands that made it into the book, it’s available at https://randsinrepose.com/archives/nadd/. Here’s a quote:

The presence of NADD in your friends is equally easily detectable. Here’s a simple test: Ask to sit down at their computer and start mucking with stuff on their desktop. Move an icon here, adjust a window there. If your friend calmly watches as you tinker away, they’re probably NADD-free. However, if your friend is anxiously rubbing their forehead and climbing out of their skin when you move that icon 12 pixels to the right, there’s NADD in the house. Back away from the computer.

Sometimes, you can find yourself testing something very new, and very big. Perhaps there are lots of people working on something together for the first time, not many specifications around, a number of potential ideas and directions, new technologies and/or a host of other things. This doesn’t necessarily mean something is wrong – it’s just how things are.

As such, one might expect there to be a lot of issues, and again that’s not necessarily a surprise, it’s just a natural transition phase from “nothing” to “something” and as testers we’re here to help with that. Issues in this sort of project could really be anything, from personal preference (stylistic), to font colours (accessibility), buttons not doing anything (functional) to out of memory errors (maybe stop-ship).

As well as being a rather special opportunity, it can pose some particularly interesting challenges to a tester. For me, it can throw a few out of memory errors in my own head.

With so much information flying around – and I’m not even talking about the stuff beyond the issues – it’s hard to keep track of them through a sort of observe, record, report, discuss, prioritise, review and verify process even when it’s just your own things, let alone all being aware of those from anyone else on the team (not just testers).

There are also risks that you’re swamped with observations and don’t report them all. Perhaps you’re duplicating issues others have already raised. Maybe it’s taking so long to officially report things that you’re getting behind on the testing and giving quick feedback to the developers.

Some tactics have worked well, whether they’ve been deliberately implemented or arrived at naturally over time. For example, rather than raising everything as a separate bug, issues can be recorded under a single bug, each issue with its own unique Id. The advantage is that these can be concise, thus quicker, and means less time is spent on paperwork/red tape and more time on finding, recording issues and giving timely feedback. It can also mean that more things are recorded, as even the self-prioritised low priority trivial stuff can be noted quickly, and might be perceived as a higher priority by someone else.

By having the issues in fewer places and with less to read, it can also help with getting a good overview of what the issues are. That’s good for both avoiding burning time investigating something that’s already been investigated, but also gaining an appreciation of the product as a whole – which areas aren’t as stable right now, where haven’t we looked for a while, etc.

There are risks too though, and some of their effects we can minimise. Tracking these multiple issues in one place requires a degree of care to make sure everything is fixed or gets preserved to be addressed later on. I’m particularly keen to make sure that the time we’ve put in to find these things isn’t wasted by losing the issues somewhere along the line, however important they’re currently deemed to be.

It also needs some consistency in how they’re handled (e.g. unique Id creation scheme), discussed and prioritised. It also really helps when everyone else is on board with the approach too – for example, having a developer enumerate an issue list and report back status on them all separately is a wonderful help.

Also, being concise can cause some details to be lost and/or misunderstandings. It’s good to accept that and be understanding of each other when it happens. If the reproduction isn’t clear, add more details (e.g. a screenshot) until it is. If there’s a lack of a common language to write things concisely, work at creating one and get everyone involved so there’s both some spread of knowledge and agreement.

So, how does this particular tactic help with my memory issue? By having this system in place, it’s possible to keep more on top of a constantly fluctuating (status and issue creation/resolution) situation, rather than having it run away into a set of issues that can’t be easily tracked, nor quickly parsed, nor fully appreciated. I’m also less concerned about trying to keep too much in my head at any one time, when I have faith in a system that’s working well.

I recently had another great discussion with a developer, essentially over hot drinks in the kitchen. We covered all sorts of topics, a lot around how testers and developers can help each other when communicating in bug reports. It’s a sensible and productive conversation to have, since both sides – and maybe others on each team – can make simple changes that really benefit the other.

Naturally, we also talked about those awkward bug reports – ones that are hard for either side to reproduce. The developer appreciated and understood that as testers, we don’t want to write bug reports where it’s not entirely clear, or the steps aren’t reliably reproducing the problem, or we’ve only seen it happen once – it’s really bad, but we’ve no idea what we did! These things happen.

I agreed and said that I really don’t want to be raising those sorts of bugs. I’ll put an appropriate amount of time in before conceding that the benefits of raising it now outweigh the cost of pressing on. Maybe the developer can suggest a route to reproduce it, just from the vague description or error message? Maybe the developer can quickly guess what’s happened and doesn’t need lots of reproduction steps?

I also said that I didn’t get any pleasure from raising bugs generally. Then had to stop myself. Wait a second… I do take pleasure from it… but from where?

It’s certainly not that I’ve “broken” something that a colleague has been working on, nor is it that I enjoy having to tell them they’ll need to make more changes or fix something. If anything, I’m really wishing for the opposite outcome of the test.

It’s also not that I’m secretly celebrating the fact that they’re there because of an ambiguous specification, or tight deadlines, or misunderstandings. The world isn’t a perfect place and we’re all working hard to do good things, at the right time, to a high standard.

So what does make me swing my chair over to my tester colleague and eagerly say “guess what I’ve just found”?

What gives me pleasure is how I’ve found the issue. Maybe I’ve created some awesome automation that’s highlighted a memory leak through having done millions of combinations of tests. Maybe I’ve built in some analysis of key metrics that have suddenly flagged up a regression we’ve not caught anywhere else. Maybe I’ve tried the new feature in combination with something else we didn’t think would have an effect but does. Or maybe I’ve spotted something that’s been right under my nose for ages and I’ve managed to take a step back to notice it.

These things make me happy as someone who is a professional tester. The fact that the company can then make a better informed decision (fix it, document it, don’t ship now and wait until we’ve dealt with it, etc.) as a result of that work, and the fact that I/we have learnt something about how to test it, are the cherries on top of the cake.

This week, after goodness knows how many years of being on the lesser-populated side of an interview table (i.e. being interviewed) and about 12 years after starting to be involved in interviewing, I’m the one running the interviews.

There are enough extra pressures already with this new role – getting the timing right, keeping the conversation flowing, introducing and wrapping things up – but I’ve also started really wondering about and analysing the questions that I’m asking.

Some are open-ended, where I don’t know where the candidate might go with their answer. They’re good for debate or general discussion and can sometimes help discover their views on something, for example. Maybe it’s their reasoning behind why they want to become a test engineer or how they approached a problem, but sometimes those answers can be quite short or simple and asking a follow-up question to such a response is tough.

Some are directed, where I’ve got a specific idea in mind. Where I’m looking for a specific answer or confirmation about something, those are fairly easy. I might instead be trying to guide the candidate towards an idea or maybe to start talking about a problem in a particular way, but I find I end up having to give more guidance and content in the question so that it’s either a closed question with just a really easy yes/no answer, or that it ends up being unclear or wordy.

A fair number are planned. I’ll always prepare some key questions in advance on things I really want to know. Maybe there are some omissions or ambiguities on the CV, or maybe there was a suggestion in a previous round that they have a preference for automation testing over manual. These can be more carefully scripted, but even then, they’re sometimes jarring as one-off questions that don’t fit as well into the natural flow of a conversation.

Most are spontaneous. Oftentimes my questions are as a result of other things that have come up during the interview, where I’m picking up on an interesting detail from what they have just said, or coming back to a testing approach from earlier on that relates to what we’re now discussing. Having thought through the purpose or intent of that question in advance is rare – I’m usually listening to the candidate talk, rather than tuning out and considering the “why” around the next thing I ask.

A rare few are wonderful. I remember a non-tester talking about working on some script and having to do some “trial and error” (a lovely lead into a question about testing). Those that illicit a deep intake of breath, followed by a thoughtful and genuinely intrigued “Now, that’s a good question…” are such nice ones. Even asking no question at all and leaving silence can sometimes be rewarding, as the candidate offers up new information or comes up with an even better solution to the previous problem. But they are a rare few, and I’m still striving to make them more common.

There are of course innumerable approaches out there for asking good questions, from STAR, to making sure you’ve got common terminology and clarified scope, listening more, asking tougher questions first in a sequence and getting the tone right. I’m well aware of them – it’s putting them into practice that’s the challenge.

While an interview is predominantly about judging the candidate (yes, they’re weighing up us and our company at the same time), Voltaire doesn’t entirely agree:

“Judge a man by his questions rather than by his answers.”

and I do feel like I’m there to be judged, too. It drives me to try harder and try to do better each time, even if sometimes I worry that the only really good question I’ve asked recently is the one in the title of this post.

I spent many happy hours during my childhood watching Whose Line Is It Anyway? (the original UK version, of course), a stand-up comedy show where a group of four act out different scenarios suggested by the audience with particular themes, traits and/or restrictions on what they can do verbally or physically. I spent my time admiring people like Ryan Stiles and Colin Mochrie and their ability to switch characters and plot lines at the drop of a hat. Not only that, but almost everything they did came with some comic value (and from what I’ve seen of them they’re still just as funny to this day).

Years later, I found myself asked to run an hour long session on something to do with line management, as part of our company’s Community of Practice on the topic. I’ve had a preference for practice over theory for most of my life (particularly at university while on a mainly theoretical course) and fancied emphasising the “Practice” part of the meeting’s name. It wasn’t that I wanted to turn line management into a stand-up routine, but Who’s Line Is It Anyway?’s difficult situations and additional imposed restrictions on how those situations could happen felt like they would make for an interesting line management role-playing exercise.

I decided to split the attendees into pairs – one would play a line manager role, line managing the other in the pair who would play a “direct report” role. I developed some decks of cards (with the help of various resources including The Coach’s Casebook and numerous lists of personalities available on the web) called the Situation Deck and Personality Deck. The basis of the idea was that each pair would alternate between the roles of line manager and direct report, with the line manager picking up a card from the Situation Deck and for around 5 minutes, role-playing that line management scenario.

I split the session up into three rounds, sandwiched between some introductions and time for reflection at the end:

Round 1: understand the general format (no Personality card)

Role-playing is generally not an easy thing to do. I’ve heard that those doing stand-up often start by running through various warm up exercises, similar to stretching before physical activity, just to ensure that their creativity is loosened up and a few inhibitions lost. So I started the session with something fairly simple – line management situations to be acted out with no additional constraints, and a decent amount of time in which to play through the scenario.

A line manager in a pair took one card from the Situation Deck, read it without showing the direct report (unless it said otherwise) and then took 5-6 minutes to talk about the situation with their direct report.

This worked well as some had questions about the format which took up a little time for clarifications, and there was some hesitancy going into it. Emphasising that it was a safe space in which to try things out with no repercussions helped relax the pairs a little bit, but as they all went through round 1 with its two situations and switched roles, they all seemed to settle into the exercise.

Round 2: impose a restriction to make things difficult (direct report sees and plays trait on Personality card)

After the warm up came the complication – now, the direct reports got a chance to take and enact one trait from the Personality Deck, without the line manager knowing what it was. The line managers took a card from the Situation Deck as before. They had a little less time, around 4-5 minutes as they were more familiar with the exercise.

All of a sudden, the line managers were trying to have potentially awkward conversations with their direct reports who were no longer responding in an expected way. Maybe they were being evasive, aggressive, suddenly very assertive or coming up with excuses, leaving the line managers in a certain amount of confusion. Their tactics for talking about their Situation card now derailed by unexpected behaviours.

I’d asked them all to play the roles respectfully, as though they were talking with their manager at work or someone for whom they’re responsible. Otherwise, it would be all too easy for the role-playing to get rather over the top. After the round, I asked and found that some of the line managers were able to identify Personality traits or some at least comparable behaviour, but it was still awkward for them. Interestingly but perhaps unsurprisingly, direct reports found playing their Personality traits to be tricky as well – images of comedians finding that same thing rather tough on Whose Line Is It Anyway? came flooding back.

Round 3: change the rules to make it more realistic (both parties see direct report’s Personality card)

The final round was arranged to be the same as the previous one, but this time the line manager got to see the Personality card as well. It meant that for the final round, they were able to go into it more prepared, taking care with their wording as they worked through the situation but also having a better understanding of why their direct report was responding or reacting in particular ways.

The conversations were noticeably less fraught, with the line managers treading more carefully and direct reports presumably being triggered far less frequently by what their line managers were saying.

The round was designed to be more realistic – although still contrived – giving line managers the chance to better know their direct reports, just as if they’d been line managing them for some time and knew their personalities. It didn’t make the Situation cards any easier to deal with, but it did make their approach and interactions more appropriate.

After the round, I gave the pairings some time to discuss a few things with each other:

• How the final round went
• What approaches worked well, given the Personality card that was in play
• What they felt their partner in the pairing had done well during the session

The last part was important to me, especially given some of the more awkward interactions I’d witnessed. I wanted people to leave the room having taken something positive away, having had to look for something positive in their partner, and feeling respectful.

Downloadable Content

Shortly before the end I joked to the participants that they were welcome to take decks of the cards with them to play with other colleagues, friends and family, but realised that it might be something useful for a wider audience – you, dear readers. So I’ve attached the decks of cards for you to print out (double-sided), cut into decks and try with your teams should you wish.

line_management_role_play.pdf

I can give some tips for running the exercise:

• We had a time limit of an hour, which is reasonable so long as you start promptly and stick to timings of 5-6 minutes for each of the situations in round 1, and 4-5 minutes for the four situations from rounds 2 and 3
• Remind people that it’s a safe space in which to practice, that nobody is judging them and that nobody is going to be asked to “perform” in front of the rest of the group
• Put a timer up somewhere so attendees can see it – more importantly (since very few looked) give them some sort of bell or beep 1 minute from the end each time
• Do make sure there’s time to reflect on the exercise at the end and to discuss takeaways
• Recommend to the pairs that they don’t get too bogged down in specifics and details – the short times for the role-playing help avoid too much detail, but having the pairs talk generally makes for easier conversations
• Shuffled decks of cards make for some great random pairings of Situation and Personality, but these can sometimes be very easy to role-play and sometimes very hard – I quite liked the variety, but you may want to remove the randomness and deliberately pair cards together

If you do give it a go, please do leave a comment below – I’d also welcome any feedback on the exercise, format, decks of cards or any other part of it.