The interviewee side of interviews

There's a lot of advice flying around about how to interview testers. I get that people are concerned about finding the right person to join their team, and recognizing what makes a good / great tester is relevant, and that with the modern team work approaches the person needs to gel into the team. But let's look at the recruiting process from another angle: the one being (potentially) hired.

I enjoy my current work a lot. Things are better because of me. Things keep getting better. We try some great stuff, and I adore my developers for the intellectual challenges they pose me (when they need my help) and for the great stuff they do (making me feel unnecessary). There's two things I'm regularly missing: other testers to grow with me and harder problems to solve. And I'd love to relocate to California for private reasons for the right job, if that would present itself.

I don't actively look for new work, but every now and then there's something I can't quite resist taking a better look at. The positions I've looked into recently would serve my need of other testers to work with and harder problems (being significantly behind in agile adoption and quality-related practices) and I would have a lot to offer.

I've just gone through one recruiting process to the point of having to make a decision of whether I accept the job or not. I'm still undecided on my choice, and wanted to share a concern these recruitment processes have in my perspective.

As the trend of the era is, there can be a lot of work without compensation as part of the recruiting. There's the manager, team and HR interviews (or even more). There's a full day of psychological tests. And there might be a day of working with the team. All unpaid. Things that happen while I should still be at my day job earning my monthly salary. Things that make me take unpaid vacation or give up weekends to compensate for the lost hours.

The feeling these processes give me is that I'm a liability. The processes bring out all of my weaknesses (which I'm well aware of, having been through these tests and discussions many times before) and mention my strengths in passing. I feel I'm being heavily filtered for possible inappropriateness. And this filtering is expensive for me. I don't have the corporate resources behind me. This is significant money out of my personal pocket, and I refrained from writing about this up until the point that I knew this was not a bitter rant of being rejected, but a consideration at a point of accepting me after all the filtering.

I think back to the time I was about to join Granlund. How my manager back then used a bit of the time in the interview into getting to know I was a tester they are looking for, but majority into making me feel like I was wanted and welcome. And I remembered discussions with one of my smartest old colleagues who mentions that the really good candidates need to be approached differently, to make them choose your company over all the other options.

I'm sure I'm not the only one out there who has a lot to give (and expects to be paid for that work fairly). I'm sure I'm not the only one who feels many companies could use my skills and expertise. I'm sure I'm not the only one who feels that I'm interviewing the company and reflecting on their value system just as much as they are interviewing me.

Interview shouldn't be just a filtering process. It's also a sales process. Why would you want to give your capabilities for this job and this organization? Money is not the defining character for quality of life around work. For me, sharing some of my values are a defining character. And making me invest days into recruiting process for the assumption that that is how these processes works just feels wrong and outdated. 

Kicking testers out and making developers testers too

There are some discussions that make me both happy and sad at the same time. I had one exemplary version of these chats at Agile Alliance Technical Conference right after my session I wanted to share with you.

My session was about exploratory testing an API. I wanted (and succeeded) in creating an experience in mob format where people would apply exploratory testing as a group on something without a user interface. So we were testing ApprovalTests. I like ApprovalTests for many reasons. First of all, testing a testing framework is so wonderfully meta in many ways that I feel a lot of testers would have intuitively ideas about what could be valuable in that domain. Second, it has extensive unit tests and a large number of users (or downloads, rather). It could work. I would love to test something that mostly works, to not get bogged down with the simple bugs but to actually show where value of exploration lies even with "well-tested software" like ApprovalTests.

I felt pretty successful delivering my message, and especially enjoyed the insightful and deep end-of-session questions. There were a few testers in the room, but my perception was that the majority of my audience was developers.

One of the developers approached me after my session, with the experience of what they might be missing focusing on testing as artifacts (automation) over testing as performance (exploration). He shared that his company had let go all of their "QA folks" and been told that they are doing all of the testing among developers. And now he could identify they had a skills gap.

The genuine interest he showed to learning these skills and becoming a better developer was what made me happy. There's nothing about exploratory testing that developers couldn't learn if they realized that it was a set of skills in its own right. While the little mob had just shown that people with a tester background were more function & value focused in exploring and dared to ask for better usability of the API, the difference is a learned behavior on both roles. What I do as an exploratory tester in my team coins down to two things: perseverance and serendipity. I stay with the software longer giving it more chances for positive surprises of it failing in ways I can't even expect. And it helps me to stay around longer that I too "test until bored" but don't get bored very easily as there's so many dimensions, so much viewpoints and so much variation that I never need to approach a problem the exact same way.

What made me sad though was the idea that there are organizations, who will throw away skilled people in my craft for missing some part of the skill (often explaining what they do). Instead, they retrain other people to do that work, often complaining that 1) there's lack of people with the right mix of skills available and 2) there's so few women in the industry.

I believe I can train developers to explore. But I could also train the testers to work better with the developers, and grow into their full potential. The 1st is a positive opportunity, and I love  how many developers are actively volunteering to learn that - fast tracking them to seniority. But the 2nd is a lost opportunity that shows how little people mean and how little we're willing to help them.

The world is full of "commodity testers" that are that because that is what they think they're asked. Those of us who have fought our way of the that cast keep fighting regularly as there are managers who would love to put us back into the stupid old ways. But I have so far met very few people who, given the chance wouldn't grow fast.

The environment often makes us what we are. Change the environment. It's not an overnight thing to change, but changing all of the software work into high-value assumption is so worth it. For both organizations and individuals.

The Awakening: Improved Discussions on Features

Something really interesting has happened, and I wish I knew what caused it. My team feels more courageous, more active in taking a stand about design of features and we do so much better!

This started happening around the time we started Mob Programming together, so I would attribute practical, hands-on work around fun and laughter has a lot to do with the increased courage. We also started discussing more about our values and what we'd consider our role to be, encouraging initiative, so the explicit asking for this might also be a contributing factor.

The ideas of what needs to be improved are now constant. The discussions around concerns of our designs are now shared. And it's rewarding to see how those discussions morph the features we're implementing.

There's been three very different yet similar experiences recently.

The first one is a lesson about power of mockups with business users, in understanding if we are building the right thing without building it. Things where the users have found it hard to contribute early on, we're now getting actual discussions around use cases. A user experience specialist has added some of the needed focus in that area, taking developers into the discussions too.

The second one is a lesson about power of conversations. We identified a need, and two opposing views to approach it. The first idea seemed implementation/risk-intensive, so we analyzed the second seemingly easy option to learn it was implementation/risk-intensive on a different, more under the hood way. Connecting the lessons learned from the two, a third option emerged. Something that was never on the table without my hands-on pairing session with a real customer, but something that seemed blatantly obvious after understanding how our customers use was different from our own use.

The third one is a lesson about initiation. We've found many places, most recently today, with relics of old ideas of how the software is supposed to be extended that never turned reality. Instead, they create complexities and places of errors. These come out actively, as people are working on the areas.

Where there might have been a feeling of unability to do anything about these before, now there's hope. And the hope gets stronger through the shared actions we're taking.

Experiencing the awakening from within is wonderful. I love seeing how developers take on the full potential they have in creating great products. And looking at this reminds me on how fragile this is, how the environment focused on separation of roles could again take us back to past. 

From unwilling/unable to willing/able

I've been having discussions about teaching and coaching as part of being coached and as part of mentoring that I think of as form of coaching.  With this post, I wanted to share the a model that helps me make some sense in to the world.

Situational leadership or something of that sort

Many years back, I read a post somewhere on the idea of which seems to map to a concept of situational leadership (picked up the word from googling what I remember - the dimension labels). When working with people at different places on the map, you do things differently.

For people who are unable and unwilling, the help they need is career coaching, disciplinary actions, detailed delegated tasks, well-run meetings, making decisions for them, focusing extra effort on testing as a feedback mechanism, encouraging good behavior (working code over lengthy designs, prototyping and unit testing, small stories and tasks, team shared responsibility) and playing with peer and manager pressure to get the person out of the place they're in.

When you're at the point of unable but willing, you're really in a fruitful place to learn. The help needed could be highlighting successes, identifying learning potential and steps, assisting with difficulties, and checking on status and feelings. Great things to do close to the work is helping people take tasks through delegation, giving guidance is new types of decisions, giving feedback, encouraging teaching others to learn from each other.

When you are at the point of able and unwilling, the help that is needed is attitude coaching, selling options as opportunities, and focusing on responsibilities as employee. This is a time to step back and let the person plan more, still enforcing small stories and tasks, with focus on personal accountability and deadlines.

We'd love to see people who are both willing and able, and whatever we do when they are not one or neither, is to help them get to a point where they are both. At this point, people still appreciate highlighting and rewarding successes (and being reminded that failing is learning, and when learning, that is a success!). Encouragement could be directed towards cross-training the others and continuing to learn, offering advice on decision making (but making sure the decisions are done by the people, not given from management). And even with people in this stage, there's often stuff outside the team that needs attention, be it to highlight the successes of these people as internal marketing, or removing roadblocks in cross-departmental work.

People who are unwilling are hard to work with. While unwilling and unable, these two might be connected: hard to be willing to do things you fail at doing. However, some of the trickiest problems I get to deal with are about lost motivation. When you've been put in a weird place for long enough, you start thinking the cave you're in is what the world looks like. You might not like it, but you know of nothing else.

I find that sending people outside is critical. Quoting a friend who chose to stay anonymous:

An average person at a conference is above an average worker at a company. Insight of the day.

— Maaret Pyhäjärvi (@maaretp) March 30, 2016

Go out to find a way to be willing and able. You need to see outside your cave.

Learning from a customer through strong-style pairing

We've been working on a set of features on our product we've labeled around a customer. They're features beneficial for others too, but they're existence is particularly important for one.

At some point of this, we already learned that taking down the distance between the programmer&tester and the customer was a great idea, helping us a lot in solving  the right problem. As often goes, the second hand information was distorted turning it into a feature instead of the need, and the best way to solve the need was altogether a different feature.

With the past learning of direct contact behind us, the product management had no issue with the idea that I would be trusted with getting the customer to use the product too. I was told to write a guideline, and in addition I scheduled a workshop with the customer.

Armed with the goal of knowledge transfer, I asked the customer to share his screen on Skype for me. I walked him through the login, guided him to the library his task was to fill out and made him do the work instructing with my words. I created him an experience of use, and in the end we retrospected for a while on what he learned and found complicated. While observing him as he did what I guided him to do, I learned of a missing feature he never realized to ask for as he even now did not see that was his need. And from our session, he could now do the things that were abstract. The guideline I wrote might be a helpful future reference, but much less necessary having the experience (not a demo) of use under his belt.

Later, I talked with the product manager who assumed I had "demoed the features" and seemed very pleased with the idea that the customer had been my hands on this demo saying he wouldn't have thought to do that. I labelled what I did: Strong-style pairing - for an idea from my head must go through the others hands. The label gave it a place in the ways to do things in the product manager's head, and he said he'd try that too. "Never thought of that", he said. I could feel smug about having thought of it, but the truth is I was told to think of it 1,5 years ago. I too NEVER thought of that before - that the roles in how you pair matter a lot. 

Mob Programming Conference - see you there?

There's one conference I'm going to as an attendee, not a speaker, and that is Mob Programming Conference, on May 1-2 in Boston. I wanted to invite you to join me there with this little post.

I'm from a family with six children, so being around others has been my natural state. Two of us ended up in the software industry. I became a tester and my brother became a programmer. I always thought it came from what we were good at - so very fixed mindset of me. Looking back, I remember limited access to computer at home. I remember the lan-parties for boys only. And I remember being quite happy and content not facing weirdness by trying to join anything I did not feel welcome to.

I chose to do something where I would be welcome. Where I would not stand out too much. And where I would not get special attention and help because I'm a girl, without giving up my interests. And software testing is perfect - both genders are equally loathed upon in most place.

I told myself I don't really like programming. I told myself I had (which is true!) enough to learn on other stuff. But for the other stuff (team collaboration improvement), I volunteered myself to work as a mob with my team - one computer for getting the code in and my taking my fair share.

I learned that learning this coding stuff is easier than most stuff I've dealt with under the label "testing". Stuff that programmers say are programming, I say is testing. The thinking and analyzing. The understanding the problem and solution. While my programmers may at first tell me "var" letter by letter, a moment later I know that and learn more as we go. And with my presence, we avoid many costly mistakes, have a better big picture and a voice of conscience reminding that we really did not test enough yet.

In a mob, the code isn't mine. It's ours but I can see my fingerprints all over it. I don't have to deal with the "since women don't code well, you'll need special attention on feedback that you learn this stuff". All this special attention makes me very uneasy, just like pushing myself to places I'm not welcome to. And it gives me the social aspect of work I'm craving.

I would love to see people with my type of background - and any background - at the Mob Programming Conference. With Kindness, Consideration and Respect as guidelines for the type of work in mobs, I feel safe and welcome. And welcome you to join the experience. An experience it is, with 2 workshop and reflection heavy days, only opened and closed by a talk.

How safe is your work place?

I've been thinking about safety today. Perhaps it's somehow related to talking about SAFe, the agile framework is less than admiring fashion last night, but the word has come to my mind often. Feeling safe. And in particular, lessons I've learned on what it takes to make people feel truly safe at work.

Some years back, I had a manager who believed that he needed to see me mark test cases passed / failed. He was honest enough to not try to wrap this into any methodology wrapping, but stated his true feeling: how do I know you're working if you don't do this?

We found other ways. For us, the simple thing that worked it to establish trust through the fact that our software at the time was so buggy that he knew I was working when I was logging on average 8 bugs a day over consecutive years. It took away the need of worrying, and established trust that was very important to me.

With my latest manager, the trust is extended even further. There's no cadence of me having to check in, and I've been intentionally testing the limits. With me feeling trusted and safe, I'm the natural me: excited about stuff, wanting to share, being active and figuring things out together so that he does not need me to check in, I just do. And I feel happy, I generate new ideas and act on them.

But the safety goes even further. It's a foundation of feeling nothing you do could destroy it all.

Imagine an employee who did not provide value. Or if he provided value, the value could be perceived negative. Interrupting others from creating value. Breaking things. Creating artifacts that would make further work harder. I used to believe these people should be fired. But I've also experienced now what I feel is extraordinary safety: supporting these people. Helping them over long periods of time. Thinking firing would almost be an option out of reach, even if it wasn't.

I'm realizing that action sends a message stronger than anything I've experienced before. It's safe. Safe to fail. Safe to be incomplete. Safe to try things out and learn.

That's a level of safety I'd now like to aspire for. Safety in the sense that it feels the current results-oriented world has little room for.