Last week I was so lucky to get to give my talk about the Impostor Syndrome, Feeling like a fake, at the Pacific Northwest Software Quality Conference in Portland, Oregon. PNSQC is for people in QA (QA engineers, testers, testing specialists, quality fighters, whichever term rocks your boat) so it was a pleasant surprise to find out that it was also very informative for software developers and anyone involved in software development so I was not as much of an impostor as I thought.
Now I went deeper into the reasons behind people suffering from it, which can stem from mixed signals when you’re growing up from parents regarding achievements and praise. Not getting praise for doing good, or always getting praise no matter what, skews our ability to assess our achievements realistically. Being in the minority can make us feel like an outsider from the get-go and so we quickly slip into feeling like Impostors. We can even start to feel like we need to represent our whole social group, which of course is very stressful. Organizational culture at our workplace plays a significant role, so we need to take steps to keep it healthy, so people feel safe to be themselves. One part of that is to have a working agreement, so there is a mutual understanding in your team, or your company, how you can work together in a healthy environment. The Recurse Center, an educational programming retreat in New York, have social rules which I feel are also very useful to make people feel comfortable.
- No feigning surprise
- No well-actually’s
- No back-seat driving
- No subtle -isms
My measurement on that my talk went well is getting people come up to me afterward who have related and share their story with me. Like a woman who questions if she can ever quit on her anti-depressants and still feel good about herself, a man who called his wife immediately after the talk to share with her what he heard and a remote worker who was so intrigued about getting his team share their feelings that he was going to get them to try it, even though usually he’s not much of a feelings-sharing-kinda guy.
When I read the description the talk of my fellow European, Zeger Van Hese,The Power of Doubt — Becoming a Software Skeptic about being afraid to say when you don’t know, I knew I had to see it. Zeger took us through his journey from being unsure of himself as a tester because he felt bad not having all the answers to being a confident tester that makes decisions based on evidence and rationality. I wasn’t sure at first where he was going with it when he started talking about his ventures in trying to explain the unexplainable, like ghost hunting. But his talk then proved to be highly entertaining as well as making you question your senses and your memory. Try this illusion where you see something completely different than reality, or try to unhear the hidden message in Led Zeppelin’s Stairway to Heaven played backwards, when you’ve once read them.
These may be silly little experiments, but they make you wonder, how much of our perceived reality only exists in our perception? How can we KNOW anything when we’re prone to display confirmation bias, finding rhymed statements more accurate, and believing even more strongly when given evidence to our beliefs? What we can do, is to use scientific methods, starting with Occam’s razor, to think critically. Maybe not believe a developer who says something doesn’t need testing, maybe think twice when we feel like we already tested this and don’t believe the majority just because. As a software developer I have a strong logical side to me, but as a poet, I’m very emotional, and these two opposites of me sometimes clash. This talk was an inspiration for me to start to question everything, starting with myself, to understand me and others better and improve my communications.
Hard Conversations: Project Quality & Project Sponsorship
I met Payson Hall on a speakers dinner the night before the conference where he was a bit distracted since the PNSQC app didn’t show his talk, so he was worried that he wasn’t on the schedule. Fortunately, it was just a bug in the app which somehow had slipped QA (pun intended). His topic, communicating with the Project sponsor, seemed to be just in the line of where Kolibri is moving (that is, the cultural transformation only gets you so far if the project sponsor does not agree with it). I hadn’t heard this term before, Project sponsor, but I immediately knew what people meant and related to how important it is to have the Project sponsor happy and informed since, in the end, it’s his or her decision where the project is going. Even though a product owner and the team are autonomous and have much influence on what they work on, there can always be some business or market decision that the project sponsor only knows about and is equipped to make decisions.
So what is the best way to have that difficult conversation with the Project sponsor? Perhaps this is a project you have been cheering for as a product owner and is not going as well as expected? Maybe some premises have changed, or things didn’t work out as planned? Maybe this is a software development project and all that could go wrong did? Nobody expects us to be able to control how things go, but what we can control is how we react when we realize that things are going differently than planned. If you tell a project sponsor that everything is going down the drain, you can bet that she will ask why you didn’t say anything sooner. The best way to communicate difficult things are to have a cheeseburger talk, i.e. get her out of the office and talk over a cheeseburger or a salat. This makes you get her full focus, and it doesn’t look as dramatic as it might otherwise be. Remind the project sponsor about the feasibility and risk of the project, then the situation. Never say that something can’t be done because how are you going to prove that? Instead, say that you don’t see a way and you need to work out where to trade-off to accomplish the desired outcome.
The Future of the Testing role
One speaker didn’t make it, and last minute James Bach was brought in to talk about the Future of the Testing role. His talk was excellent, so I’m glad things panned out that way. It was almost like being at a standup, he was so confident and threw off jokes, mostly about himself. James is a guy that doesn’t care about what others think of him and likes conflict. Maybe that’s why he does so well as a testing specialist, because in this line of job you have to be good to stand on your opinion and be ready for conflict when saying something isn’t done. James doesn’t want to be called a QA person or a QA engineer because he doesn’t look at his job as assuring quality, but he’s testing things and making sure they work. He made a solid argument about that testing is very accessible, and anybody can be a tester, but to be able to test systematically, write reports and analyze results, you need to be a testing specialist.
Even though testing is very accessible, it requires specific skills and a certain mindset to stay in it (and enjoy it). Testing is unbounded; you never know when it ends, so you need to let go of uncertainty. The hardest thing about testing probably is that better developers make testers feels useless! It’s an emotional struggle, you don’t want there to be bugs, but when you find one you feel thrilled. It’s like firefighters, they don’t want houses to be on fire, but when it happens, they feel good about it because they can help.
To be a good tester, you have to:
- Test deeply and reliably
- Explain and defend testing (how and why)
- Question and challenge assumptions
Katy Sherman talked earlier about the importance of breaking the silos between QA and developers, but James didn’t see it like a tester was in a silo. Instead, a tester lives in a villa and invites people in. Everybody can come and swim in the pool of quality and dine at the table of testing. But then the guests go, and the tester cleans up the mess and does the dirty dishes.
There is a current pattern of the testing role not being seen as a necessary role, but instead, everyone should watch out for the quality and everyone should be testing. Agile has given developers most of the power, and unit testing and automated tests are the hot things right now. James once had a conflict with a developer that proclaimed that testing was so easy, he had done so and so many automated tests and it was so easy. It wasn’t until long in that discussion that James realized that for that developer testing was easy because he was only testing a contained part of the whole thing and then yeah, testing can be easy. But to test the entire thing, all possibilities, then testing is hard. The downside with everyone being responsible for quality is that it can lead to nobody taking that responsibility. So the testing role is still relevant and is always very important. There are cases that a test manager is sufficient, whose job is making sure that everyone is testing.
Finally, some pro tips for testers; Save stories of terrible bugs to defend testing and create your private group where you can throw questions and thoughts about testing around and get a response from people you trust before you go and challenge your boss.
Build A Workplace People Love — Just Add Joy
The final keynote was by Rich Sheridan who wrote the book Joy Inc. about how he created a joyful culture at Menlo Innovations. His book inspired us at Kolibri, and my some of my co-workers met with Rich when he came to Iceland a while ago. Rich talked about how he had felt miserable in his programming job after climbing the corporate ladder. From working in chaos to bureaucracy to agile, which was a blend of those two. After the company he worked at became bankrupt after the dot-com bubble he tried being a kano instructor. It didn’t take long until he wanted to find the joy he had first felt when programming and was sure that he could create a joyful environment with simple structures and processes. Rich founded then Menlo Innovations who provide innovative consulting and software development. Everyone work in pairs who are rotated on a weekly basis. And since people switch places all the time, nobody has their machine, but they have many different kinds of computers and versions of OS which means that all code is constantly developed on various platforms. Headphones are forbidden and everyone works together in an open space. Personally, I’m not a fan of open spaces, but I can see how it can work for a pairing culture like that. Meetings are life-sucking, so they are kept to a minimum and instead discussions are made ad-hoc and quickly. They do have a daily meeting which takes around 13 minutes with 70 people. I call that efficient! They have an interesting approach to their weekly review meeting with their customer where the customer shows them the project instead of the standard vice versa. Just as at Kolibri, transparency is regarded essential and a part of that is open salary. As someone that has gone through burnout, I’m a big fan of their no-overtime policy.
I haven’t read the book yet, but it’s high on my to-read list now. Even though at first I felt some of Menlo’s work processes are a bit out there and is maybe not for everyone, after thinking about it, I can see people thriving in it.
All things must pass
Like at all great conferences, it’s not just the talks that are inspiring but also the people and I made some great connections. Portland is an amazing city with quality food, quality coffee, and quality people. Americans are generally so open and friendly, and even more so in Portland than in many other cities. Finally, a big kudos to the organizers of the conference, especially to Joseph Ruskiewicz who showed me around and made me feel like a local.