I tweeted a little thought:
First of all, I believe all people are products of their environment. There are no inherently bad people. There are no people who wouldn't be able to grow should their environment be the right one. However, I believe sometimes the damage done to people by their past environments is hard to unlearn.
What makes a person bad, in my experience is that there starts to be a common perception in a team that someone is not really contributing, or that the value they contribute is negative. I'd be very careful on assessing so called badness on a short timeframe and without significant effort in helping anyone perceived bad first get a fair reassessment and then help in growing.
With these warnings, I want to share an old experience.
Over ten years ago, I was a test manager (the good old days, when I still thought being a manager was more power than being a great hands-on tester... Empirical evidence trumps speculation. Every. Single. Time.). I had a tester in my team, and the other testers were mentioning in passing that he wasn't really contributing much. Of anything.
I worked more closely with him. I talked about how he defined his job. He was enthusiastic about automation, and considered that one of his main tasks was to run a test automation set on every daily build. He had no skills to maintain the automation set, but he loved running it. He could skip the one that was failing, or remove it. And he could mark down 272 tests run every day. There was _never_ a single bug found by that automation, but he felt it covered a lot of ground. Manually, he could run maybe just 10 tests a day.
I suggested he would start skipping some of automation runs and just use every second day on adding 10 tests that were completely new, outside the automation set. I showed him how his area of responsibility had more support complaints from production than other areas, and explained I would like to work with him to figure out ways of testing that would find problems that clearly were there as per support feedback, and stop paying attention to the automation that wasn't really taking him forward with his goal of helping the team deliver better quality.
We worked on various ideas over a period of six months, and none of it stuck. We tried a lot of things, but it always all came to the conclusion that I had no clue of what good testing looks like and eventually, that I speak so much only to cover the fact that I know nothing.
At some point, I started making a journal of every encounter we had. I started giving all assignments both in writing and spoken form. But essentially, I started making a case of getting the person fired.
Out of this whole incident, I remember best one colleague who approached me. In not so many words, he came to plead me for letting this tester with troubles keep his job. The words stuck with me forever: "Just let him stay in his cubicle, doing nothing. This is a big company. They wouldn't know he does nothing if you did not tell them."
Back then, I worked to the conclusion of having the bad person leave. I was close with some of the good people leaving, as not everyone thinks its ok to have someone to share the work so that others will have to carry his weight too.
I learned back then that it is a lot of work to first make sure you help the person. And then collecting the fair case of letting them go.
Nowadays, I believe the tester back then was very harmless. He was just not providing any value. He was also not on the way of others, really, other than leaving more workload for others to carry. Nowadays, I work with developers and I know bad developers are not harmless. A bad developer can easily not create value but also make two other people work on fixing the mess they leave behind.
I still believe these people are products of their environments: years of accepting stale technology and little learning, years of siloed work, years of not considering the craft but hacking together whatever might appear to work without considering maintenance or quality.
As a tester, I tend to shine light to places that were secluded and hidden before. And when you see the mess in the corner, you need to start addressing it. Agile has many other mechanisms that do similar things. And when the cat is out on the table, it needs to be addressed.
I'm not really into talking about the recent experiences I've had on this topic, but it's great to have old experiences to refer to. I want to elaborate a bit on what I mean with bad people.The price of letting the bad people stay in your team is that the good people leave.— Maaret Pyhäjärvi (@maaretp) June 14, 2016
First of all, I believe all people are products of their environment. There are no inherently bad people. There are no people who wouldn't be able to grow should their environment be the right one. However, I believe sometimes the damage done to people by their past environments is hard to unlearn.
What makes a person bad, in my experience is that there starts to be a common perception in a team that someone is not really contributing, or that the value they contribute is negative. I'd be very careful on assessing so called badness on a short timeframe and without significant effort in helping anyone perceived bad first get a fair reassessment and then help in growing.
With these warnings, I want to share an old experience.
Over ten years ago, I was a test manager (the good old days, when I still thought being a manager was more power than being a great hands-on tester... Empirical evidence trumps speculation. Every. Single. Time.). I had a tester in my team, and the other testers were mentioning in passing that he wasn't really contributing much. Of anything.
I worked more closely with him. I talked about how he defined his job. He was enthusiastic about automation, and considered that one of his main tasks was to run a test automation set on every daily build. He had no skills to maintain the automation set, but he loved running it. He could skip the one that was failing, or remove it. And he could mark down 272 tests run every day. There was _never_ a single bug found by that automation, but he felt it covered a lot of ground. Manually, he could run maybe just 10 tests a day.
I suggested he would start skipping some of automation runs and just use every second day on adding 10 tests that were completely new, outside the automation set. I showed him how his area of responsibility had more support complaints from production than other areas, and explained I would like to work with him to figure out ways of testing that would find problems that clearly were there as per support feedback, and stop paying attention to the automation that wasn't really taking him forward with his goal of helping the team deliver better quality.
We worked on various ideas over a period of six months, and none of it stuck. We tried a lot of things, but it always all came to the conclusion that I had no clue of what good testing looks like and eventually, that I speak so much only to cover the fact that I know nothing.
At some point, I started making a journal of every encounter we had. I started giving all assignments both in writing and spoken form. But essentially, I started making a case of getting the person fired.
Out of this whole incident, I remember best one colleague who approached me. In not so many words, he came to plead me for letting this tester with troubles keep his job. The words stuck with me forever: "Just let him stay in his cubicle, doing nothing. This is a big company. They wouldn't know he does nothing if you did not tell them."
Back then, I worked to the conclusion of having the bad person leave. I was close with some of the good people leaving, as not everyone thinks its ok to have someone to share the work so that others will have to carry his weight too.
I learned back then that it is a lot of work to first make sure you help the person. And then collecting the fair case of letting them go.
Nowadays, I believe the tester back then was very harmless. He was just not providing any value. He was also not on the way of others, really, other than leaving more workload for others to carry. Nowadays, I work with developers and I know bad developers are not harmless. A bad developer can easily not create value but also make two other people work on fixing the mess they leave behind.
I still believe these people are products of their environments: years of accepting stale technology and little learning, years of siloed work, years of not considering the craft but hacking together whatever might appear to work without considering maintenance or quality.
As a tester, I tend to shine light to places that were secluded and hidden before. And when you see the mess in the corner, you need to start addressing it. Agile has many other mechanisms that do similar things. And when the cat is out on the table, it needs to be addressed.
