How to Develop Customer First Testing Teams with Phillip Talbot

Get ready to discover the most actionable end to end automation advice for some of the smartest testers on the planet. Hey, I'm Joe Calantonio, host of the Test Guild Automation Podcast and my goal is to help you succeed with creating automation awesomeness.

Hey, it's Joe and welcome to another episode of the Test Guild Automation Podcast. Today we'll be talking with Philip all about how to develop customer first testing teams. If you don't know, Philip lives to develop teams that are talented at assuring customers have an excellent experience with their software. Since 2013, he's worked as a manual QA, a QA engineer, and a QA manager in various industries including fintech, government, higher ed and food services. Philip has also founded two QA teams for two different companies and he currently manages a team of 16 QA professionals in seven countries. This is a topic I think a lot of people struggle with and I think you're going to get a lot of value out of this episode. You don't want to miss it. Check it out.

The Test Guild Automation Podcast is sponsored by the fantastic folks at Sauce Labs, the cloud based test platform that helps ensure you can develop with confidence at every step from code to deployment. For every framework, browser, OS, mobile device and API, get a free trial. Visit testguild.comsourcelabs and click on the exclusive sponsor section to try it for free today. Check it out.

Hey Philip. Welcome to the Guild.

Thank you.

Great to have you. I guess. Before we get into it, is there anything I missed in your bio that you want the Guild to know more about?

No. I think you pretty much summarized a decent amount of my work experience. I got into QA by accident, so that's one piece that got left out, I think. I didn't have that. I got into QA because someone didn't like me working for their department. But they were good enough to understand that I had talent somewhere else. And they told me, they said, hey, you know what? You should go try to be a qa. And I said, what's that? And they said these words to me. They get paid to break things. And from that moment on, as my mom told me, I would never get paid for doing this and I am going to make a living at it. And I have made a living at it. So when people ask me what I do, I say, I get paid to break things. Now I say, I get paid to help other people break things. So nice.

So how did you educate yourself then? This is. It's already off topic, but you know, a lot of people find themselves in this situation, they have a new role, they never heard anything about it. Like, how did you know where to get started then?

So I fell into some good hands. I really did. I owe my career success to one particular person. And when I moved over, I Knew nothing about QA. I didn't know how to write SQL. I didn't know the difference between Java and JavaScript. So you can laugh at me all you want, all of you experienced people. I knew nothing. And I sat down with a lady and she told me, she said that she would mentor me. And my manager told me, he said, hey, look, Philip, we fired the last person. This is a sink or swim job. You have one week's worth of training and that's it. And so she pointed me in all the right direction. This lady spent a lot of hours with me, mentoring me on how to write a test plan, how to manually test, because at that company, everything was manual. And so she really took the time and she Talked me about W3 Schools. At the time, Udemy wasn't really a big thing, but she taught me about going to W3 schools and teaching yourself how to just write code that way. And she taught me the very basics of SQL, how to write a select statement. And we were using mainframe, so I had to be able to query the mainframe and knew nothing about that. I didn't even know what any of this stuff was. So she. I fell into some really good hands. But then I found out after that, I realized, you know what? Education just isn't. College education is a lifelong pursuit. So from that point on, I started trying to figure out all the concepts that I could about software quality, from automation to manual testing to what's the difference between waterfall v model and agile? What's the difference of the different types of agile? And so I stumbled across Atlassian and some of their stuff and I watched a lot of their videos. I stumbled across you, actually. And so I owe some of my success to this podcast because I got concepts from here that I then used throughout my career, even as building out my teams. And then on top of all of this, I stumbled across Udemy. I was working with a developer and I needed to learn how to write some basic code. And I couldn't figure it out. And the developer said, hey, there's this course on this website called Udemy. And I went, u to what? And after that it was over. Because you can find just about anything you need to and if you wait long enough, the course will go on sale and you can afford it at a cheap price. And my big thing about that is pay attention to the reviews. Pay attention to the reviews. They really mean something there. With other things, maybe not, but with that one, pay attention to the reviews. So that's how I self educated. It was a lot of reading. I hold two certificates from istqb, the CTFL and the CTFL at and I downloaded all the syllabuses that ISTQB has online and I've read them all. And then I bought some of the books that were also recommended in those syllabuses and they're a little bit old, right? Like they're 2017, 2012. Some of these books are 2008, but they still teach you core concepts that you need to know and core proficiencies. So yeah, it was a lot of reading, watching videos and then practice.

Oh, great stuff there. I love how you say education doesn't end with college. That's what I love about our profession is you always have to learn, always have to be up to date. I think you had a great hack there. Looking at syllabuses a lot of times you don't necessarily need a tape or certification, but the syllabus is available and they can act almost like a self learning guide for you to dive into where you should be looking into for different parts of your career, I think. So that's a great hack for sure. So it almost sounded like you start off with good mentorship, someone took you under their wing, showed her the ropes and you learned the, maybe the testing, the technical aspects of it. So how did you then start moving up into, say more of a management role? Because I know when I speak to a lot of people, they're like, no, I'm a tester, I love it. But I want to get more into management. What do I do? What is some tips you can give to people, how to do that?

I have a severe problem. I'll admit this to you right now, I have a severe problem. I don't know what the person above me does. My problem though is not just that. My problem is I am going to find out.

That's how I got into starting QA teams and management and stuff like that. Because I asked myself, well, what does my manager do? Most of the times I reported to a manager that either had less experience in the QA industry than I did or had no experience in the QA industry. I worked for one job where the manager was actually the director of sales and he would be on the road for six months out of the year. Try Doing a review of your employees quality work. When you're gone for six months, you don't know what he does. So at that company, they passed me around to six different managers. None of them had any experience in qa and so none of them knew what I did. As a matter of fact, they didn't know what the team did. I was the one that wound up giving those managers the reviews that they then passed to the individual team members. And I was like, well, surely this can't be what management is like, this cannot be it. Like whatever it is, this can't be it. So Rex Black wrote a book called a while back on, I believe it was Managing the testing Process.

Yeah, great book.

Yeah, it's a great read, but it is not a thrilling read as most of these type of books are. So I read that book and I went, dude, I can do that, I can do that. And so at the time, the, a lot of the companies that are smaller, you, a person wears multiple roles, so. Or wears multiple hats, right? So sometimes we were reporting to a DevOps manager, sometimes we were reporting to director of development, Sometimes sales kind of all depended on, they were like, we don't know what to do with this qa. So. But I noticed a common trend. Every one of them shied away from automation if you talked about automation because they didn't understand the value that brings to a QA life and to the company as a whole. They would shy away from it and they would not invest in it. And I worked for one company where they did automation and then they just cut it out. And they were like, oh, we're done, we're not going to do automation anymore. And they still don't, by the way. They still don't do automation there. And I said, when I become a manager, I'm not going to do that. I'm going to preach automation and I don't care if the higher ups get sick of it. They're going to hear automation out of my lips all the time because it saves so much time. And so really it just got to the point of me being dissatisfied with who my management team was. They were all great. I learned from every single one of them an amazing thing, different amazing things. But I never learned how to be a manager so I had to self educate on that. I had to read. And then I got hired on here where so I built a team without being a manager. And that's all about influence, okay? When you have to influence someone on who to hire, that's different than you making that decision, and that's tough. So I had a lot of influence at my last company and I influenced them on who to hire. And then I trained all those people and that's how I built that team. This company I got hired in, I was going to be the QA lead. But then when I started going through all the details of what a QA lead should do versus what a manager should do based off of Rex Black's book, my boss ended the interview midway through the interview and he goes, I'm sorry, we have to shut this interview down. I thought I lost the job. And he called me back later the next day and he said, hey, Philip, we want to do a different interview. We realized mid interview with you, we need a manager and not a lead and we want you to be the manager. Would you come back and do the interview? And that's where I learned not the technical side, but the hands on side. I made a lot of mistakes. So if you've read management books, you're very familiar with the 360 view. I had to learn that the hard way. I had to learn the hard way of what not to say to your employees and what you can say. Because when you're a peer and you say something to them, that's entirely different than when you're a manager and you may say the very same thing, right? So my boss is a mentor and so I needed one. Even though I had the understanding of what the company needed, I didn't have the soft skills of a manager. So sometimes to move up into management, to answer the question directly, sometimes to move up into management, you do have to leave because there's just no room. If you're in a small company and there's no room for the management, that is okay. That's what that company needs. But that may not be what you need. And so you may have to look for that role. My suggestion is, if you're just starting off in your career, don't look for a management role. If you're just starting off in your career, learn the fundamentals. Get the fundamentals down. Know them by heart. Because if you don't, when you become a manager and you have to teach your team, you are going to have a problem on your team and you're gonna have a lot of defects going to prod. So learn the fundamentals. And then I would start asking your own manager, how do I become a senior at this position? What does that job description look like? Go out and read job descriptions for other companies, see what they mandate in Their management staff. Learn it, love it. Live it already before you get that job. Learn it, love it, live it before you get that job. I've had people who actually report to me, even though I wasn't their boss, because I learned it, I loved it, I lived it. And my boss looked at me and said, you know what that person, you tell them what to do. Because I don't have the time to be able to manage every single person that I have. Take that experience and roll it over into another job. Don't be afraid to transition for the sake of your career. Companies lay off people all the time. We're in an economic downturn right now and a lot of people are getting laid off. Gone are the days when companies stick by employees no matter what and employees stick by companies no matter what. You are in charge of your career. Take ownership. Don't wait for someone else to do it for you.

Absolutely, I love that point. Take ownership because like you said, you will get laid off. You're in the tech industry. You will eventually get laid off. I don't care what you say. I was laid off maybe three years ago and because I had worked on my skills on my side hustle, when I was laid off, I was all set because I could do what I was doing all along anyway. So that's a great tip. So I guess something that's different between your situation and mine is I'm used to work for large enterprises and it seems like your niche is like smaller companies. So with large enterprises, like they usually have process in place and like they have job titles and career paths. So I would just curious to know, how do you then start with a smaller company that doesn't have all that process and everything in place? Like how do you know what task to go start implementing and what are some challenges that you would face then when you're starting from, you know, from scratch probably.

So if you are delegated the title as manager and the authority, it's one thing to be delegated the title and no authority. I've seen frustrated employees in those positions. If you are delegated both the title and the the authority or just the authority to go do it, the very first thing that you need to do day one is figure out what the problem set is that you're facing. Automation will not solve every problem. You have Facebook, Google, they found that out. They have tons of automation, but they found out that doesn't solve every problem. I believe April 2017, Google had something like 4.7, 4.2 to 4.7 million automated tests that run and they still have people that do manual tests. Now it's not as designated as maybe what you'll find in a smaller company, but they still couldn't get past that. Somebody needs to have eyes on this. So you have to figure out what the problem set is that your company is facing. At my current company, when I got hired on SQA manager, they told me in the interview, they said, Philip, we have a problem with defects going to production. Every release we have catastrophic defects that stop all of our customers from being able to do their work. And so I explored that and I asked him, I said, I have to turn in two week notice. Please wait the two weeks before you do another deploy to production because I want to see what I'm getting into. I get in and the very first thing I start doing is just going through their processes. What do you have for qa? They had nothing. And I was like, okay, well I need to start implementing processes. So who do I need to hire in to help me? Do I need an automation engineer or do I need a manual expert? And you have to identify those, especially in small companies, you have to identify what the problem is and what the solution is. Because if you have a patient in a hospital that's been shot in the chest and they're bleeding everywhere, the question is, do I need a neurosurgeon to come in or do I need the ER doctor, right? Like I'm wheeled into the hospital, which one do I need first? Well, I got a chest wound, I don't need the neurosurgeon, right? So when you come into a company to build a team, that's what you have to do. You have to examine and say the patient's dying, what's the problem and who do I need to fix it. In my case I needed a manual tester because they had all new developers and one senior developer and so they were writing code that the new guys just didn't understand would break things. And so we brought in a very experienced QA manual QA expert and she has become my right hand person. And when you find one of those people, another key, don't let them go. Second main point, find out what your boss's priorities are. They better become your priority or you will not last long. So if you're all about performance testing and your boss is not about performance testing at all because he does not see the need, you either need to influence him to see the need or maybe he or she is actually right and you need to change. But if you don't figure out what the priorities of the company are, where the problems are, and then start aligning your team in that direction. You will not last long. The third thing I would do after I figure out those two things, what are my boss's priorities and what's the problem is draft. Just go out and plagiarize. If you need to draft job requirements, you need those. Because how is that other person that you're going to hire? How are they going to know if they fit that role if it does not exist? And in my case, it didn't exist. So. So I had to create these from scratch. And trust me, nobody cares if you go out and you look at a thousand of other people's postings for a QA position and you snip a line here and you snip a line there, and you build your own and then you change and add your own verbiage. No one's going to care that you did that, but your employee will care that they know what's expected of them.

Awesome. Great advice as well. Love this. So, you know, you mentioned you talked a lot about your team hiring team members. You know, also I think you said in the intro that there's. You manage people in seven different countries. Is everyone in house or are some of those contractors?

So we have a mix of our contracting types. So we have some in house and then we have some contractors and then we have some. Where. I don't remember the technical term. Where it's basically a group of contractors with project manager that is over that group of contractors. Right. And we deal with some of those people as well. Where your point of contact is the project manager and not the individual contributors. And then we sometimes we will directly contract with individuals in other countries. So that's how we kind of do it. And so it becomes very unique because the laws around contracting and the expectations you can or cannot set around those. So before you go with any contracting model, you should really talk that over with your HR department and with your direct boss, because it can be a little bit of a headache. But if you do it, you are changing people's lives. And I'm not saying that to be melodramatic or anything. You really are. $80 a day in Nepal changes somebody's life that lives there.

Good point. So I guess the question now is, how do you know what the right mix is? Then between, all right, we're going to actually hire someone in house as opposed to. I know this excellent contractor that has a great, great set of folks There we're going to use for this project, we're going to use them instead of an in house person.

So one of the things that I would say is, are you looking for longevity? If you're looking for longevity for that role, I would always hire it in house or do direct contract with somebody that you anticipate them potentially coming to the state. So an example is we had one person we hired directly in the states. That person moved to another country because they wanted to be with their family. We loved this person's work so much, we converted them to a contractor so we did not lose them and directly contracted with them with the expectation that when their entire family was able to move back to the United States, that person would come back as an employee for us. And we did that because this person was so good. She was my first person I interviewed, she was the second hire. She was so good, we did not want to lose her. And I'm not going to tell anybody her name because if I did, someone's going to come by and get her from me.

So how did you convince your company to do that then? Was it a company decision or was that you using influence to say, look, we need to come up with a solution to be able to keep this person employed somehow?

Yeah. So it was influence. I went to my boss and by this time I had an established reputation of success. And I went to my boss and I said, look, this lady, she wants to go be with her son and her husband and we will lose her if we don't do something. She will go back like it's gonna happen. And I said, so she wants to go back to be with them, but they're gonna come to America. But it will take a while to get all the legal stuff worked out. But do you wanna lose her? I don't. She's the best person we have. And so you don't do it with the people that aren't your best. Do it with your top tier talents, the one you want to keep forever at your company and bend over backwards for those people. And he had worked with her on several projects and so he understood the value she brought to the table. She has her master's in cybersecurity. And so when we had some cybersecurity updates that we needed to make and policies to implement, they leveraged her, which again, wearing multiple hats in a small company, you leverage people who have those degrees because they studied it for a reason. And so she helped us with that, which was a huge benefit. And he went, I don't want to lose her. And it was that exact conversation. You either do this or you lose her. And I don't want to lose her because I don't think we can replace her easily. And so in a larger company, it's a lot harder to get that. It's a lot harder to get that type of leniency from your management. I have two bosses right now, according to my one boss is the person who hired me and he tells me what to do every single day on the org chart. There's another guy who's my boss and he also tells me what to do every single day. Guess what? I have to figure out what both of them want. They both have QA teams underneath them. I manage the QA teams for two different divisions of my company. And so I have to figure out what their priorities are. There's one QA manager, and that's me. So I have to figure out what both their priorities are and how do I make them work. So you got to get to know them very well. Get to know that when your response to them, when you say this is the direction, you. You already know what their answer is going to be, which is, that's what I was thinking. That's how well you want to get to know them. You want to become basically where you are. The book they are writing. That's how well you know them. Because then you know if you're going to make the right decision for the company because they know what the right decision for the company is because they're the ones leading it.

So I guess a lot of things, a lot of times people then struggle with, all right, now I have someone that's offshore. How do I manage teams that are both local and in different locations. So how do you effectively lead or manage a team that includes both, say, domestic, local and international testers?

Yeah, so I have people in Canada. I have people in the United States. I have people. And by the way, they're in different time zones in the United States as well. I have people in Uruguay, Ethiopia, Nepal, Vietnam and a couple of other locations. So their dispersed time zones around the world. One thing is know what time it is in their country. Just know what time it is. Don't schedule a meeting for too late at night for them because it would be like you staying up till two in the morning and then trying to conduct a meeting. So be cognizant of their time. Another thing is we often request that there be some form of overlap, whether it's the first three or four hours of our day or the last three or four hours of our day. And if it's a situation, and I've had it many times where we can't, I will actually go and work at night for a couple of hours to hold meetings during the daytime their time. So that way we can have a touch base. But communications like Slack Teams, Confluence and Jira are essential. If you don't use some form of communication that is written back and forth between the two, you'll never get enough verbal conversation in to direct them. So a lot of times a simple comment on a ticket is more than enough to supply the direction they need. But it is a lot of meetings. It is a lot of meetings for sure.

So you know, I just want to jump back to something you mentioned when we first started our conversation about how you really believe in automation. And you said some companies don't or some organizations kind of deprioritize it. So what are some key considerations you would then know to decide when to automate a QA process and then maybe how do you go about maybe getting automation started within a company, especially a small company?

Yeah, so those are really great questions. The one of the things to look at is always look at your regression tests and there are some questions that you need to answer whenever evaluating some tests and whether or not you should automate them. Because there's three things. There's what you can automate, what what you should automate, and what you will automate. And those are all different things. It's just like in this podcast there's going to be the things that I want to say, the things that I should have said, and the things that I did say. Right. So that's the way it's going to be. And you have to create a valuable way of identifying what needs to be automated. Cost is one of them. How much is it going to cost me to automate this thing? That's complexity time. Right. Just like your story pointing. I do a similar sequence. It's 1 through 5 and I say how hard is this going to be? How much is this going to cost? If it's a five, it costs a lot. If it's one, it costs nothing. Or sorry, if it's a one, it costs a lot. If it's a five, it costs nothing. Okay, then another one is how valuable is it to the company? Again, one through five, one not valuable at all. Five super valuable. And you build a metric system like this. I have three key ones that I do and someone from Microsoft and I can't remember her name. She did a LinkedIn learning on it. And so I borrowed the metric system from her and if I can remember it, I'll shoot you the link to it. And she broke it down so eloquently, much more than I'm doing. And basically if it's. If your numbers is 13 or above, you can only get to 15. So if your total for that test case is 13 or above, you need to automate that test case. If it comes to a 12 to 10, that's when you look at maybe automating for later. Anything that is nine and below, don't even bother. You're not going to come back to it. It's not going to provide you enough value. The ROI is too low. Right. So that's one way of actually doing it. Another thing is how repetitive is the task. Everyone hates writing or testing regression tests. If you can automate those bad boys, that's the first thing out the door. That's what I always try to sell the company on. There's 70 regression tests it's going to take me. Even if I do a test, you know, every minute I'm spending 70 minutes doing this, not including data setup time, blah, blah, blah. And you tell them every release I'm doing this. We release every two weeks on our sprint cycle. So you're eating X amount of time, every single sprint that I could be doing these other things or these people could be doing other things. And you start monetizing that, your boss starts paying attention to the dollars where they go. If you turn those regression tests into dollars and savings, they start getting excited about that.

Absolutely. I love how you keep matching valuable to the company. Valuable to the company. That's how you stay employed and that's how you actually help your customers. I love it. That's how we hope to stay employed, right? Well, you hope. I mean, best you can. So you know, you mentioned. So you mentioned automation's key. So when you're hiring, do you. Is automation one of the key skills you look for or do you necessarily. Everyone you hire, do you expect everyone to be able to have some sort of skills that allows them to contribute to the automation process?

No. So I look at my patient lying here on my floor and I ask what does my patient need? Not what do I want, what do they need? So for the first year here at this company, I hired no automation people because the patient was critical. Their processes were broke. And I mean broke bad. They were writing code, not doing unit tests, they were. And then pushing that code to prod and just basic things were broke. There was no real good flow on the juror boards. So I needed people who had been manual testers, who had experience where things were flowing nicely and best practices to be able to come in and say, this is where all these places are broken. This is where we need to fix them. Because automation wasn't even going to get up off the ground because there was no way it could. So it didn't even have a fair chance. So even if I hired an automation engineer, I would have to pay them an automation engineer's wage or an estets wage for an entire year and not even use them in the capacity that they were hired for. Most people will get dissatisfied with that and they will leave you. So I looked at the problems that I had and said, what is my patient provided what my patient needed? And then I said, okay, how do I get them from where they're stable to where they go back home? Right? Every hospital believes that I go from critical injury to stability to going back home. And my version of going back home is how do I make this to where everyone's life is nice, customers aren't having problems with defects and I, I'm not having to have so much intensive manual testing going on. And at that point I look at who has automation experience in the past, who has experience, maybe even college experience with writing code or taking a certificate or gone into udemy and taking training on Python or Java or JS or whatever, right? Like, what are their skill sets? And then how can I leverage them to do automation? So do I have people that I've already hired that can do this? Can I train someone to do this? And then I go out and I look for an expert because I want someone to mentor the people who have no experience. So I go hire an expert, I bring them in and then I tell one of the people that have interest and have the ability to learn, I'm like, hey, pair up with this person and start learning what they know. And then together they'll build out the framework, they start building out the scripts and they get to learn the foundation of everything. And I believe in basically cross pollinating your team. If your team is large enough, you should always be looking at cross pollinating your team. Someone you should always have redundancy built into your team. The girl that I hired, that is that we turned into a contractor and will bring back when she comes back to America, believe it or not, she can replace me. I am replaceable. She knows everything that I know. I have trained her to do My job. Because if for some reason I go, they still need leadership. And so I've done that with everyone's role in the QA team. They're all cross functional. So that way if somebody leaves, someone else can replace them and then they can hire, then they can train the replacement. So that's how I structure it. This way, there's no siloed knowledge among the QA team members. You'll have experts in one area and you'll have people who aren't experts, but they at least know what the expert's doing. And then you'll always have someone who's training.

Awesome stuff. Okay, Philip, before we go, I know you've dropped a lot of actionable advice on us, but is there one piece, one piece of actual advice you'd give to someone to help them with their testing efforts, especially in a small company? And what's the best way to find or contact you?

Sure. So if people want to contact me, they can find me. I'm Philip Talbot on LinkedIn.

So.

And they can reach out to me there. They can connect with me. I'd love to connect with anyone on that. The other thing is my personal email address. They can reach out to me at the letter P, and then my last name, which is Talbot, T, A l, b o t, 1987 mail dot com. And then, you know, in the header, you can put what your question is, and I will try my best to respond to it as soon as I can. And then, yeah, so those would be the two best ways to get a hold of me. One thing that I would give somebody, you know, we're going into economic. Into what everyone perceives as an economic downturn. Right. And that's got a lot of people stressed out. Don't give up. Don't give up on your career. Don't give up on your dreams. Don't give up on the hope of your team. If you get hit with a hard hit in your company because of the downturn, it's okay. Don't give up. Don't cash in your chips. You can rebuild. Rebuild is just a part of life, but you can do it right. Never give up. You will hit some of the hardest things in your life. As a manager, I have actually gone home and shed more tears than any other role that I have ever done in my life. You'll hit times where you don't want to go into work. You'll hit times where you're like, I don't want to tell this person they're doing a bad job because they're a great person, but I don't want to have to provide that corrective action. Don't give up. Provide them that corrective action because they can't grow unless you do it right. So never give up. Never ever give up.

Thanks again for your automation awesomeness. The links to everything of value we covered in this episode. Head on over to testguild.com a434 and while you're there, make sure to click on the Try for Free Today link under the Exclusive Sponsor section to learn all about Sauce Labs awesome products and services. And if the show has helped you in any way, why not rate it and review it in itunes? Reviews really help in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild Automation Podcast. I'm Joe. My mission is to help you succeed with creating end to end full stack automation awesomeness. As always, test everything and keep the good. Cheers.

Hey, thanks again for listening. If you're not already part of our awesome community of 27,000 of the smartest testers, DevOps and automation professionals in the world, we'd love to have you join the fam@testguilds.com and if you're in the DevOps automation software testing space or you're a test tool provider and want to offer real world value that can improve the skills or solve a problem for the Guild community, I'd love to hear from you. Head on over to test guild.info and let's make it happen.