What Should The Relationship With QA Look Like?

About this Episode

Today, we have a conversation about what the relationship should be between QA, testing engineers, and development engineers.

Transcript:

MIKE: Once again, we have another session of our podcast that doesn't have a name yet, but we'll choose one soon. [laughs] Today, we're going to have a conversation about what the relationship should be between QA, between the testing engineers, and between the development engineers. I think this is a really interesting topic.

And we've got a great group here today. We've got people from the QA side and from the development side, and some people who've been on both. So I think that we can have a really good discussion here and hear about the different perspectives and how people see it. I've got some strong feelings on this one. I'm looking forward to the conversation.

I am Mike Challis. I am a software developer here at Acima. I've been a software developer for a long time, a couple of decades. And I'll be hosting today. We'll go around and introduce the group here so that you know who you're listening to. Guillermo, do you want to introduce yourself?

GUILLERMO: I'm Guillermo. I've been in QA since August of last year, just about eight months. And I didn't have any experience in QA coming into this position, but in this past time, I've gained a lot of knowledge. Before that, I worked with collections in Acima. So I had knowledge with LMS and merchant portal. That's the extent of my knowledge. And now I've gathered a lot of knowledge.

MIKE: Great. And I like that you mentioned the knowledge. I think that'll help lead into some of our discussions later. Well, thank you. Jared, do you want to introduce yourself?

JARED: Yeah. So my name is Jared. I've been with Acima for about ten months now. I'm leading the QA team. And the QA team is, you know, a lot of the team members are working into a development role. And it's been very interesting for me because I've got about four years of QA experience. And I love seeing the growth and learning all the technical aspects here at Acima. So I'm happy to be here.

MIKE: Great. Eddy.

EDDY: Hey, team. As Mike mentioned, I'm Eddy. I've been in QA going on ten months now. The team is great, and I couldn't ask for a better position. So you guys are awesome, and girls.

MIKE: David.

DAVID: Hey, I'm David. I've been a software developer here in Acima for like one year now. And I have been a software developer for more than ten years. I have also been in the QA role years ago for...it's like one month or something like that. And I have helped here also. So it's a great topic, and I'm glad to be here.

MIKE: Great. Thank you. Diane.

DIANE: Hi, my name is Diane. I've been at Acima for two years and have been QA for a year. The first year I was in processing, so I have a lot of experience with merchant portal. And I came on to QA with no experience, and so I've been able to learn a lot and grow a lot in this position.

MIKE: Oh, that's great. Ramses.

RAMSES: Hey, everyone. My name is Ramses. I've been with Acima for three, three, and a half years-ish, almost four years. I've been a developer for just a couple of, I guess, about two months now, I think, full time. I was in a technical support role for a little over a year, and during that time, I did a little bit of QA, but it was just kind of on and off.

MIKE: Great. And you might offer some interesting perspective as well, coming from support, not exactly QA but a similar role. Zsolt, do you want to introduce yourself?

ZSOLT: Yes. Hello. I'm Zsolt, and I'm the newest member of the QA team. I've been on the team for about three weeks now. I've really enjoyed working with the team so far.

MIKE: Great, yeah. We love having you on the team. Afton.

AFTON: I'm Afton Call, and I have been in a few of these episodes, so I might be somewhat familiar. I have been a software developer for just shy of four years here at Acima, and that is my entire career. [laughs]

MIKE: Great. Melissa.

MELISSA: Hi, I'm Melissa. I've been at Acima for six years now. I also started on the operation side of things and then moved into QA with little experience. I had been pursuing my computer science degree for maybe a year at that point and had also done the mentorship that Afton led. And now, I'm a software developer, and I've been doing that for the last ten months now. Happy to be here.

MIKE: Great. Josh.

JOSH: I'm Josh, and I've been at Acima for a little over seven months now, I think. But I came to Acima with about ten years of experience in QA in different roles, mostly in Utah. I'm originally from Washington State. So I still think of that as home even though I've lived here for quite some time now. So that's me.

So I'm right now working with the QA team, and we have a really good team. I'm extraordinarily lucky because I've worked on some that don't communicate as well, work together as well. So yeah, for lots of reasons, it's a really good team.

MIKE: Great. And you probably have some interesting perspective there of seeing things not work so well.

JOSH: I obviously don't focus on those. But yeah, obviously, there's group dynamics and all that. It's very interesting to me.

MIKE: Thank you. James, do you want to introduce yourself?

JAMES: Hey, yeah. I’m James Murphy. I'm on the QA team. I have been with Acima for a little under three years now. Started off in sales, went into account management, did that for about two years. And then, I've been with the QA team for about eight months. Always been interested in technology, development, things like that, and QA was a great opportunity for me to really dive into it headfirst. And it's been a little like drinking out of a firehose, but it's been awesome. I love it so far. Great team. Really have enjoyed my time here with the engineering side of things.

MIKE: Thank you. And finally, Brian, want to introduce yourself?

BRIAN: I've been with the company for three and a half years, I think. I started in QA when it was a two-person department and was there for about two years. And I've been in development about a year and a half.

MIKE: Great. Well, let's start our discussion. We've got a diverse group here, and people from QA, and people in engineering, the development side of engineering, and people who've bridged the divide between the two. So I think we will have a great discussion. I wanted to start by talking about an interesting experience I had quite some years ago.

I had a bus driver when I would ride to work who was an adjunct professor at a local university. We can have another discussion here about how adjunct professors are underpaid, and they have to drive a bus to make their living [laughs] on the side. But we had some fantastic conversations. Previously being a university professor, he had been a QA engineer at a company. And we had some interesting conversations about what a QA engineer should be. And we'd sit on the bus together and chat. Sometimes it was just the two of us, so we had some great conversations.

And one thing that he talked about is that companies he had worked for the QA team and the developers were very adversarial. They hated each other. The developers would think that their code was perfect and hand things off to the QA team. And the QA team thought that everything that the developers wrote was trash. They would always send it back and tell them about all the problems with it.

And in the end, a lot of times, the developers would just end up ignoring the QA team, or the QA team would try to send ultimatums to say, "We're not going to let this go out." And it was a really toxic environment that he talked to me about. Where I was at the time didn't even have a QA team.

But sometime later, I worked at a place where we hired some people into QA from out in support and found this familiar story. And one of the developers who became a QA engineer really applied himself, became really good, and ended up asking to become a manager when we had a bad experience with the existing manager, and he had just disappeared one day. And I supported, and he ended up being one of the best managers I've ever had.

Went on to become a software architect and is currently playing a prominent role at another software company. He took that journey from being out in support to being the lead engineer at multiple companies. And seeing that transition, seeing how great it was working with him, gave me a lot of perspective as to what QA could be versus what my bus driver had experienced, which is really awful.

That opportunity that QA had to work closely with developers ended up not only building better software, I think, but also giving the QA team an opportunity to really bridge that divide between QA and development and sometimes crossover. And I thought that was a great transition for this developer. I'm not going to mention his name since he's not here [laughs]. I don't want to name him without him present.

But seeing that success, as well as a number of successes here at Acima, in particular, of people who have come over from QA and had a great time in development, I had some strong thoughts about how important it is for the developers and the QA team to work together as peers, as a combined team that is collaborating with different strengths that compare their different strengths in order to produce great software.

With that introduction, I'd like to have an open-ended discussion here. Hopefully, there are some seeds there for us to keep talking. What do you all think the relationship between QA and developers should be? And you certainly have some context here. And some of you have some context with other companies as well. So I will quit talking and let others speak.

JARED: I really wanted to jump in and say this. Having been in a couple of other companies and now coming into Acima, I think it's incredibly impressive the way that the developers put into unit testing. Every single PR I get has a unit test, and that means the developers are more test-minded. And so I think it's really easy for the QA team here to get along with the developers because everybody has testing in mind.

And I've seen places where testing is like the last of people's worries, and then some things get pushed out, production breaks, things happen, and it just doesn't work very well. So I have to say that about Acima. Everybody is test-minded, so it makes the environment really easy.

JOSH: I want to add to what Jared just said. When developers and QA are both test-minded, nobody is the official...or no one is seen company-wide or even department-wide as the gatekeeper for the release of any product, or feature, or code. When it's viewed the other way, I don't want to say toxic, but maybe it's not as balanced. If developers aren't as involved in testing, then it's all on QA. And as a result, if there's something ever wrong, it's easy for that message to spread through the department that QA doesn't want to release something, so it's like we're the bad guys.

We get all the blame but none of the credit because if it goes out live, developers are like, yay. [laughs] So I like the mix we have here at Acima, and that's when it's like, we're integrated. And we don't necessarily have individual teams within the department, but we all work together all the time on every PR. So we all have equal stake, and I really like that.

MIKE: That's an interesting point you both raised about developers being interested in testing as well. What happens when developers aren't interested in testing? Can QA save that situation?

JOSH: I think short term maybe like from a PR to PR basis, but long term it sees more consequences.

DAVID: I think that's out of mindset or also experience because I've been working for places where developers hate QA. Those developers are...because they don't like to test. They just code, and they just test the happy path. And they just send everything to QA. And then the QA guy starts testing, and they see, oh, there's a bug here, and boom, it rejects the code and rejects the ticket. And then the developer is, no, but it's fine. And they...no. Did you sit with the QA? And they say, "Oh no, it's right."

And they start hating the developers just because they were unable to test their codes like they were just in the happy path, and they were unable to see beyond that. So I've been in that place. But I think that's also a matter of experience. Because for example, in my place, I love when QA finds a bug because I know that code is not going live. He just saved me from a real problem. So yeah, [inaudible 12:24]

MIKE: There's a text post here: it works on my machine. [laughs] I think you hit on something critical there, David. Sometimes I think that we misunderstand our job as developers. We think that our job is to write code, and I would argue strongly that that's not our job. Our job is to solve business problems. And if we misunderstand what our job is, then...I wrote all this code. This code is wonderful. Why aren't you thinking that my code is wonderful? [laughs] We start taking it personal.

And there are some issues there around psychological safety as well that I think are important to recognize that you need to be able to have feedback without it being a personal attack. But this idea that the code is our output is, I think, really problematic. What we're trying to do is solve the problem. And if we're all trying to solve the problem, then code is part of the solution, but it's a collaborative effort to solve the problem.

And as you said, David, if somebody finds a bug, and I feel the same way, like, oh, thank you for saving me because we're working together to solve the problem, not working adversarially to push out code that then somebody's going to criticize. And we just have better outcomes. It means that we're all working for the same goal rather than for different goals. Neither of which goals really is one person's goal is to block the code, and the other person's goal is to get out code. Neither of those are really solving the real problem, which is the business is trying to help people out with their software, provide a feature for customers.

AFTON: This surprises me to hear how many experiences people have had where developers are just kind of, here's the happy path, here you go and then sending it off. And maybe this surprises me because I've grown here at Acima [chuckles], where testing is a big part of our process and our mindset. But when I write code, I want it to be foolproof. I want you to be able to throw anything at it and know it's going to work. Like, this can handle whatever you throw at it. That's a big part of what makes me feel so satisfied to produce it.

It just surprises me that there seems to be so much where the happy path is all they're thinking about because all the different angles is like, yeah, I feel like I'm here to solve the problem, not to present just a happy path. That's interesting to me.

GUILLERMO: Kind of what Afton said is I think I'm fortunate enough to start QA in Acima versus another company and getting that bad taste of QA somewhere else. I do agree I can reach out to any of the devs tickets that I'm working on and say, "Hey, I'm finding this." And they respond rather quickly, and they'll work on the machine. And we get to the root of the problem and take it out.

JOSH: I think a lot of it in my experience...I've worked at several companies in the last decade here, and it's in QA. So they've all had unique arrangements, both in departments and how teams are set up together. And what you're describing, what Guillermo just touched on from my experience, seems to happen in teams that are divided where there's the QA...oh, you're on the QA team, okay, I'm on the dev team.

Those kinds of teams, you end up finding developers who you work well with and then just avoid the rest of them. And they probably do the same for QA people as well, someone who can test their stuff and get it released as quick as possible, who isn't going to be a pain to work with and find bugs, or however a lot of that is viewed.

That stuff dies away when you integrate, at least in my experience, when you work like the teams are divided like 60% developers, 40% QA, or 70-30. When you're on the same team, you're in the same meetings. You're planning together. You're grooming stories together. You're understanding what the work is. That animosity, for the most part, dies off. So in a way, the way it's set up here at Acima kind of plays to that same...falls in that same category. Like you said, Mike, we're all trying to produce quality software that solves business problems. We're not trying to get done the fastest. We're trying to get it right.

EDDY: To chime in a little bit here, I feel like there's a stigma in the industry that I've read on, and I've heard from other people's experiences how the relationship between QA and developers can be rocky at times, whether that's communication or not. I can talk from personal experience working at Acima that that's never been the case.

I feel like it's crucial where the communication and the confidence, you know, to be able to provide feedback, whether it's good or bad, whether it's from QA to developers or vice versa, is really important. And I think that speaks for the foundation and the team dynamic that Acima has grown and groomed that all of us...and I guess I can speak for all of us where the communication is great between both parties.

JARED: If I could actually interject on that as well, the communication aspect I think is so important because if you think about developer to QA, oftentimes, there is a huge discrepancy in technical understanding. So the devs do what the devs do, and the QA does what the QA does. And oftentimes, devs will hand QA a ticket, and QA will not know what it's supposed to do, not understand what's going on.

And so I think if you look at it from...the communication needs to be polite in a way where the devs can't go and say, "You're stupid. I wrote this code. I know how it works. This is how it's supposed to work." And then the QA, if they find an issue, they shouldn't go to the dev and say, "You're stupid. This doesn't work. This is not how it's supposed to work."

I think wording is very important where the QA shouldn't come and attack. But they should ask, like, "Hey, I'm seeing this. Is this how it's supposed to function? How am I getting this result?" And the dev can then also walk him through how it's supposed to work. I've seen a little bit of that in my experience. I think that's what creates the animosity, the toxicity, and the divide between the two. But the way that you word your questions, I think, is very important.

JAMES: This just reminds me of a situation I got myself into. I was fairly new to the QA role. And I was doing a PR where, Melissa, I think you and Brian had collaborated on it. I did something. I did like a database rollback instead of...I don't remember exactly what I did. But I completely threw everything sideways by accident. [laughs] And so I went to Melissa and Brian, and I was like, "Hey, can you help me understand what I did?" And they were super nice about it.

And they kind of just explained the intended testing was this, but this brings up an interesting point of maybe we should set precautions against this. And I felt like an idiot because I completely messed up the testing and kind of threw a wrench in things. But Brian and Melissa were like, "No, no, like, it's an interesting way of looking at it," and kind of took that perspective. And it almost just gave me the confidence of like, oh, cool, I can talk to these developers.

And if they had come to me and been like, "Hey, stupid head, that's not what we said to do," but they were so cool about it and just friendly. And they walked me through the processes, and the differences, and the different styles of testing and stuff like that. And it just kind of created this very friendly environment, even though I had stepped in it. That is something that stood out to me where it's just like, really, it was a great experience for me where it could have just been awkward or embarrassing for me. So just going along those lines.

BRIAN: Yeah. Having a new user who's totally brand new to the whole thing is such a good perspective to get as a developer because we get so nose to the grindstone, so to speak. We're too close to the metal; you know what I mean? And so that's why when you run it...I don't even remember the property there.

But I love finding those weird things, and it's because someone who's brand new to our tech stack and brand new to the problem we're solving, it's like, they actually have a really good point of view because they're going to do what the most intuitive to them is. And that's why I was like, so interesting for you to find a problem that we're like, yeah, everyone is just so used to migrations working this way. Put it in front of someone brand new, and you're like, oh, well, what did their intuition say about it?

JAMES: Wasn't it like I was supposed to try to do a seed migration then a seed rollback, and I ended up doing a database rollback or something like that? But again, yeah, [laughs] I did --

BRIAN: I don't remember at all. [laughs]

JAMES: I just remember you guys were super cool about it, and you helped me understand what the difference was in that instance. And it helped me grow as a QA rep. And it was a good experience for me just learning.

MELISSA: Yeah. And I think that brings up a good point of investing in your QA. Because if we take the time to actually explain things and help you understand different processes, then that's only going to benefit us in the long run because then you can think of different scenarios to test or how to manipulate data in a certain way. So I think it's really important to take the time to explain things to QA.

JAMES: I can vouch for that. That's something that's helped me out a ton, just taking 15 minutes and saying, "Well, actually, this is why this is doing this, and this means that." And I've always really appreciated that.

BRIAN: Cool. And that's one of the benefits of our pipeline from QA to dev is me and Melissa; I mean, that was like just a year or two ago for the two of us. We kind of understand QA's point of view. We definitely understand being new to the Acima tech stack. And I think that's one benefit of...not saying that people who don't do QA are bad developers, but I think that is one good benefit of being a QA first and then being a developer is your perspective. You kind of have a little bit more empathy, I feel. And you kind of view QA as the goalies for your team. You would never get on the field without your goalie.

EDDY: Mike, I think if I can interject here, you've had skills clinic before where all we did is talk about the fear of sounding stupid, for lack of a better term. And I think a lot of us, when we first get started, you know, get in our heads about like, man; I don't want to sound dumb when I message this developer. Or they must be really busy; I don't want to take time away from them, from work asking something that's really simple to fix.

But the environment, again, that Acima has groomed, speaking for me at least, is that that's never the case. Every time I've messaged someone about a concern that I've had that has been met with generosity. It's been nothing but great experiences.

MIKE: I'm really happy to hear that. [laughs] That's immensely gratifying, I'll say that. That is exactly what I'd want to cultivate. The technical word that I would use for that...well, it's two words, psychological safety, the technical term, and there's a good body of research. Well, first of all, I just thought on a personal level, I think it's important to treat people nice. That's backed up by research, and you can look this up.

Google did some research some years back as to what made their teams most effective. There were a few contributing factors, but by far, the most important factor they found was that psychological safety, when people feel free to express themselves, to be themselves, to ask questions, to ask uncomfortable questions, then the team is much more successful.

Because all of us, you know, you talked about doing something that made you feel dumb as a QA developer. Well, developers do that, too. We do things that we look back on and think, oh, why did I do that? All the time, because we're human. We make mistakes. Closely connected to creativity, you know, we do stuff that is unusual. And a lot of times, it doesn't work, but sometimes, it's brilliant. And we have to be able to be there for each other in order for those brilliant things to come through.

I also love what Melissa said. She said, "It's an investment." It might take 15 minutes to explain something to the developer that's testing your code, to that engineer who's testing your code, and that is a cost; that's time. But if you pay that, it will be paid back with interest. Making that investment in those relationships and in helping people develop those skills will grow your opportunities in the future. And my experience is that time is almost always worth it.

I mean, there are times when something's on fire, [laughs] and you might have to defer the conversation. But that doesn't mean the conversation shouldn't happen. Once the fire is out, well, okay, the fire is out. Let's go talk. It is worth asking those questions to develop that. It looks like, Diane, you had something to say about that, about asking questions.

DIANE: I get nervous to ask questions all the time. But one thing I do go by is that if I don't ask this question, even though I may feel like it's dumb, I'm not going to get the answer. I'm not going to know how to do these certain tests. So it's really important to, even if you feel like it's dumb to ask the question.

JAMES: And just to kind of piggyback on that as well, I've found personally, if you have a question, chances are there's at least one or two or a lot of other people that are going to have that same question or aren't 100% concrete on the answer. So I've always tried to have that mindset of not even just asking the question for myself but asking that question for other people on the team who might have that same question.

MIKE: I would offer that, in my experience, asking a question does not make you look stupid. It makes you look curious and eager and interested. I want to work with people who are curious, who are interested, who want to know what's going on because then I know that their skills will be growing. Honestly, when I'm interviewing people, and I've talked to many other developers who interview, who have said the same thing: one of the things they're most looking for is people who are curious. We're in an industry where we don't know all the answers; none of us do. But people who are curious will find the answer.

BRIAN: It's a pretty common saying, I guess, but the only stupid questions are the ones you don't ask. And it's important to keep that into perspective because, as Diane was touching on, if you don't ask the question, you're never going to know the answer, and so you'll just be in the dark, and you don't get anywhere with that.

MIKE: And then you're stuck, right? Being stuck is not good for your career. [laughs] I have to say that. It's not good for anybody. It's kind of the definition of a bad position to be stuck. If you're in a company that's interested in getting things done, that's the last thing that they want. And if you ask somebody, they're going to be interested in helping you out.

Again, there are unhealthy companies. There are unhealthy cultures. But in companies that care, and I think it's probably most, what you'll find is somebody is going to want to work with you because they want to solve the problem. And you're going to do that better together.

Maybe to pivot a little bit, one thing that we've done a lot here at Acima, and as I mentioned before, I've seen this happen in other places, but we've really tried to emphasize it is we try to have a [inaudible 27:10] boundary, an open door, a pipeline so that QA engineers have an opportunity if they're interested to build development skills, to actually start working on code, taking tickets and writing code, getting that experience and building that over time so that they can move into development if that's something that interests them.

I personally think that that has been a fantastic thing because it gives people opportunities. It allows us to work with people that we already trust and know are extremely talented and already know the business. It just seems to be a win all around. I think that that's a fantastic thing that we've done. And again, it's not only here that I've seen it, but I think it's a wonderful thing that we should do, that we have done, and that everybody should do if they have that opportunity.

What do other people think about that pipeline idea of there not being a hard boundary between QA and developer but trying to spread that role around so that QA engineers can do some development if they so choose and even move over into development?

JARED: For me personally, I think nothing builds a good company culture better than the possibility of upward mobility. There are a lot of people that go and get a job, and the only thing that they know how to do to change their position is to get a different job. And some people have all that knowledge and that experience with one company, and you're using that software internally. And if you're able to move into a new position and still retain that knowledge and within the company, that makes you not only more valuable to the company but also to everyone else around you.

Because I think there is a massive turnover cost to losing employees that have this tribal knowledge of your software, and they just go to another company versus retaining them and keeping them and moving them in other positions.

EDDY: I just love the perception that I've gotten for the past ten months that I've gotten here. And it's nothing but good things. And the fact that Acima is willing to invest within goes to show the environment and the company that you work for and the possibilities of happiness, of willingness to stay longer within the company.

I even heard of situations where people leave Acima, and they come back because of the environment that you guys provide, and I think that's really important. And I love the fact that Acima is willing to invest an hour or two a day to work on skills that we're wanting to and pay the debt back to the company.

MELISSA: This pipeline works both ways for dev and QA like; it improves both sides of the process because developers come in with that more test-focused mindset then produce better code because they're trying to think of all the scenarios. And then also it benefits QA because they start to understand the code that they're testing. So they can actually look at the code and see scenarios that maybe the developer didn't think about. So I think it goes both ways. I think it just benefits everyone all around.

EDDY: One thing that I love as well is...this was kind of explained to me when I jumped into the QA position is really that it's on me to learn. Whatever I put into this job, I'm going to get out of this job 100%. Coming from a sales background where I could be the top sales rep or hitting my quota every month, and I just keep doing the same thing every day, it's refreshing because, really, in the development world and in the QA position, I feel like whatever I put into this job I'm going to get out, Mike, like you said, with interest. I'm going to get back everything that I put in with interest.

So it really is a cool environment where the developers are helping QA, and QA, in some ways, are helping the developers, and there's this collaborative effort. But also, it's kind of on us to be self-taught and to learn what we need to know to be more effective in these positions and to master our craft, if you will.

AFTON: I'm just going to say I have loved watching people move into development from QA, not only because I love being part of the mentoring and helping and teaching because that's something I personally find a lot of joy in, but the quality of developers, like Melissa was saying, who have learned how to ask all the questions, and test all the scenarios, and think very test minded has blown my mind actually to see these developers who were my QA and then they're my peers, and they're reviewing my code.

And they come up with great questions that challenge the work I'm producing and help me to become better. And also, having the opportunity to mentor people as they're coming in helps me to improve myself, explaining and thoroughly understanding why I'm doing it the way I'm doing it. It's just good all around.

MIKE: I couldn't agree more. [laughs] Absolutely. I'm interested in this idea that I think, Melissa, you mentioned and others have touched on it. It makes us better developers as well when we are test-minded that not only were we thinking about QA coming over to development but development doing some of the QA role.

As a company, we have a policy, and it may not be exactly the same across all teams. Certainly, our team has a policy where a developer will test the code first before it goes to QA. We test within development before we send it over to QA. And we also have a process of documenting the tests so that we're thinking through the testing process enough that we can document it well enough for another developer and a QA engineer to test it.

And thinking through the problem, like writing up those instructions, is really good for poking holes in your code [laughs] and your thinking as you're going through that like, oh, wait, I missed this. And where our goal is to produce great software, that's a wonderful moment where the light bulb goes on, like, oh, wow, I forgot to do that. Or, oh, look at this thing that broke, or, wait, maybe I haven't tested that. I should check that and add that to the instructions.

Just going through the process of explaining what needs to be tested, I think, goes a long way, as well as doing the testing itself beyond what unit testing can do. Unit testing is fantastic. There is something to be said for manual and integration tests. They catch things in an integration sense that individual unit tests would not. Have other people seen this idea of a testing culture on the engineering side, improving your code?

ZSOLT: I've seen that in some of the open-source projects that I've contributed to over the years. You can definitely tell when testing is a big part of the internal culture of the group of contributors because everything just flows way better, and there are a lot less problems most of the time. And when people understand what's important to check when they're writing these tests and when they're thinking through these problems, it does help you catch a lot that you wouldn't otherwise catch.

MIKE: So, we've talked a lot about the value of collaboration. And we've talked some about this idea of a pipeline where QA developers can become developers but also the opposite. And developers working in somewhat of a QA role are able to be better developers as well, and that bi-directional communication is really valuable.

Team, I want to take that a little bit further. There was a comment that came up near the beginning of our conversation, but I think brought up something really valuable. Somebody mentioned the value of being able to reach out to the developer shortly after, at least get a response, and talk through a problem with them. I think that that's kind of a big deal. It sounds kind of trivial, like, okay, so you can talk to somebody, and they'll talk back to you. But having the mechanisms in place to make that really easy to where it's really easy to reach out and have that conversation, I think, is really meaningful.

What experiences have you had using that opportunity to discuss things where you reach out and have that conversation? Has that been universally positive? Do you feel like that is enabling to just ask for some feedback on that?

DAVID: I have a lot of feelings in that situation. [laughs] I have been in the spot where a QA writes to me or just sends me a message. And I've been like, "Oh my God, what's wrong with my code?" And then he's, "Hey, your code is ready for release." And I was imagining something completely different, [laughter] and I was scared.

And I've also been in the other situation where they just text me and say, "Hey, I found something strange. Do you have a few minutes to talk about it?" And we review it, and it's just a nice conversation. Sometimes there is a problem we need to fix. And probably, there is something we didn't see, and we need to communicate with someone who has more knowledge or more business logic and see if there is a new thing that we need to add or if there is a scenario that we didn't consider in that ticket.

So I think it's just great the way we manage that here in Acima. If there is good communication between, let's call it, both teams, it's going to be great. No matter if there is something to fix or if there is something to talk, it's going to be a great conversation.

MIKE: Thank you. Any other thoughts on that topic, about that open-communication channel?

JOSH: Yeah. I guess that feeds into what we talked about originally; earlier on, I guess, is when it's not an open-communication channel or when there's...you mentioned psychological safety, I believe is what you said earlier.

MIKE: Yes.

JOSH: These all play into each other. There's a lot of significant overlap in a lot of these areas. If there's not an open-communication channel, it's not just a company or a corporate decision that was made; it's just how people trust each other. And lack of trust often leads to shutting down and not communicating.

So that's why when we say, hey, it's a great team; you guys are all amazing; developers are great; QA is great; well, we are always communicating with each other. And I don't know of anyone who's actively angering people or causing a stir or anything. So it's like either work-related or not work-related; all those things can combine to create an open-channel communication or the opposite of that.

MIKE: I think there's a lot of truth to what you said there. It's hard to detangle all the threads there, right?

JOSH. [laughs] Yeah, for sure. I've experienced several of those in a couple of different places where I've worked where we actually have had meetings. When I worked there, we would have team meetings to discuss why we don't trust each other. [laughs] And I mean, it was like pin drop silence. No one would open up and say anything because it's this big, vicious cycle. You don't trust each other enough to be open and talk about why you don't trust each other. And it's bringing like an office head shrink trying to crack it open, have smaller meetings or something. I don't know.

But it seems like...I don't think there's really a solution I've ever seen to that problem other than they just reorganize teams. [laughs] They shuffle teams up, like, okay, we're going to break up teams and reassign y'all. And that works for another year or so, and then the problem comes back.

MIKE: I think it has to be supported from the top. You have to have leadership that cares.

JOSH: Yes. You have to have buy-in, yeah, for sure That's a great point.

MIKE: If the company cares to promote good culture...and I say companies, but companies aren't a single atomic entity; they're made of people. And you know that you're at a healthy work environment when you have people that care enough to create that kind of culture. And when you find somebody like that who really cares, you might want to stick around. [laughs] It's a place that you're probably going to really grow your career.

JOSH: And, I mean, career growth for sure. And I'll just say this last thing, but also, I had no concept of how heavy that kind of stress was to carry around when you go into those work environments and not be able to talk to people and know that everything you do for your job is hated. And [laughs] it's a lot of stress, and you don't notice it until you do. So by comparison, when it's not like that, yeah, stay, stay. [laughs] Why would you not?

JAMES: I think Mike, you, and Josh really hit the nail on the head. I've worked for companies where they put up billboards saying how cool their culture is and how great everything is and these catchphrases. But then once you're part of that culture, it's completely synthetic, and they're trying to manufacture this culture. Whereas one thing I've always loved about Acima is it almost seems like a sleeper company, right? I got hired on here, and I was like, why isn't everybody talking about this company?

And I come into the dev team, the engineering team, and I'm like, oh my gosh, it gets even better here. And really, there's nothing fake or synthetic about it. It's just this cool, organic culture where everybody, you know what I mean? There's no quota on the success that we can all see together. There's no shortage of success, so why wouldn't we help each other grow?

It is a very organic and natural culture as opposed to some other companies that I have been where it's kind of just lip service. They say, "Oh yeah, we're going to have the greatest culture, and here's free snacks and energy drinks." But it's actually very toxic with free snacks. Whereas Acima just seems to have just this amazing culture and also free snacks.

[laughter]

JOSH: Can't go wrong with free snacks.

MIKE: I was going to mention that when I'm interviewing people as new hires, prospective hires, I can often tell when they come from a place that had an unhealthy work environment. There's a little pause in what people say. They'll get close to saying something, and then they'll stop, and they'll pull back a little bit. There are some other signs as well. You don't know everything about the background.

But my point is that it has enough effect that you can talk to somebody who's been there, and you can just see it in the way that they talk. It affects their aspect, their countenance. And seeing that, first of all, is kind of sad. And I often notice that people in that environment have not grown as much as people in other environments because they've just not had those opportunities. They've been surviving, and they haven't seen the possibilities of growth that other people have had.

JOSH: Yeah, it's like duck and cover. You don't want to be the first chicken with its head stretched out. I mean, that's really what it is. You're just like, I know what my role is. I'm going to stay here and look at my monitor and type, type, type. And I'm like, other than that, [laughs] you limit your interactions.

And there are probably so many companies like that. That's the thing that is a little terrifying. Because you're like, oh, I'll look around and see what's available in the Valley or whatever. And you're like; you have no idea what's going to be there. [laughs] Not that I'm looking in the Valley, Jared. I'm not looking in the Valley; I'm just saying.

MIKE: Well, and it is important that when you are looking to get hired that you're interviewing the company as well.

JOSH: True.

MIKE: And there's nothing wrong with asking some questions. "Tell me about your company culture." And you'll probably pick up on some things. Right now, if you're looking for work in 2022, you've got a lot of options. If you see something that has a lot of red flags, it's probably worth moving on, taking a different opportunity because you're worth it. Your career's worth it. Your psychological well-being is worth it.

We've talked quite a bit about this idea, and I think that we've had some great discussion. We're near the end of the time that we had set aside for this. I love working with you. [chuckles] I love working with the developers I work with. I love working with the QA engineers that I've worked with. I love working with people who were QA and now have come to the development side. Working with you is a great pleasure. I hope that you feel appreciated.

And those listening who are not within this company, I hope we can leave you with a sense of your potential that there are opportunities out there to grow. And there's real value in engineers on both the QA side and the development side. And we can learn from each other, grow from each other, and make cool things together that we wouldn't be able to otherwise. It's been great having a conversation. I'll see you next time.