Building High-Quality Teams: People, Process, and Proof for Effective QA Leadership

The full transcript

Harshit Paul (Director of Product Marketing, LambdaTest) - Hello, everyone! Welcome to another exciting episode of LambdaTest XP Series, where we deep dive into cutting-edge insights from thought leaders and QA in the testing world.

I'm Harshit Paul, Director of Product Marketing at LambdaTest, and I'll be your host for this session on “Building High-Quality Teams: People, Processes, and Proof for Effective QA Leadership”.

Building a team that embodies excellence isn't just about having the right tools or having the right skills. It's about nurturing the right culture, defining clear processes, and having the ability to measure success.

But the real question is how do we go about building one such team? Joining us today as an expert is someone who has been at the forefront of quality assurance for over 25 years and is deeply passionate about team dynamics and employee engagement, Blake Hill, Senior Director of QA and Agile Delivery at AccentCare.

Blake Hill (Senior Director of QA & Agile Delivery, AccentCare) - I'm doing great. It's great to be here. I appreciate you having me and I appreciate the opportunity to be able to talk about this very interesting topic that you just mentioned. I think it's great. I love talking about this. So I'm looking forward to it.

Harshit Paul (Director of Product Marketing, LambdaTest) - I'm pretty sure everybody would love to hear about this from you because to everyone who's joining in, Blake is an expert in agile methodologies and quality management. His impressive career spans across industries from hospitality, credit, and healthcare, and his approach is all about building teams that embody both quality and unity.

And speaking on that, environment matters a lot when you talk about building a high-quality team, right? So, how do you build a supportive environment for your QA teams? What strategies help you motivate and empower them, Blake?

Blake Hill (Senior Director of QA & Agile Delivery, AccentCare) - Great question. I think that's kind of like the foundation, right? I mean, that's really the key. If you don't have this foundational aspect, then you don't really have anything to build on. So, I know whenever I've been fortunate enough to lead teams, it all starts with me and it starts with me being transparent.

It starts with me making sure that I'm able to open lines of communication and trust with the team. I think when I come into a team or if any manager comes into a team, I think the number one job they have is to basically earn their team's trust.

Typically, what I do is I just tell the team right out of the gate, I just tell them to have all of my trust, but I need to earn your trust. And then I make sure that I do what I say. I think it's really important that you define as an organization and as a team, like, what are we about?

And I just come out right with it. And I'm very transparent with the team. I can give you a great example of a leader who did this. We have a new CEO at our company. And in the first meeting that she had with us as an entire organization, she clearly laid out what she was about without telling us what she was about, meaning she was very transparent.

She was sharing personal stories about herself, her own family, and some things like that. And she came across as very genuine. And if you really want to earn people's trust, you've got to be transparent with them. They know in five minutes, people know in five minutes, if you really mean what you say.

And so when you're transparent with people, and you share a little bit about people, you share about what your motivations are, and that you really want to build a high performing team, you have to lead with that transparency. And then, know, people on your team are going to follow basically whatever they're modeled.

And so whatever a leadership model is really what's going to come back to you. So, if you want to have a transparent environment of trust, it's up to you as the leader to make sure that you are sowing that into your team. And I think it's very important that you have these established 1:1 meetings.

For example, you know, we talked about 1:1 meetings, and people have 1:1 meetings. And usually what a 1:1 meeting is, is it's like, hey, you come to me and you give me a status on what you're doing. I could have gotten that status in any number of other calls. And the one-on-one doesn't accomplish anything.

So what we do is flip it around where we have one-on-one meetings, but they own the meeting. They put it on my calendar. They run the meeting. They bring to me topics they want to talk about. It's not what I want to talk about. What do they need from me? What can I do to help them?

They can move the meeting around as they need be. If they're too busy, they can cancel it, right? But having those, sometimes we don't even have things to talk about. So we'll just talk about, hey, so what'd you do this weekend? And we, doesn't matter that it's not always work-related. It's about having those.

It's about getting to know one another. I might know their daughter's name, their son's name, their son just graduated. They've had a family milestone event. Those kinds of things really establish trust and it's kind of the foundation you have. then, know, obviously it goes across when you do that also in team meetings, it encourages your team members to basically do that.

So they just need to know. And as far as the support part of your question, the support part is pretty simple. You need my help with something. I tell you I'm going to do it. I do it. And then I follow up and make sure that I communicate with you that I've done it.

If I don't get it done in the timeframe we agreed upon, I follow up with you. I'm accountable to you. You know, I work for you. You don't work for me. I'm working for you to help you get your job done. So it's incumbent upon, I think a leader, a manager, whomever with a title that they understand that they work for their team. It's not the other way around.

And so I'm accountable to them to make sure I get stuff done so they can feel supported, you know, that's why I'm here, right? I'm here to help them. That's the only reason I'm here. I'm passionate about helping them. So a couple of thoughts there, at least on the first question.

Harshit Paul (Director of Product Marketing, LambdaTest) - So, excellent point, actually, especially the one where you talked about, you know, having those 1:1 meetings and not worrying about the status update, because that is literally something you can get from, you know, endless number of dashboards and whatnot.

Blake Hill (Senior Director of QA & Agile Delivery, AccentCare) - Exactly!

Harshit Paul (Director of Product Marketing, LambdaTest) - To get this, you know, and not a lot of people relate to that in the first point, right? Because people still go up and asking about, okay, what did you do this week or what did you do this month? Right? it's extremely important to understand that those one-on-ones have to be a safe environment where your team is able to open up and you have to be a listener at the end of the day. Right?

Blake Hill (Senior Director of QA & Agile Delivery, AccentCare) - You nailed it! So that's why if they own the meeting, I'm there. You nailed it. You absolutely nailed it. I am there to listen to them. If it was my meeting, I would probably be the one doing the talking, but if they own the meeting, they do the talking, and I do the listening. And that's, you nailed it. That's exactly why that's flipped. All right, at least on my team, I had it flipped. So I do the listening, absolutely. Nailed it.

Harshit Paul (Director of Product Marketing, LambdaTest) - Perfect. And let's talk about, you know, we've talked about environment and there's also purpose, right? A QA team has to have a purposeful purpose, right? So how do you go about, you know, creating that purpose and setting it into your team and how do you involve your team in defining these processes as the purpose of the process is kicking.

Blake Hill (Senior Director of QA & Agile Delivery, AccentCare) - Yeah, you have a purposeful process. So lots of P's there that we have, but purposeful process is, you know, a lot of times when you come into a team, they, might already be an established process that we have that people have followed.

It's been, you know, given down through the years through development organizations. And it's just the way we've always done things. There's no thinking about doing things differently. There's nothing like that. So I encourage my team to tell us where's the process need to be changed. What needs to be changed?

Taking their feedback and not just taking their feedback, but empowering them. In the introduction, you talked about Agile. Obviously, the goal of Agile is to have a self-managing team. Not all teams become self-managing overnight. It doesn't happen overnight. It takes a long time.

It takes a long time for teams to work together well. In fact, it takes about seven months to build trust. It takes half that time to lose trust. So, trust is not something that comes by easy. If you think about it, when you're building a team, you have these agreements, you agree on who has what role.

If I'm a basketball team, I can go get a bunch of great players on my team and sign all the best players, but that doesn't mean I have a good team. mean, look at the Lakers. They try to sign the best players every year. Have they won a championship lately? No, they haven't. So why is that?

It's because teams need time to form. You can get a bunch of great people on your team, but they have to work together for a while and understand how one another work and they have to agree as a team on what processes they're going to follow. And even before that, what values do they actually like?

We actually talk about that. Like that's part of the agile process. When you have a purposeful process, establishing what the team values are and how you guys are actually going to communicate with one another and how are we going to handle certain situations?

Like we talk about that upfront. That's the very first thing that has to happen. Cause if you don't have any kind of agreement like that, then what are you going to do when these situations happen? You it's usually kind of chaotic if you can hurt people's feelings blah blah blah.

So We had the team sit down and talk about like what are you gonna value? What are some things write them down? We'll write them down and communication was one of the major ones and how we're gonna communicate and Transparently and honestly and openly and all those kind of things but then we let them have a say in the process.

So for example, you know, we were on a one month release schedule up until recently and the team said, hey, you know what? We want to have an interim release every two weeks as well as our one month release. Because then here's what we think. And they were trying to sell it to me.

And I was like, you guys don't have to sell me on anything. If that's what you guys want to do, then that's what you guys should do. Let's make it happen. And they did. So when they have a part of being in the process and defining the values the team is going to have, when you have time and sweat equity invested into something, you now make it work.

If I told you, have to do it this way, this way, this way, you might do it that way, but at some point you might lose interest or whatever. But if you actually help design the process, you're going to be a lot more attentive to making sure you adhere to it. And I think the other thing is too, is then you also lose a little bit of that ability to complain about it, if you think about it.

Because if you're involved in the process, then people probably aren't going to complain because they helped architect it. We've done that at several times and we've modified our process in three and a half years that I've been with this team, probably three or four times we've modified the way we're going to do things and had some major overhauls to things, but it's what the team wanted.

And the team has been insanely successful because of that. And I think it's because they don't have somebody pushing top down. You have to do it my way. We need to do it your way. How do you guys want to do it? And not each team does it exactly the same because all the teams are not exactly alike.

Harshit Paul (Director of Product Marketing, LambdaTest) - Right. That's correct. So, during the span of three, three and a half years, do you also happen to scale your QA team? We did scale. We scaled up and we scaled back. mean, we were all originally like onshore and then the decision was made that I needed to have my team half offshore and half onshore.

So, while doing all these processes and everything and trying to hold a team together, we were also having to like incorporate an offshore component to where half of our team was now offshore. And now I would say my team is probably about 70% offshore.

And so, you know, there's some challenges that inherently come with that. But again, that's my, our onshore efforts are going to succeed or fail due to our company, not their company. It's up to us to set them up for success. And I think we've done a lot of things that are done very differently with offshore vendors that maybe not everybody does that has helped ensure that we've had a successful relationship.

So we've scaled the team up, we've scaled it down, we've swapped members here and there where need be. And then we've added roles that weren't originally there. So, it's in a constant state of change. And you're always trying to tweak things and make them better. But the relationship with our offshore vendor is massively important to our success, massively.

Harshit Paul (Director of Product Marketing, LambdaTest) - Got it. Got it. You know, we speak about scale and I think that's also something which is on top of a lot of QE leads, right? Because they want to scale their teams as well. So how do you go about highlighting these values of the QE team to your stakeholders, asking them to scale and what strategies do you demonstrate to show your team's impact?

Blake Hill (Senior Director of QA & Agile Delivery, AccentCare) - Right. So if I'm going to have to scale a team, the best way to do it when you're talking to people, you know, that are, that have big titles is talk about money. Right. Okay. You're either talking about cost savings or revenue, one of the two, usually with QA, it's a cost savings or something like that.

But I would do a cost benefit analysis and you know, that's the simple way to do it. You know, you show them the cost, but you show them what they're going to return. What are they going to gain maybe in velocity or what are they going to gain in quality?

And you show it like over a three year span. And whenever you can do that, You're showing them here's your cost in year one. Here's your return of value in years one, two and three for a total savings of X cost savings. That's how you have to talk to executives. You have to talk to them in that way because that's how they view the world.

And most of them have MBAs. Most of them have MBAs. Most of them are very good with accounting. So you kind of have to learn to speak their lingo. You can't just say, I need more people. mean, that's great. I mean, that's nice, but I need more people.

Here's how you do it. I need more people to scale my team and here's the benefit to you if you invest this money and here's your return over three years. So that's the best way to scale your team. I mean, that's by far the best way to do it. Do a cost benefit analysis.

Every time I presented a cost benefit analysis, I've gotten exactly what I've asked for because it shows that there was some level of rigor, some level of thought, some level of actual, you know, pen to paper, pencil to paper and math done to show them.

So I have to change my language and speak their language. I'm not a finance guy, but they are. So I have to adapt. So that's the first thing. And then what was the second part of the question? That was the first part was.

Harshit Paul (Director of Product Marketing, LambdaTest) - So how do you go about, you know, highlighting the impact of the team? So let's say stakeholders agreed, and you ended up scaling. Now, how do you go about showing the impact?

Blake Hill (Senior Director of QA & Agile Delivery, AccentCare) - Yeah. So you really have to have metrics have to have metrics. And so the best way to do that is to establish baseline metrics for whatever you, I can't paint a brush that works for everybody, but there are metrics in your organization that matter to people, but they might not even know what they are.

So it's up to us as QA leadership, what are those metrics? So I could share with you a couple that I came up with that were important to us. One of them was obviously escape defects. That's a big deal, right?

Everybody cares about it. And QA is never popular until something makes it into production that it shouldn't. Ask the people at CrowdStrike. They'll tell you the same thing. So that is number one. What are the escape defects? What is our percentage currently of escape defects?

And I went back and I looked historically over six months to find out what our escape defects was. And I established a baseline. This is our baseline percentage of escape defects. So that's one part of the equation. Escape defects. Another one was I started tracking escaped requirements or we call it scope creep, but we actually put a number on it and we actually started tracking that.

I don't know of many organizations that any that's that tracks scope creep because to us that's a defect. It's the same thing. It's a defect. It's something that was missed. It was just missed earlier than QA. So how can we track these metrics even sooner so that we can find out what they are?

So we track scope creep and we attribute it either to the business or we attribute it to us. And if it's on the business, we track that. I'll get to the key point here in a minute. So that's another thing we track. We also track ideal velocity. So what is ideal velocity?

Ideal velocity is this concept that came up with it. It's like, here is what we deliver as a team. Here's what we would have delivered as a team had we not had this number of defects in the system. This number of defects in the system caused us X amount of rework.

And then I convert that number based on a formula that I have in the background. And I'm able to basically show this many defects equated to roughly this many story points that we didn't deliver. We delivered, let's say, 50 story points. We could have delivered 62 had we not had this number of defects.

And this is an important metric that we use. The goal is to get the two lines to meet, right? It's probably never going to happen where there's no defects and ideal velocity is the same velocity. It could happen. It's happened once in the three and a half years I was here.

But typically those lines never meet. It's about getting the lines as close together as you can. And it's important to track that because that includes your development organization now. A lot of times metrics are just about QA. You need to have development, has to have some skin in the game on that.

So by showing that we have defects and then we attribute defects even before that to BAs, we attribute things to development, QA. So the goal with all these metrics, this is just a couple of the metrics that we have, know, mean time to defect. That's another thing that we try.

Like how long is it taking us to find these defects? but here's the key. All of that's great. And having baselines for all that's great. Now what do you do with it? You transparently communicate it across the entire organization. And now everybody is accountable and you want as many eyes on those metrics as you can get.

Because at the end of the day, when those metrics are all put out there, now the game is on. So now what are we doing to improve on those metrics? To raise this metric, to lower this metric. The last metric that I didn't include that I think is more important than any of those is we have the concept of running quality assurance as a service.

Everything is a service now, so why not make quality assurance as a service? And what I mean by that is we run a quality assurance organization as a customer service organization, take the quality out of it. We're a customer service organization, the product organization is our customer.

We ask them every release, tell us how happy are you with what we delivered? So we do an NPS score on our net promoter score on our deliverable every single month. We track those numbers and we immediately disseminate it throughout the organization.

So everybody can see that we're either kicking butt or we're getting our butt kicked. And if we're getting our butt kicked, we communicate it just as we do when we celebrate something that we do great. And an example on this team their original baseline of NPS score from our product organization was minus 37.

If you know anything about NPS, minus 100 is the lowest you can go, 100 is the highest you can go, minus 37 is not a good number. within four months of us doing this, we were in positive territory with our number, it went from minus 37. And within 12 months, we hit world class, which is 70. Since that point, there have been 31 consecutive months of our NPS being over 70.

Harshit Paul (Director of Product Marketing, LambdaTest) - Impressive.

Blake Hill (Senior Director of QA & Agile Delivery, AccentCare) - So we've never hit below 70, but that's because of the team agreed upon values, purposeful process, having, you know, passion for people, measuring what matters and having metrics that actually mean something. It's the combination of all those things that have made that team very successful and they've taken ownership and they're successful because we get out of their way.

They're successful because we let them do their jobs. They're supported. They feel supported. So I think those are some keys. That's a long answer, but that's a big question. I there's a lot to cover there.

Harshit Paul (Director of Product Marketing, LambdaTest) - Yeah, I'm pretty sure, especially there are also cases where you have a certain team onboarded, and there are maybe a couple or so resources who are not performing as much as you would expect them to. And maybe because of that, all the metrics that you talked about are actually being affected, right?

So how do you go about relaying feedback on such individual, do you just, you know, on individual basis, do you do that on a team call or what are your thoughts on that?

Blake Hill (Senior Director of QA & Agile Delivery, AccentCare) - So that's a great question. And this is where, you know, if you're in management, this is where you actually earn your money because it's easy to manage when things are great, but we really provide our value in the scenario you just brought up.

That's no one wants to have difficult conversations, but you you should, if you're a manager, not be shy about these things. there's two things I do. If it's a full-time employee, I'll have an honest conversation. And I've pulled people aside before and said, hey, is something going on? I'm asking because I know what I normally see and this is what I'm seeing.

Are you okay? Is there anything I can help you with? Is there something you feel comfortable talking to me about? If it's personal, you don't have to tell me, but just let me know if you're okay and how can I support you? More often than not, I'm right when I have that assumption because I care about my team, because I'm involved with them, I know them well.

And oftentimes they'll open up and talk to me and I'll say, okay, well, what can I do to help you get past this? What can I do to help you? You let me know in any way I can help. That usually will take care of the problem. Obviously there have been times where I've had to put people on performance reviews or whatever, or even have someone terminated, but that's a rare case.

It’s all about trying to fix it, not about trying to manage somebody out the door. Conversely, and I think this is super important because I told you most of my team is offshore. So here's what we do with the offshore team. Me and the team that run the management team of the offshore, we actually do a quarterly review and we rate our contractors who we consider team members.

We don't consider them contractors, but let's just say for the purpose of this, they're contractors. But we don't look at them as resources. We look at them as team members, no differently than my team onshore. And I don't treat them any differently than my onshore team.

But what we do is we review to make sure that, you know, what is their velocity? What is their technical skill set? And how is their communication? So we grade them on three things. And they get a number between one and 10. And I rate the team in the blind, meaning I don't share my scores with them. And I have the offshore team rate their own team.

Harshit Paul (Director of Product Marketing, LambdaTest) - Got it.

Blake Hill (Senior Director of QA & Agile Delivery, AccentCare) - And then we get together in a meeting every quarter and we compare the numbers. Interesting. we see someone that we agree upon, then we talk about how do we remediate that. And it's their job, because they know what our culture is here, to remediate that if they can and get it turned around.

And I think this is really important because I think a lot of companies take a lot of... We also interview our contractors. We don't just let them give us, hey, we've got a QA person. They start Monday. Why would you do that? I have a culture of people over here that I'm trying to you know, protect and I want to make sure that anyone I bring on, even if they're off shore, that they have those same cultures and values.

So we interview them so that we know we're getting good people. But we've had to do that, you know, and at a previous job I had, not the current job, but that was one of the first things we came in, and I flipped over like 40% of the team because there were a lot of people and by implementing what I just talked to you about, there were a lot of people that actually weren't producing.

And that was causing a lot of problems. Well, as soon as we replace those people and got the right people in, all the metrics that you're talking about corrected themselves almost instantaneously because we got the right people. And, you know, you can have that high trust with a vendor, right?

That they're going to always hire the right people. But man, if you've got that relationship with a vendor, you should absolutely be involved in the interview process and make sure that you're bringing people onto your team that are going to be a net addition to your team and not a net subtraction? So yeah, that's a great question.

Harshit Paul (Director of Product Marketing, LambdaTest) - And those are some great answers. And a lot of useful experiences put in together as well. And while you talked about a lot of good pointers there, how you can make sure that your team's morale is good and how people can open up. But there are employee burnout is real, right?

Especially all the way, it's all the more real to a quality analyst in picture, right? Because there's always so much to test at the table, so many things to chase, right? And how do you address, you know, challenges where there are conflicts in the team or say lack of motivation, where somebody's feeling burned out? And what methods do you have to build a cohesive environment after that, in case there are any conflicts?

Blake Hill (Senior Director of QA & Agile Delivery, AccentCare) - Yeah, so it's important that we make sure that what we talk about we actually implement. So if I care about work-life balance for my team, then it's incumbent upon me sometimes, I have to go fight on behalf of my team. And so, you know, as a manager, sometimes that makes people uncomfortable, right?

Sometimes you don't want to go fight a fight, but you know what, if you want to have the respect of your team, you better go fight a fight and they need to see you go fight a fight. They might not always see that you need to win, you know what I mean? But they want to know that their manager has got their back and we'll go fight the fight.

So, I think it's very important. know, I tell my team, sometimes I'll see my team say, I worked the weekend or something like that. I'm like, well, what were you working the weekend for? I had to get this. you don't need to do that. You know, I have to set them straight. You don't need to work the weekend. That is not an expectation.

If we needed to do something like that, I'll talk to you. But I think it's super important that we protect them from that. Another example, I think there's little things we can do. Hey, you know what? It's Friday. It's three o'clock. Go home early.

Hey, we're having an install tonight and that install usually lasts two or three hours sometimes. It can, let's say, because you want to do some testing around it or whatever. Let's say it's an install like that, because I know that's typical of most teams don't have microservices that they're releasing every minute into production.

So for a lot of teams, they have big installs. Sometimes we do. When we do, I could have my team work eight hours and then have them log back in and work another three hours, or I could tell my team, go home at two worked five hours, worked three hours here, and now you still worked eight.

So doing things like that, you know, hey, hey, I get this. Hey, I have a doctor's appointment today. You know, I'll submit a half a day vacation. You know what? You're good. You don't need to submit a half a day vacation. Save that half a day vacation for actual PTO time.

Nobody wants to burn PTO for having to go to a required doctor's appointment. So hold on to that. I'm not going to make you use it. Let's save that. And you use that time for vacation.

So I think there's things that we can do there, but I think obviously the biggest one that we can do is making sure that we stand up for our teams whenever we feel like they're getting more work on them and they need to feel empowered to actually say something and say, hey, this is more than we can take in the sprint.

A lot of times I'm on calls where teams are believing they can get X amount of work done. And I'm like, yeah, but can the QA team do that? So I'll speak up for them. Do you guys really feel, no, we don't feel like we can. Okay, what can the team deliver in completion as a team, you know, all the way through QA.

So, you know, you have to stand up for your team sometimes. And I think teams in general are always optimistic, always. So I try to stay overly so. So I am a pessimistic on the team, being a QA person, and I will come along and say, set yourself up for success.

But set yourself up for success where you can actually exceed. Don't make it up here to where you have to just barely get to success and you've just killed yourself to get to success. Make this your success marker. Then you have a chance to exceed it if you choose to, if you can, if it's doable.

But don't make the bar so high that every release is just killing you to try to, that's hugely important. So it's a culture, you can protect from burnout to an extent. It's easy to say, but there are things that we can do. I mean, we can choose to be victims or we can choose to actually be proactive and try to change the outcome.

And I prefer the latter because being a victim doesn't help anybody get anything done. So it's just important that you instill a culture that is promoting that type of atmosphere and where people can come to me, they can say they feel burned out, they can feel like they've got too much work.

So what can I do to get it off their plate? What can I do to I mean, that's what I'm there for, Is to try to help them out, or at least in my mind, that's what I'm there for. So, you know, that's what we try to implement. Is there a perfect solution to that all the time? Not always. Sometimes, there's going to be overtime. That's just how it goes. But that should not be the norm. That should be the exception, not the rule.

Harshit Paul (Director of Product Marketing, LambdaTest) - Got it. That makes sense. you know, speaking of expectations where you talked about setting the expectation bar not too high, we're always chasing it have there been any instances where you set the expectations thinking that something's gonna happen.

But the expectations were set, thinking that the team would be able to do a certain amount of tasks within a certain range of time, but it just didn't happen. And how did you address that after?

Blake Hill (Senior Director of QA & Agile Delivery, AccentCare) - So I think sometimes we see, we have multiple agile teams and some teams are further along in their journey than other teams, right? So some teams are self-managing, like they're completely self-managing. Like we just get out of the way.

Other teams, not so much because, you know, they work on some really complex things, but they've added a lot of new team members, etc. Sometimes management can be overly involved in that. And, you know, it's up to me if I'm doing my job, that we make sure that management is not involved in that the management isn't setting the expectations on what needs to be delivered in a sprint.

It's very important that the team feels like they are the ones that are going to choose what they commit to. That's the concept of Agile, right? They've got the skin in the game. We're just chickens. They're the pigs. We have to make sure that they feel comfortable with what it is they're delivering.

And oftentimes, I will question them, are you sure? Sometimes they'll be like on the seesaw, like I think we can deliver all that. I'm like, okay, where does I think become I know? If you think removing this story gives you some level increased of like 90% assurance, let's remove that story, put it on the backlog.

If at some point during the sprint, you're able to bring it in and complete it, fantastic. If everybody agrees. If not, don't try to kill yourself to deliver that. It doesn't mean that we don't want to challenge them to go faster. We just don't want to challenge them.

We don't want anyone having to steal victory from the jaws of defeat. You know what I mean? We want it the other way around. We want to set teams up to be victorious. And when they feel like they've accomplished what they've committed to, or they get the opportunity to deliver more, I recently just had a team that delivered more.

They went to the backlog, they got more, they delivered more than they committed to. They were very proud of themselves on that. Because people want to do a good job. And so they were really proud that they exceeded what they said they would deliver. And you know, these are because these people are professional. They want to do a great job.

So we've got to set them up to be able to do a great job instead of, hey, I'm management. You think you're agile. I'm telling you, here's what you're going to deliver. you didn't deliver it. You didn't deliver even. We're to have to move everything into the next sprint.

That's not a recipe for success. I'm sure you've seen that happen. And everybody's failed that way. You learn by failing. So that's not how you do it. You got to let teams help be they'll tell you what their velocity is. And then again, when you're recording velocity, you have past velocity to use as your determinant for what our velocity should be going forward.

And so when you start to deviate too much from that, you can see if you run it by the numbers, you know, whenever we have a bad release, it's because we usually have bad scope creep and bad scope creep leads to missed defects and missed defects lead to right escape defects. So they're all kind of tied together.

So we want to the team to have, we always try to leave enough time. You ever heard the adage, know, we need to get 100% allocation. yeah. And if you think about that, when is that ever a good idea? I mean, if you think about it, if you get on the freeway to go home at night and the freeway is 100% allocated, are you going anywhere?

No, you're not. No. It's the same concept when we have this mythical, we need people to be 100% allocated. When people are 100% allocated, they usually don't get work done.

If people are like 85% allocated, they've got some wiggle room and you have some little room built into your deliverables to where you could take the unknown or the gotcha or the we missed this, we didn't account for that. You leave a little bit of room to help set them up for success.

Harshit Paul (Director of Product Marketing, LambdaTest) - I think that's extremely important to note, especially when you're thinking about employee bandwidth, right? So giving that sort of free room that can actually come in handy, especially for any adhoc.

Blake Hill (Senior Director of QA & Agile Delivery, AccentCare) - Absolutely. There'll be some adhoc, product will forget something occasionally or we might miss something and say, you know, what we didn't think about that if we made this change here, it's gonna affect this over here. So sometimes we'll miss the thing.

And so, you know, it's good to prepare for that. It's that another old saying like come loaded for bear. And if you get a bear, you can take the bear. But if you come loaded for rabbit and you get a bear, you're in trouble.

Harshit Paul (Director of Product Marketing, LambdaTest) - That's a nice way to put about it. Yeah. So let's also talk about, you know, handling conflicts, right? They happen whether you want it or not in a big team, especially if there could be some conflicts happening between one or two resources or maybe more. So what's your go-to resolution? How do you go about fixing that?

Blake Hill (Senior Director of QA & Agile Delivery, AccentCare) - So I usually always have those conversations like offline, right 1:1. It’s 9 times out of 10 is a communication problem. So I spent a lot of time and I had mentioned this a little bit earlier. I think the number one thing, and this isn't any business. I don't care if it's QA, if you work at McDonald's, if you work at Pep Boys, it doesn't matter.

The number one skillset an employee, a QA person, a dev person, a manager can have is communication skills. And we spend a lot of time talking about your tone, how you talk. You know, only 7% of the words you say when you communicate is how your communication is received. The other 7% is words, I think it's like 38% is your visual cues and your expressiveness, your facial expressions, everything.

The other 55% or so is your tone. It's how you say it. And I think a lot of times what happens in teams when there's conflict, you have people that get excited because they're passionate about it and communications get a little haywire, tone gets sideways, people talk, people get offended and everything.

So really what I try to do with that is it's almost always addressed. It's usually not a personal attack by anybody. It's people get excited. People are fighting for one thing they believe in. And if you think about it, two people can't argue when one person relents on wanting to be right.

So, you know, we have to ask ourselves, is this really worth fighting for? You look over your shoulder and ask yourself is what I'm fighting for right now worth fighting for. But we usually address that and one off conversation and almost always deals with communication.

I'm a huge proponent of having communication be something that everybody on my team goes to. We go through the same communication class and training so that we all have like a common lingo and understanding and, you know, basic foundation. mean, that communication is taken for granted.

I think a lot of times, you know, teams usually aren't taught that. Right? When we go to school to be in QA or to be a developer, are you taught communication? No, you're not. working on a team, within a team construct, working in IT, and that's hugely important.

And that's not just communications from, sometimes those same conflicts can happen in written conversations. It can happen on a user story. It can happen in any kind of of means, but I really think that's the best way to deal with conflict is I can't control another person on another team.

So I talk to my team and I will say, here's how we could deal with that in the future. Or here's some ideas in the future on how you could deal with it. And if it's bad enough, obviously I would have to go to the other person's manager and just say, look, we've got an issue here. It just needs to be talked to.

We both need to be, you know, we need to be talking the same thing to the, the same people and make sure that, you know, we don't have that we don't have that conflict, but I just can't underscore the value of strong, transparent, we're back to that word, which seems to be the key for every foundational thing we've talked about, transparent communication.

And then I always encourage my team, if they ever get sideways with a team member, is to work it out and go back to them afterwards and say, hey, you know what? I could have maybe handled that better if they were, whatever, and just be honest and be authentic.

And if you are, no one's ever gonna, you know, talk down to someone or take offense to someone if someone comes to them and say, hey, you know what, I could have done a little bit better with that. I'll do better in the future. I'm sorry, I got a little heated or I got overly passionate. You know what I mean?

So if you do that, I really think that takes care of lot of the problems. It's just a lot of times people don't want to talk about those things because they're uncomfortable, right? You got to be able to handle uncomfortable conversations. So yeah.

Harshit Paul (Director of Product Marketing, LambdaTest) - And I think like really it's all about, you know, having those one-to-ones in case of conflicts because you don't want to go about correcting someone over a public forum. That's just about adding fuel to the fire.

So extremely important to go to the right person and have that conversation one-to-one, understand and look at things from their perspective. Really useful point, right? This was one of the common challenges I think pretty much every leadership faces, but what are some other challenges that you have faced as a, know, biggest challenges that you've faced as a leader and what did you do to overcome them?

Blake Hill (Senior Director of QA & Agile Delivery, AccentCare) - I think what most people in our position in QA would say, if you're in any kind of leadership position, is constantly the pressure to do more with less or to do things faster. Oftentimes QA is looked at as, hey, what can you do faster? It's like, you have this much time and we plan out how long each thing is going to take, right? Well, what happens?

This planned time became this and then this plan time became this. And QA's time doesn't move because QA has the external deliverables. So now QA's time was this and now it's this. So it's like, that's a common issue. That's again, that's a management problem and that can be dealt with and it needs to be talked about.

And there are things that we can do there. That's a challenge that we constantly have. Obviously doing more with less, doing things faster is always, so obviously there's automation that obviously can help, but obviously upfront automation doesn't save you any time. It actually costs you time and it costs you money.

So what's the cost benefit analysis? If we do this, how's it going to pay for itself over the next three years? What does that look like? I think that's a really big issue. think obviously I hate saying shift left, but it's something that everybody understands.

So I say it even though I don't like it, but it is, it's like, what kind of testing can we do even before it gets to testing? What kind of validation, you know what I mean? Can we do to make sure that we have the right requirements and involving that feedback loop early with product?

I think those are the kind of things that we've done that have helped to try to address some of those issues. I think really in an agile environment, having an active product organization and it's up to us to get product involved.

Because a lot of times product wants to just throw things over the wall. That's how they're used to doing work. And I don't mean that negatively towards all product organizations, but a lot of times they're not used to being enveloped and actually being a part of the deliverable as a QA team like they should.

So it's incumbent upon us to get them in that scrum, huddle up with us, be a part of the team, see what we're doing. I think that helps, again, that's about communication. The more involved they are with us, the less chances there are of having miscommunications, bad requirements, misdeliverables, misunderstandings, wasted time.

If they're a part of our daily scrums, if they're a part of our retros, if they're a part of, you know, we include them on our sprint goal. You we actually do all these things. We include them and ask for them for sign off on you know, on our requirements. Those kinds of things help reduce those things, help make us faster.

Because usually, again, defects almost always come down to a miscommunication of some sort. misunderstanding of what would need to be delivered, how it needed to be done, that type of thing. So I don't know, that's just one thought there, but.

Harshit Paul (Director of Product Marketing, LambdaTest) - Yeah, sure. Pretty much everybody who's listening would agree to that part. And we've talked about a lot of questions and you answered them extremely well and in detail manner. Just one last question before we wrap up the session is pretty much what everybody wonders, which is the future, right?

With so much happening around QA and AI and whatnot, how do you see the future of QA, right? Especially with all these AI-based emerging technologies and automation, what skills do you think future QA leaders should be having with them?

Blake Hill (Senior Director of QA & Agile Delivery, AccentCare) - Well, obviously, I think AI is where it's at. I think that's going to be where everything goes at some point. I think right now it's cost prohibitive for a lot of organizations to actually implement. It sounds great. Everybody's doing it. It's the buzzword.

It was RPA a couple of years ago, and now it's AI. RPA will probably go away in the future because AI will replace it at some point where there's no code. You don't have to write any code at all. I like that AI can read your code and can develop test cases for you. I think that's great. What it can't do is it can't test integrations to your other systems and stuff like that. that's still, it's not a cure-all. It's not a silver bullet.

And even then a lot of the exploratory testing that we do is still hugely valuable, I think. So I do think AI can be, I think we can partner with AI. I think it's still cost prohibitive though. A lot of those AI solutions, I have talked to several vendors, they're not cheap.

And typically, most organizations are not wanting to invest vast amounts of money into their quality process, unfortunately, because most of us, people in accounting, most executives view QA as a cost center. And they could look at it as a savings center, but they look at it as a cost center and they just look at it as money going, money going, and they don't care about quality until they care about quality, right?

Until they don't have quality and then everyone. You're the most important person in the building. So I think that we can try to find some easy ways to adapt. We could use it to help us write test cases, but we should absolutely review. Not everything AI produces is perfect. So and absolutely right all the time. So I think you can use it.

I think that's where we're headed. I mean, at some point, AI can do a lot of that testing for you, not just write test cases, can execute the test cases and the code, but where I think that exploratory testing, obviously integration testing with other systems, it doesn't know that. It doesn't know how to integrate.

Will it at some point? I guess it could, if you want to open up your code base. then you get your security team involved and they're like, wait a second, where's all this? When it's reading this, where is it making these calculations? Where's the data being stored in the cloud?

So, there's a lot of compliance on it's kicking in, yeah. Yeah, absolutely. you've got PHI data or you have HIPAA compliant data or you've got bank data, you can't, so there's some thing, you could have it behind your own firewall and all that kind of stuff, right? But I don't know, I definitely think that's where it's headed.

I think it's where it's headed. I'm not saying that there's not a future for QA, but I think when we say QA, there's two QAs, right? There's QA testing, and then there's quality assurance process. So process is something that's always gonna be needed to having optimized processes and stuff like that.

So I don't know. It's a great question. I've thought about that for our team as well. I don't have a lot of money right now to invest in AI, but it's something, it's going to be here. And as more companies come out with solutions, it will create its own downturn in cost. It will happen at some point because the market will have a lot of options and we'll be able to pick them and be able to probably utilize them.

It's the same thing when automation first came out back in the day. It was expensive. Now you've got freeware where you can just use Selenium if you wanted to. So, yeah, think AI is definitely, I mean, it's not like anybody doesn't know that.

Harshit Paul (Director of Product Marketing, LambdaTest) - Actually, automation has matured over time. AI would probably do the same. And back when automation was there, this question came out from a lead perspective as to how should they prepare themselves, right?

But how should the young ones, know, freshers or somebody who's entering the industry now? They often wonder if AI is going to hunt the jobs for them. We've heard that for automation. We've heard that multiple times in the past as well. What are your takes on that?

Blake Hill (Senior Director of QA & Agile Delivery, AccentCare) - I don't think it'll end anybody's job. I don't I honestly don't think at a workplace that could it reduce some workforces? It could. And it's likely that it could. So I think that would be one of the, you know, if you're looking at from an executive perspective, that if you were to implement and spend a full scale AI solution for your QA team, that would probably be part of their expectation or they probably wouldn't invest in it.

It's just a real talk. I mean, let's be real, that's probably it. So there would probably be some reduction, but I don't think it will ever ultimately get rid of, you know, it's hard for AI to know what users will do to a system. Right. And so that whole concept of negative testing as well, there is some negative testing like boundary testing, and there's all kinds of things like that that you can do.

But there are some negative tests that AI would never come up with that people use the system to do. Maybe different workflows they take or that they came up with that is not the proper workflow, or you just do things completely not the way the system was designed those are harder for AI to come up with.

So I think negative testing is a huge thing that, and again, not just the classical testing, you know what I mean? I can enter text into a numeric, AI can figure that out, but I think there are certain negative scenarios too that you can come up with.

Harshit Paul (Director of Product Marketing, LambdaTest) - I think that's- it's all about finding those critical edge cases where- Yeah, As of now, least human intelligence is imperative.

Blake Hill (Senior Director of QA & Agile Delivery, AccentCare) - I think so. think that's a really big thing. you and I think so, a QA person could like, you know, really make themselves valuable, you know, know your system inside and out, but like more than anything, but then you can come up with those edge scenarios that other people would never dream of.

And you can really find some really good flaws in there. You know, I mean, I think that number one interview question I like asking people to address that is like, if someone answers the question, you know, why did you choose to be in QA? And a lot of times people say, I was a developer. And then I found out I didn't really like it.

And a lot of, I hear that a lot. was a developer and I did a lot that. And everything. I get some answers occasionally. And these people I hire, I will almost literally stop down the interview and just be done when they say, I love to break things. That's like, well, that's exactly why you're in QA.

Harshit Paul (Director of Product Marketing, LambdaTest) - That's the mission statement, yes.

Blake Hill (Senior Director of QA & Agile Delivery, AccentCare) - That's the mission statement. You love to break things. And when someone tells me that and their face lights up, it's like, I want to work with you right then and there. And I've had some testers that I've worked with in my day that were just ridiculous with the negative scenarios they could come up with and the way they could break a system was amazing. I don't know if AI can ever replace that.

Harshit Paul (Director of Product Marketing, LambdaTest) - Yeah, I absolutely 110% agree to that. And with that, thank you so much, Blake, for giving answers to everything in that great detail with all the experience you've had on board. And I'm pretty sure everybody loved this episode and thank you so much for making the time out of your busy schedule.

This was extremely insightful. And for folks who are listening to this episode, in case you just joined us midway, you will find the full recording of this session over our YouTube channel. You can also find the full podcast over Spotify, Apple Music.

So by all means, Subscribe to LambdaTestXP series in case you already haven't. And feel free to sync with Blake on LinkedIn as well in case you have any further questions which you want. We weren't able to take while this was on. Thank you so much, Blake. Bye!