 Okay, yeah. So hello everyone, my name is Deepak. I'm a quality engineering manager in Red Hat and with me is Jallak. She leads the Red Hat customer portal search quality engineering efforts and everything that goes with it. And our second guest who is still trying to find a way through the Hopin app is Swapnil. He leads the QE efforts for our internal integration platform called Hydra. So he's more of a mid-tier person and Jallak is more of a solar. Oh, here is Swapnil, hello Swapnil. Hey, hi, am I audible? Yes, yes, I'm listening to you. Hello, hello guys, hello all. Sorry for being like, that was some issues for connecting to Hopin so I hope I don't need to say anything. That's okay, okay. So again, welcome to Ask the Experts panel for the software quality assurance track and we hope you enjoy. So it is going to be a very interactive session. So I'll probably ask Swapnil and Jallak to introduce themselves first and let's see. Let's start with Jallak first. Thanks, Deepak. Hello everyone, I'm Jallak and I've been associated with Red Hat from around, from past two years and I'm working as a senior software quality engineer in Red Hat, looking forward to talk to you, everyone here. Thanks, Swapnil, over to you. Hey, hello Jallak, hello Deepak, hello everyone. So I'm Swapnil Chado, I'm Q-lead at Red Hat. I've been associated with Red Hat for close to three years now. Mostly I'm interested, like my area of interest are specifically in the automation, specifically the microservice automation sorry, any of the AP automation performance testing. So those are my area of interest and this topic is really interesting and I'm looking to share my views and hear your old views as well on this topic. So yeah, really excited for it. Thank you, Swapnil. So everyone who is hearing us, please type in your questions during the event as well, it's not a presentation so that you have to wait for the end. Just if at any point of time you feel like asking a question, just type it in, I'll read it out to our guests and we'll try to see what their views are on that topic. All right, so starting in the beginning, let's start with building a fence around what psychological safety is, right? Let's start with Swapnil this time. Swapnil, what do you think? What is your idea of psychological safety? We see it has to us like psychology and the safety. When we talk about the safety, it gives you a safety net wherein you are safe in that zone. You can make mistakes, you can do mistakes, you can learn from those mistakes. So basically psychological safety for me is something wherein I have the freedom to be heard or to be making mistakes and still not being worried about being punished or being penalized for those, my opinions or questions. So yeah, that is what the psychological safety means for me. Excellent, Yalak? So for me, we can say that it is a shared belief where which is held by the members of the team and the others on the teams where you do not feel to be embarrassed, rejected or punished for speaking up. Now, consider a situation yourself being at home. You are just yourself and you be very comfortable. So similarly should be the situation when you are at office. People should feel comfortable of being themselves. They should be bringing their full selves to work and it should also allow for an honest discussion about results so the results could be good or bad. So whatever takeaways could be. So this is what psychological safety means to me. Just be yourself. Okay, so talking about this particular problem, right? Psychological safety for testers. So historically speaking, if you go back, let's say, 20 years into software development, when we had this old school waterfall model, testers were mostly a support group who would be included at the end to validate whatever was built, was working fine and then give a sign off and then so that they could release those golden CDs to the public, right? So it's very recently that line between a developer and a software is blurring, which is good, right? But still see something which is very deep rooted, stays in our unconscious point, right? So do you think that, do you think that given the fact that testers have always been considered a support group? And some critics will even go to the extent of calling testers the second class citizens of software development, right? So in that sense, in that sense, do you think that it is highly important for whoever runs, whoever is running the team, it can be a product manager or a project manager or a PO or anyone or an engineering manager, right? Who is the directly control of taking decisions in the team? Is it important for them to properly take care of these things, right? That testers don't feel left out, they feel included. So my question is for Sopnil, Sopnil, do you think that psychological safety as a concept applies more to testers in a development team? Yes, Deepak, I definitely agree with this, like we're in testers, this concept specifically applies to testers more. Basically whenever we hire a tester or any other QA engineer on our team, what are the qualities that we look for? We look for the critical thinking, we look for inclusion as we look for the collaboration with other teams. So these are the basic things or the basic attributes that we look in the testers whenever we hire them. And all these attributes of a QA testers, they are quite closely related to the psychological safety. If a QA testers or any of the QA is not safe enough, like it doesn't feel or willing to ask really hard questions, stakeholders or business analyst or your developers, definitely the quality would impact. If all the soft questions are being asked, definitely the quality of your software isn't going to be that great. So definitely this concept is really applicable to testers. They should be free to ask the questions. However silly it may sound, however silly the question may be, but they should have this platform, they should have this freedom of asking this question. They shouldn't be judged or rather mocked for the simple questions because they might not have the technical background which the developers have for developing those applications. But they bring in the perspective of the customers. They bring in the ideas or the vision of the customers for that particular application. So they see the application from the customer's point of view. So if they are given this freedom, only then they will be able to ask questions to the developers, business owner, project manager, and that's how it will indirectly help the entire team. So yeah. So you're saying that they have to be given some kind of freedom, right? Yeah. Right. So Jalak, what do you think? What are the steps that we need to take to get psychological safety protesters in the team? So by now we understand how important it is to have a psychological safe environment in our workplace. So there are a few hacks, a few steps that we can share with you to see how we can have a psychological safe workplace. First is we should be meeting each other's needs. So now when you're interacting with your team members, you need to be conscious of their preferences. Too often managers make decisions without even consulting their direct reportees. So we need to figure out what your employees want in terms of communication style or one-on-one meetings or feedbacks. So that you show that we actually care for them and this is how we can bring some amount of psychological safety. Also, when you have taken their feedback, make sure that you follow up and was that feedback fruitful for them because of the requirements or the mindset of the people keep changing. Then other thing could be, you know, you have to, the trust. Trust is the key of psychological safety. You have to establish and build trust. So you need to strengthen an employee's trust when you have gained trust. People are comfortable being themselves. And believe me, if you have gained an employee's trust, you, there could be a healthy employer or manager relationship. Employees who trust their managers are more committed, more productive and then they communicate better. So building a strong workplace culture which is rooted in trust is more important than ever. The other point I would bring in here is, you know, go for the appreciation, go for frequent appreciations. We all like to be, we all like to get appreciated, right? So in a survey, it showed that around 93% of the employees wanted to be recognized quarterly at least if not more frequently. So people value recognition from both their managers and peers, be it genuine, personal or meaningful. So though recognition costs nothing, but then it can have major consequences if not done. So make sure that you are appreciating your, appreciating your team members frequently. Next one is show empathy. Now consider the situation when you're putting yourself in somebody else's shoes. Though it takes time to understand the person, but then it pays off in speeds. Listen to people and then acknowledge their thoughts. When employees show empathy towards each other, they're more likely to continue collaborating in the future. Nowadays, what the issues are that people do not collaborate or people do not speak up, but then they should be feeling very comfortable in speaking up. They should be knowing that their decisions would be respected, right? Their decisions would be acknowledged. When people do not speak, they do not speak out of fear. So next is include them in decision-making. Make sure that you make them feel valued, that their decisions are being valued and how important their decisions are. Collaborate with your team when we are making decisions. So more and more input would give you a good feedback. And then this is a great way to involve everyone. It's a gather continuous feedback and then review it as a team to build collaborative action plans. So this is how I think we can, these steps can help build a strong psychological safe environment. Okay. So what I gathered from your points is that the essence is that every person is unique, right? The management needs to let them assert their individuality, right? So some people are on the left side of the introvert, extrovert spectrum, right? And some people are on the right side. Plus this is a spectrum, right? This is not a binary thing, right? Yes or no? So, right, okay. So, but the things, the points that you mentioned, Jallakar very generic for every employee, right? So what is that special thing about testers that you think should be there? How can we fix it for testers, especially? I think we need to be very vocal, you know? Our job is being, it tells us to be very vocal, speak out. So I'll give you an example. So in the past, there has been a tragic incident where, you know, a Boeing jet was crashed because as for the design that the BA gave, that the BA gave was overburdened and because of which a lot of lives were destroyed. So the pressure to keep the plane on schedule, overroad designer is concerned. And this, because of which the jet safety was not met. So this led to two crashes and then around 346 deaths and thousands of planes were grounded after that incident. Now, so engineers knew that the shuttles were doomed, but they were afraid to say anything to the management because they were afraid of the consequences. How would the people react? But they could not say. And since it is, at that point of time, they were being not vocal, this led to such a big tragic incident. Now consider, put yourself in that situation if this would have happened to you. So whatever the result may be, good or bad, it is required to be vocal. You know, the QO people are seen as the gatekeepers of any application, they criticize, they point out the weak points. So it's been, for us, it's been an easier and harder time both. But then, yeah, it's our job of doing that perhaps, and it requires a larger sense of psychological safety to dare to speak. You have to dare to speak, no matter what the consequences may be. Don't consider it what the people may think because they can take it as a criticism. But then, yeah, this is our job, and we have to do it. Okay, excellent. Okay, a quick time check. We have 11 minutes, and a quick audience check. Anyone has any questions so far? I just feel free to write them down in the chat section or the QA section. Okay, so something in my next question for you. Let's say I put you in charge of finding out, there is a team out there, right? Let's say inside Red Hat, a team that is working iteratively to deliver software to their stakeholders or customers, whatever. I put you in charge of, as a spy, to detect whether this, let's find out the maturity of the psychological safety in this team, right? What would be your markers, your cues to detect that psychological safety level? So Deepak, this is really an interesting question. So like, there is one old saying that says, like, don't shoot the messenger, but that is not exactly happening, right? Now today, what is happening? The person who is raising the issue has been shot right there itself. Like that is what is happening as of now. So in psychological safety, let's say there are two teams that we have. One is actually following the psychology safety and it's well bounded with each other and another team which is not well, they are not well gelled with each other. So there has been a couple of features done and let's say if we have to parameterize a couple of things, if we have to see like whether, particularly following the psychology safety or not, it can be quite easily figured out. We can just check a couple of things or detecting whether it is present in a team or not. Like first thing is how often does the manager talk to their employees or all the associates? Not only talking about having the one two meetings, but also taking the frequent feedbacks from the employees. Like whether they are feeling safe, whether they have their, like, is their voice being raised? Like, is there a way to take it into consideration? So people might not raise these questions in the meetings, but they might raise it to their individual manager. That is the first thing that how frequent these one-to-one meetings are happening and how effective they are. Second thing, let's say if you're giving any presentation, in case you're giving a grooming session or any presentation, so always see how many questions, follow up questions that you're getting. So in case you are getting a couple of follow up questions, either you might not for two reasons, either like all the audience, all entire members of the teams, like they understood entire project, entire requirement, or they're afraid of asking the questions. They are embarrassed because I might ask a really silly questions. So whenever you're presenting an idea, presenting a requirement of the, check how many follow up questions that you're getting. You might not get the questions right after the presentation or after the describing the requirements, but after a certain time, how many follow up questions that you're getting. So this couple of parameters will help you to understand whether my team is comfortable or not. Another point is like how well the team is gel, like how many, like ownership of the mistakes, let's say there is some issue that has been happening. How effective are your retrospectives? Like how, you know, how the teams are using this retrospective meetings. If they are able to own their mistakes or like they are pushing this mistakes to each another, if we see these kind of parameters, it means that people are not able to own those mistakes. They are feeling like in case I own this mistake, definitely there will be some issues with my career or there will be some issues with my arrays. So all those things, these are the couple of parameters which we can consider. So yeah, for judging the same setting, right. So I was reading a blog somewhere and especially for testers. So let's say I go to, so we, the problem is manifested in a different way. When you are a tester that reports to a QE manager, but works in a separate team, right? So in those scenarios, so what, as a manager, what I should do is go to that engineering manager where my QET member works and ask them, have this product or the service that you are developing for, let's say one year, being challenged or the process with which you developed this thing. What was the last time someone really criticized or challenged this thing? Either your process or your product, right? And was that person a tester? If the answer is yes, was that person a tester? So calculating, like we do in when we hire, when we try to notice the gender ratios in tech, right? We see the talent pool. How many CDs are we getting in the gender ratio? And what is the gender ratio in the team, right? So you have to find those points. So in this case, the point is, if a process or a product was criticized or challenged, let's say 10 times in last six months, how many times was it distributed equally or it is just two or three smart people in the team who always criticized freely without any fear, right? So yeah, good points. Okay, seven, 24, six minutes. So Jallak, my last question for you. So when you say that we have to speak no matter what, right? So I think this has that mental illness conundrum, right? Where let's say somebody is not feeling okay, right? We tell him to cheer up, calm down if somebody is not, right? That does not, that never works, right? So eventually we have to align accountability with the authority. So the person in authority is accountable for making sure there is psychological safety in the team, and that can be their direct manager or whoever is running the team, correct? So who do you think is responsible for and how can you properly hold someone responsible for maintaining the psychological safety, especially to testers? To me, it looks like it could be the other way around also, but to me it looks like that a manager has a, or manager or the leaders have a key role to play in this. Consider, now this is my practical experience when I have been going through this illness of having a lot of thoughts were going into my mind where I was being, I have been depressed by other members of the team. So I somewhere had a trust on my manager that he's going to, if I share my feedback with him, he's going to acknowledge it and work upon it. So my manager always ensured that the psychological safety is there in place and always confirm for me that are you feeling psychological safe? Now, but if I say manager, we have discussed a lot of points where whatever role manager has to play, but on the same front, I would say everyone in the team should also be responsible for bringing in psychological safety. And why I say is this, if you're having any problem, you have to step up and go to the manager and discuss it instead of having, instead of going through that, bringing yourself down and not feeling a psychological safe. So it is very important from our point of view also, are we reporting this to the leaders or our managers? Managers can help get rid of this, but then are we trying to do that? So of course, managers need to understand their reportees, need to gain their trust, need to have to address all their concerns, and then we need to come up with our problems also. We need to report our problems. So you are saying that both parties... Responsibility lies on both, yes. Yes, yes. Okay, let me see if we have any questions, no questions yet. I think we have one, sorry. Okay, yeah, yeah, go ahead. I think we have one from David Duncan. Tell us a statement that you must speak out, doesn't mean that you have to be insubordinate, does it? The manager is very much responsible party and by definition must trust the team as a whole. So Chalak, could you take that? Of course, yes. Thanks for the question, David. By this I mean, sometimes there's an insecurity where a manager doesn't trust the efforts or the capabilities of their reportees. So this could be a situation where the deadlines have not been met or the manager has the fear or the insecurity of the deadlines being not met. So there, a manager needs to have a lot of trust on the employer and when they show that trust, the productivity comes out from the team. Like a small example where you are just micromanaging your team, how would the team react? And then you ask your employees to just finish your work, how much hours of a day you work, be it three or four, but I want to finish the work. So this is how the trust should be. Okay, any closing remarks, Chalak and Swapnil? So yeah, as Chalak's already stated, like psychology, safety is everyone's responsibility, making that environment safe for everyone. It's like everyone's responsibility, but yes, leaders can lead it. They can set the priorities, like it is even for us, it is very important for us. But yeah, to make it safe, it's everyone's responsibility. So yeah. I should, I would be saying that it is, please practice psychological safety because it is very important for somebody's mental well-being to feel psychological safe. We think of our physical safety. We think of, so how much physical safety is important and our mental safety is also important. Most of our times we are spending in office, we are giving most of our time in office. So it's really important that we, to ensure that we have a psychological safe workplace for everyone at first. Excellent. Thank you, Chalak. And thank you, Swapnil. All right. Thank you so much, Deepak, Swapnil and Chalak. Thank you for asking all the right questions that are the need of the hour actually, given this pandemic situation and given all the psychological stuff that we are going through as testers and as programmers, as managers as well, as the employees of these and working in the software industry as well. Thank you so much for all the inputs.