174: Nail Project Delivery with Jay Aigner

18
Sep

Jay Aigner is the CEO of JDAQA, LLC, a scalable team of experienced software quality assurance professionals that helps software development teams remove the stress of testing. We discuss the project delivery framework, ways to remove yourself from the business process, and why software testing is important.

—

Listen to the podcast here

 

Nail Project Delivery with Jay Aigner

Our guest is Jay Aigner, the CEO of JDAQA, a software consulting company focused on implementing and automating quality assurance, accessibility, and security testing. That was a mouthful. Welcome to the show, Jay.

Thanks for having me, Steve. Glad to be here.

So you are running a somewhat technical company. So I think our challenge is going to be to keep it high level so that everyone can relate to it. But on our pre-discussion, I think we achieved that. So I’m kind of excited about how it’s going to go. So let’s start with your journey. So you start as an upfair contractor a few years ago, and now you have over 60 people working for you. How did you do that? How did you build this business from just being a freelancer?

So I kept my nine to five job while I built the freelancing side up. I use my experience in QA to basically land a bunch of gigs, land a bunch of jobs, had a bunch of run at the same time. I didn’t set out necessarily to run a business. I just was trying to make extra income. And then eventually I started pulling other people that I’d worked with previously. My old boss actually ended up working for me and then built a team out. One of the bigger milestones was hiring a chief operating officer. She was one of my kind of ace QA people, and she had the option to either work with me at full time or to get a promotion and kind of stay at her current job. She said she really wanted to work with me. I took a leap of faith there and it was probably one of the best decisions I could have ever made because it took me from working in the business to working on the business. And it was a big transition for me. And then we just started keep hiring contractors. We have US based folks, people in Mexico and then the Philippines. And we’ve built out each one of those over the years. So it’s been a good run, man.

That is exciting. So you talk about your hiring contracts in different geographies. So what’s the difference between a contractor that you hired in the Philippines and one in Mexico? Are there cultural differences? Is there a different approach that these people take? So walk me through what is your thinking and what is your experience?

Great question. Yes, there’s certainly cultural differences. United States folks are much different than our team in Mexico. And then the people in the Philippines, completely different than either one of the other two. I think the common thread is hard workers, good communication skills. And you got to kind of find those common threads to be able to build those teams in different areas because good communication for someone in the Philippines is the same as good communication in America and Mexico and anything else. You have different time zones to deal with. You have different accents and things to get used to when you’re working with those different folks. But culturally, I think everybody that at least is on our team appreciates being paid well for working hard. And I think once we’ve established that as our foundation everything from there is pretty easy.

Okay, so in terms of communication are you saying it’s the same so you have to communicate the same way to people in Mexico and the Philippines or the US or it’s different? 

I think it’s the same I don’t treat them any differently I don’t talk to them really any differently there’s some nuances where maybe one location is more introverted or reserved or quiet than another. Maybe one kind of talk tends to ramble and just talk more than the other. Maybe people, and I’ll go ahead and say it, the United States are maybe a little overconfident sometimes. And so my communication to them is very similar, it’s just the communication to the client has to be the same. We have to teach everybody, like speak up when there’s a problem. Don’t over communicate, which confuses people sometimes. Don’t give them a bunch of every detail that you could ever list out and just be humble and realize that we’re doing a service for these folks. We’re not W-2 employees, right? We’re not on the payroll getting benefits and we just kind of come in and punch in and punch out like we’re here to do a job. And as long as we can communicate that effectively from whatever group it is, we’ve had a lot of success.

We have to teach everybody, like speak up when there's a problem. Don't over communicate, which confuses people sometimes. Click To Tweet

Okay, that sounds very interesting. So let’s talk about the frameworks here, because this book is all about blueprints frameworks. What is the framework that helped you the most in building your business?

Yeah, we talked about the project delivery framework, which typically starts with an initial sales call, scoping call, really discovery call first, and then a scoping call. The framework itself is scoping call after doing initial sales call, then we have our contract phase, then we have our onboarding and kickoff phase, and then there’s the execution and continuous delivery and improvement phase where we work with the client, understand what they need, and kind of make sure that relationship stays as high bar as possible. So it’s really just those four phases. And really, like I said earlier, hiring that operations lead really opened that up for me. I got to figure out, like, what is our process? Because when you’re in the weeds, when your head is underwater, and you’re just trying to get stuff done every day and working on client projects, you don’t really have enough time to kind of come up above the water, take a look around, see what your actual process is, implement one, improve it and kind of keep iterating. So I think that’s a big key is getting out of that day to day work and some of that comes with delegation and installing a framework like the one I just talked about.

Yeah, definitely. It helps when you remove yourself from the process, you can look at it from a bird’s eye perspective and then recognize that there are different elements and that different elements can be maybe broken down even further. So you don’t have to eat the elephant at one sitting, you can eat them one bite at a time. And then what I also found very useful in this approach is that when I broke down the process you said the main ones are scoping. So then you basically determine what is the job you’re going to be, what are the parameters of it, what it includes and what it doesn’t include. And then contracting was the next one, which is basically getting the clients to agree to those terms of how you’re going to work together. And then you resource the project, you bring the people on that you need, then you onboard the clients to make sure that you got all the information from them that you need and they know what they can expect and then the execution thing. So when you break it down like that, then maybe you can delegate better because some pieces gonna go to one person to another person and they don’t have to understand all the parts in order to be effective. What is your experience? Is this how you experience it? How did it help you to remove yourself from the process?

One extra note I think there is that some people are better at some parts of the process than others, and it’s easy when you’re doing it all to expect to hand it off to somebody and somebody else does it all. That’s not typically the case, and it used to drive me crazy that certain people wouldn’t be able to do certain things in the process. And I’m like, “Why can’t they do sales or why can’t they get these contracts, right? Or why can’t they do whatever?” And you’re somewhat unique in an entrepreneur in that you can kind of figure out how to do it all together. And as you start to realize, and somebody said the other day, let the pitchers pitch and let the catchers catch and the hitters hit, let them do their specific tasks, it really opened the door for me to say, “Okay, I don’t need to have somebody do everything I was doing, I need somebody to take a piece of what I was doing and do it better than I was doing it,” Improve the client experience, improve our kind of value to the client, and that just kind of cascades down through the rest of the process. Now yes, there’s people that can do, you know, kind of different parts of the process along the way and can kind of help you with that, but nobody’s gonna own the full process like you did. And if that’s your expectation, you’re going to kind of be up against the brick wall because nobody’s going to do it in your eyes probably as well as you did the whole process, right? So try to pick a piece that eats up a lot of your time, whether that’s doing scoping calls or whether that’s writing contracts or whether that’s finding people or whether that’s doing whatever. Find somebody you think that can take that on for you and just let them go. Give it a shot and they may fail a little bit here and there but at the end of the day, any failures in your business go back to you, right? Either you didn’t train somebody properly, you didn’t pick the right person for the job, you set the wrong expectations, you did all these different things. So I think just keep it in mind that even if you delegate, it’s not the person you delegated to’s fault if they didn’t do exactly what you wanted them to do and the process doesn’t work extremely smoothly. You’ve got to look back at yourself and go, “Okay, how do I improve how I’m training people, how I’m explaining things, and how I’m communicating what I need to get done for my business and my customers?”

Okay, I don't need to have somebody do everything I was doing, I need somebody to take a piece of what I was doing and do it better than I was doing it Click To Tweet

I think that is so true. I think the two, as you’re explaining this, the two things that stand out to me, the two big benefits of delegating, it’s not just that obviously you can’t do, you can only serve a certain number of clients and then you have to delegate. But beyond that, when you delegate and when you get these people, you give them the momentum by giving them the process, then they’re going to carry this momentum to a higher level because they’re going to then specialize in that piece of the process. They’re going to get better than you were to begin with, and then they can build further nuances into the process. They can make it better. And then the big all together is going to be actually better because the parts are better than you could on your own do. And it will add up to a better result. The other big advantage that I experienced was and initially I was very afraid of delegating because I thought that the client hired me and they want me to deliver and if other people deliver, I’m kind of cheating the client. Well, just the opposite happened. The client actually was wondering how I could possibly deliver while serving multiple clients. There was a big question mark in their heads. And then they saw that they had a team, then they managed to breathe and relax. Ah, okay, so I’m going to be able to supervise things and make sure everything’s happening. And I’m also going to have the bandwidth to engage with my client on strategic issues which they don’t expect me to be able to do if I’m in the weeds.

When you delegate, you give them the momentum by giving them the process, then they're going to carry this momentum to a higher level because they're going to then specialize in that piece of the process. Click To Tweet

Yeah, that’s a great point. I think it’s a great point. And it even, it changes your future sales pitches. You go from pitching saying, “I can do this, I can do that,” I can do this, to “We can do this, we can do that.” And my team and the people I’ve assembled, and it’s almost a better level of trust, I think, with your clients if you establish the fact that you can build a team, a scalable team, to accomplish anything. Like you said, if somebody’s hiring you and they know it’s just you, they know what the limits of one person is, they know that there’s not a million of you, so if you, but if you can convince them that “Look, I can build teams that can deliver higher value than you could expect from one person like me,” that’s a different level of trust and I think it’s, like you said, it puts the client’s mind at ease a little bit, they’re like, “Oh, these guys know what they’re doing and they’re going to be able to support whatever we throw at them.”

Yeah, because if it’s just you that they have to find another you and then they have to coordinate, that’s much better. 

Yeah. 

OK, so let’s talk about software testing. I mean, this may not be an obvious thing for everyone. Why software testing is important. Obviously, we want software that works well, but how is this whole testing thing comes to the picture? And why would someone just hire a firm to do the testing rather than have someone do the whole thing?

A great point. I think there’s people are learning that testing is an important part of the process. I think sometimes still, and even today, if a client goes and hires a development shop and they say, we need you to build this thing. They assume it’s just going to work, right? And it’s just going to do whatever they said it’s going to do and there’s not going to be any problems. And if they do, then they get their money back. And it’s like going to buy something at the store. If you’re on Amazon, something doesn’t work, you just send it back. It’s not really how software development works. It’s a living, breathing thing a lot of the times. So, I mean, testing is important because it’s your brand. If you will go to download your app or go to use your web app or go do whatever, use your VR application and it’s buggy and it sucks, the first thing you’re going to do is uninstall it. And the second thing you might do is leave a bad review. They may go say this, and that’s everything these days, social reviews, social proof, all that sort of stuff. People will just not download it. I mean, I’ll do it myself. I don’t go buy, download an app that has a two-star review. So testing’s important because it is your brand.

We work with a lot of custom software development companies and they’re usually a bunch of really, really smart programmers and engineers and project managers and product people. And that’s what they’re good at. They’re not good at building device matrices to figure out exactly which devices are supported and what needs to be tested and the browsers need to be tested on and what automation tools can we save time with and how do we test this thing effectively so that when it gets on our customers’ hands, it doesn’t explode. So a lot of times we can work with custom software development companies who are making products for other people. And they can even write, mark us up, mark our hours up as just part of the project. And they can make money by working with us, right? They’re charging a hundred dollars an hour and we’re billing them 60 or whatever the numbers are, they can upcharge our service and make money off with custom software development companies.

For SaaS companies that build their own products, we add a scalability that they don’t have by hiring W-2 resources or by hiring freelancers. If the software development lifecycle is very up and down, you build, build, build, build, build, you test, test, test, test, test, and then you put it on the market and you see what happens, right? And the same thing happens with every release. Make a bunch of features, you make up a bunch of bug fixes, whatever happens, then you put it out in the field. So to have the right amount of staff available is tough. It’s a tough thing to do. You don’t want to go higher, go higher 30 W-2 people because you’ve got a big release coming out. You don’t want to go higher 30 freelancers because that’s like herding cats and like trying to manage a bunch of independent resources. So that’s kind of where we found our sweet spot is we’re going to bring that scalability where if you need us for big releases, we’ll have a few people on the team.

We can kind of really crush through a lot of software, get it to where it needs to be, and then scale back down when you don’t need us. And then we kind of scale back up when the next release comes out. It’s a very elastic relationship that we have with a lot of our clients. So it’s typically custom software development companies that build stuff for other people. We augment them as kind of their arm. And then for the SaaS companies, we come in early, typically, and kind of become their QA team. Or later on in the process, when they’ve gotten their series A, series B around and they’re growing really rapidly, they either just need really good people to step in or they need people to come in and implement automation because they don’t have the experience in house to figure out, “Okay, we do have a big QA team, we have a big product, we got a bunch of money now to continue to grow this product.” How do we save time on testing the same things that we do over and over and over and over again? And that’s where we’ve found a really good niche with all our partnerships with a lot of the QA automation tools companies. We can come in as a recommended partner for a lot of our tool partners and implement, maintain, and kind of save a bunch of time and money for those clients who are in that kind of hyper hockey stick growth phase, who don’t want to be waiting for builds to be tested manually by a team of 50 people. So it’s multiple pillars that we go across, but testing has become a much more important thing and a much more understood thing, I think, over the last 10 to 15 years I’ve been in the industry.

Fascinating. So you basically help, it’s kind of a staff augmentation business. You basically place these experts that you groom into companies and they will do the testing, and when they don’t need it, then you can pull your experts back, place them somewhere else. Now, what about the automation? I’m really curious about it, because automation is a big buzzword these days. Everyone’s trying to automate processes so that humans can be basically less human labor, need to be tied up. It is even more flexible and cheaper. So what does it take to automate testing, and how does it fit into the big picture?

I would say, and my favorite phrase for automation is it’s like Bigfoot, right? Everybody thinks they’ve seen a fully automated, non-human interacting test framework, but all there is is like a blurry picture off in the woods that doesn’t exist. There always needs to be humans involved in testing softwares. Just, I can tell you from my experience, you got to have people there to do things that automation will not do. That being said, we typically come in, we’ll identify the areas of repetitious testing that go over and over and over again. You know, logging in, logging out, forgot password, profile stuff, stuff that doesn’t change a lot, kind of like the bedrock foundation stuff of an application. We’ll write, you know, I’m a huge tools nerd. I love tools. I love QA tools especially. And we’re we’ve got a lot of partnerships I mentioned with QA automation tools like Ghost Inspector or Functionize, Sauce Labs, like Reflect. There’s a bunch of different tools that you can use to automate your testing. So once you’ve kind of figured out what you need to automate that you’re eating up a bunch of time with, you write automated tests around those, typically on a SAS product these days. If it’s a web app, you can just kind of record and click. You can do some kind of manual code injections in there to grab certain elements or do different things you need to do. That’s a little more technical. And then you can hook those into the build process. So when a developer goes to write his code and then he hits the build button, he can’t even get that code out to the general, not the masses, but to the QA team or to the product team. If he didn’t if he broke some of the automated tests, right, if you can’t log in anymore after this guy just checked his thing in, but whatever you just checked in is not good. Right. So he has to go back and take a second look at it and go through and fix his code. Push it again, the automation test pass, it’ll automatically get pushed down to QA where people can kind of take their manual pass across it. And you’ve already kind of taken a bunch of the guesswork out of does the core functionality of the application work before it even gets to the QA’s hands.

So essentially, it’s streamlining the quality assurance process by automating all the routine, repetitive, mundane pieces so that the software engineers, they can really focus on the discretionary, important pieces. What about AI? I mean, you know, this year since ChatGPT came out, everyone’s talking about AI, how AI is disrupting different industries. How is AI applicable in social testing and what are its limitations?

Yeah, I thought about this question before. I don’t have the best answer because it’s still so new that we use it to help us strategize the test that we’re going to run. We can feed it some information around parameters of things that we need to test, and it can give you some pretty good ideas. And we’ll take that and tweak that and use that as maybe a high-level strategy plan. It’s the current iteration of AI today, the one that’s available for most people through GPT, and you’ll run into it, is that context is still missing, right, and context is so huge in QA. You need context of did this thing do what it was supposed to do on this build? Did it do in the last five builds? Oh, wait, it broke two weeks ago because we put this feature in that broke the login and we broke whatever. There’s context just inside the application itself. If I do this thing, this thing is supposed to happen. That’s still not quite there where you can just kind of unleash AI to test your application. Now there are tools like Functionize and MockTest and a couple of these other ones that we work with that use AI in some pretty interesting ways to, so for example, if you have a forgot password field, it will use AI to create a bunch of tests, a bunch of automated tests to test the bounds of what that’s supposed to do, right? So like you kind of, they kind of know what a forgot password field is supposed to be, what it’s supposed to contain, what characters is supposed to accept, what it’s not supposed to accept. And it’ll build these automated tests around and go, Oh, I recognize that’s a forgot password field. So these are all the things that we need to test around that. And it’ll build some automated tests around it. I don’t think that’s kind of pure AI. I think that’s kind of just maybe even just automation in general that’s doing. So I think we’re still in our infancy. I would love to kind of crack the code on what does it mean for testing, but certainly it hasn’t gotten to the point, and I’m not concerned in the least bit, that it’s going to replace human testers at any point in the near future.

Yeah, I don’t think it does. It basically just amplifies your skill. You can use it as a lever in your business. You can do things faster, but the thinking still needs to be there and the way it does is organize existing knowledge. It doesn’t create new knowledge. So definitely that’s that seems like a good direction. So finally, I want to ask you this. Quality testing is such an elusive topic. How do you even know whether your testing works or the projects perform? Is there a way to quality assure the quality assurance?

What a magical question that is, I think the short answer is yes. If the product does what it’s supposed to do, it matches all the requirements. Then, and it’s been run through a QA team, then yes. right. They did what they’re supposed to do. It, they check all the boxes. It does all the things it’s supposed to do. From a more high level perspective, do, are people doing what they’re supposed to be doing in that role? That’s a little more of a nuanced question. I think that’s why we’ve been pretty successful is because we’re good at identifying the talent up front. We get a lot of feedback from our customers on how they interact in the process. And I mentioned earlier, communication being such a big thing pretty quickly. And I mean, everybody out there will know people who don’t communicate, right? We all know the bad communicators in our lives or in our business or in our coworkers or whatever it is. And those are the ones that will cause the problems in any facet of business. It doesn’t matter if it’s QA, if it’s development, if it’s whatever. So I go back to communication because QA is the last line of defense, right? We are the last line before it gets out to the customer’s hands. And we have to be exceptional communicators. We have to drive communication with the product people, with the project people, with the developers, with the C-suite, with the stakeholders, with the customers, with everybody, we have to understand, we have to be able to communicate. Does the thing do what it’s supposed to do? And if it’s not, why? Right? And so if we’re doing that from a pretty abstract perspective, the answer is yes. From an employee perspective, do the people function in that communication role at a high level? Yes, you can tell that. And you can kind of, over time, figure out who those people are. And just from a general qualitative perspective, how often are things getting past the QA team into production or how many times are we iterating on things with developers back and forth because we didn’t communicate it properly and we said the wrong thing and we didn’t document it enough, or we, so there are ways to kind of, you know, put some metrics around it, but I’m not a huge, huge metrics guy. I mean, I enjoy them for certain things, but a lot of this is just touch and feel. It doesn’t feel right. Does it work together? And is the product successful because the quality is high?

So that touch and feel thing, which is easy to discount it as fluff, but actually I think the opposite is happening with AI and chat GPT information is available immediately to everyone. So that’s not a differentiator anymore. Knowledge is basically, it’s there for the taking. It’s about synthesizing the knowledge. It’s about communicating. It’s about understanding. That’s the differentiator. And people who communicate well, they can connect the dots, they can work together. They can utilize that knowledge that is out there ubiquitously. Awesome, well, great conversation. Really enjoyed it. Uh, so if, if our listeners would like to learn more, maybe they run a software company, a SAS company. They need some testing resources that they can pull in at short notice and augment that team. Where should they go? Where should they look?

First of all, everybody should go give Steve’s podcast a five star review. You’re a great host, Steve. Thank you for having me on. I appreciate it. I love your podcast, by the way. It’s a great podcast. jdaqa.com or find me on LinkedIn, Jay Agner, A-I-G-N-E-R. Feel free to email me, J- A-Y @jdaqa.com. I’m happy to talk any QA with anybody. So I appreciate you having me on, Steve. 

That’s awesome. It’s a pretty niche business. I love it. Whenever I see a really well-niched business that, I mean, you’re the first on this podcast. We have had 175 episodes here. Lots of softer people, but not as niched as you are. So that’s pretty cool. If you need testing, definitely check out Jay. And thank you for coming to the show.

 

Important Links:

This entry was posted in . Bookmark the permalink.