Giving Control Back to Software Developers: An Interview with Mike Faulise

Jennifer Bonine: All right, we are back with our second-to-last interview of the day for our virtual conference, and we are here with Mike Faulise.

Mike Faulise: Hello.

Jennifer Bonine: Nice to see you again.

Mike Faulise: And always good to be here.

Jennifer Bonine: So, a couple of things I thought we would talk about that actually haven't come up in the last two days, one of them being that you know lots of organizations are talking about DevOps, CI, CD, how that's playing out, agile, right? So ScrumMasters as opposed to project managers, for example. Roles shifting and changing.

With all of that happening in the industry, being that tap|QA works with many large and small organizations, kind of, on projects, cutting-edge stuff as well as maintenance stuff, what are you seeing right now as a trend around, say, release management and some of those roles?

Mike Faulise: Sure, so there's a lot of stuff.

Jennifer Bonine: I know. That was a big question. I know, right, did you get that all?

Mike Faulise: It was a big mouthful. You just sort of gave me a big mouthful of stuff here.

Jennifer Bonine: All of this, make it into something.

Mike Faulise: All right, we're going to make it into something beautiful. And you will notice there are no drinks in front of us.

Jennifer Bonine: I know, we should have drinks.

Mike Faulise: I don't know who's in charge, but someone needs to be yelled at.

Okay, release management. So, interesting enough, so I think one of the things that we see at tap|QA—go to tapqa.com, by the way—one of the things that we're seeing, just from a quality trend, is that a lot of organizations have moved, you know, certainly into the agile space in the last ten to fifteen years, if not now getting into DevOps, and one of the things that we see DevOps replacing is really a part of release management.

The idea that we've been giving back control to developers, which we never used to do before, and now we're giving that control back, and so now all of a sudden ... The reason for part of this is the fact that that release management role has started to disappear from organizations. And I think this is one of the reasons why. And part of that, I think, is technology. So the fact that we have some of these great technologies now that make life easier for us, we have virtualization tools that spin up environments in a minute, so technology's made this easier, but it hasn't necessarily added quality.

So that's where we need to continue to invest quality into. Whether it’s agile, DevOps, because that release management piece has kind of gone from being a role that's been driven, along with change management and all those other great attributes that we'd want, to now being driven more by technology. And so that's where we start to lose a piece of it. And if you were just watching the last interview about robotics, there's a lot of great things from AI and from automation, but we do have to be careful about the level of quality that we lose.

Jennifer Bonine: Yeah, yeah.

Mike Faulise: So there, that's where there has to be sort of this yin and yang.

Jennifer Bonine: Yeah, absolutely. Well, and I think it's interesting too, if you just take ... You know we talked a little bit about it in some of the other interviews, with recently there being an issue with Equifax, right, and a huge breach in their data and their security. They went really fast right 'cause now they're under pressure to fix it, to create a link where people can go to to see if you were compromised, and their link broke.

Mike Faulise: Sure.

Jennifer Bonine: Like, you've just had a major failure, you now need to react, and because they were going so fast, they then all of a sudden can't even serve the people that they're trying to tell whether or not they were compromised.

Mike Faulise: Yeah, I find it interesting, it really is, with the propensity for us to go into this DevOps space, it is interesting that now we are really trying to have our teams be more responsible for what they put out there, so they can fail fast and fix it quickly. And it's interesting, if we look at it over the span of, say, thirty years, you know, thirty years ago we had a systems analyst doing everything. And so they were the one person you went to, and that was it, and they had control over everything.

And you know with the advent of the internet and client server and shutting off control to that systems analyst so they couldn't do things, and creating ops teams, and now, all of a sudden, now we're getting into the microservices—more agile, back to them having control of the actual production environment to these microservices teams. It is funny that in thirty years we've literally come full circle, back to what I would consider systems analyst teams that now just involve a developer, a tester, and somebody that's helping with release management.

Jennifer Bonine: Yeah, that encompasses what that person was.

Mike Faulise: What a systems analyst used to do all by themselves. So it's funny how we've literally come full circle.

Jennifer Bonine: Well, and that is so interesting, and something that you probably see being in the services space in particular, right, 'cause again, tap|QA doesn't produce any software or tools, it's purely the services that help people do all of these things around testing and quality.

So something that I find interesting, as I've heard recently, several large companies who have had actually some pretty massive failures themselves in quality, rationalizing their vendor list down to a very small number of people. And I just was curious to your thoughts on that, 'cause to me it seems almost contrary to the idea of collaboration, the idea of getting, you know, multiple people to look at a problem and finding the best person to solve the problem. You know, any thoughts on that, just in the services space?

Mike Faulise: Yeah, we definitely see that. I mean, I think that as organizations are ... They're trying to answer the problem of human-capital management. Like, that's really what they're trying to do. And you see a lot of organizations that don't have responsibility for direct project work. They're ending up rationalizing these things down, because they want to just rationalize down the number of people that they have to go choke a throat on how these humans aren't working the way thought they might.

So because we have become so diverse in the subject matter expertise, it's really hard for one company to do that. So we certainly have had the fortunate nature of being able to get on a lot of these vendor lists because of the fact that we are so skilled in the testing services.

But what I would recommend to large-scale organizations is that you really do need to be open to figuring out, how do we get vendors that really are partnering with us and solving a problem for us? And that's a tougher challenge, and easy to say from behind the camera.

Jennifer Bonine: Right, right, but it's a hard challenge.

Mike Faulise: It's a hard challenge, once you're in the world of practicing this, it's hard, and nobody and no manager that I've ever met loves playing the blind resume game. And so that's really a big challenge that organizations have today, is how do we partner with somebody that we can cross a trust bridge with? Because there's all this great technology and a lot of great open source technology that now, we need to better understand, "Hey have we tested the technology that's running our business?"

Because we just sort of thought and gave the assumption that because everybody else is doing it now, it's okay. You know, if we look at ten years ago, nobody was using open source because they were worried about security. Turns out they might have been right.

Jennifer Bonine: There's a few issues.

Mike Faulise: That's really where we're at as an organization, we have to start thinking about those things from more of a quality perspective.

Jennifer Bonine: Yeah, and well, counterintuitive, right, because we talk about agile being, you know, fail fast and often. We want teams to be self-directed, self-guided, and yet and to your point, these organizations outside the teams that have to do the work are mandating how they get the people to do the work that they need to do.

Mike Faulise: It is very counterintuitive. But that's where, in getting back to them, we have to hire the right people. And so how do you really understand the people that you're hiring, especially when you're being forced to hire potentially through a very smaller subset?

And that's really where, you know certainly we at tap|QA, we're starting to understand that we have a large supply-demand shift in the quality space. So what do I mean by that? If you can imagine three bubbles, right, maybe our heads could be one bubble and then be, like, one up here. But the idea being that we have a supply-demand issue, and here's what I mean by that, we have ... Everybody wants in the middle of those three bubbles, which is quality, industry knowledge, and technology. And in the last, call it ten to fifteen years, it used to be you could only get two of the three and everybody just wanted, you know, understand my industry, and make sure you can test. Like, that's what everybody wanted.

Well, now that's shifted. And it's shifted away from the idea that I care about, you know, you understanding the insurance business, to "I don't really care if you know the insurance business, I just want someone with QA and with tech." And that's created this massive supply-demand issue of everybody wants to do continuous integration, they want to do DevOps, they want to do continuous delivery or deployment. They want to do all these great technology things, but they don't have the internal staff to do it.

So they have to either rely on great partners, like tap|QA, tapqa.com, or they really have to understand, how do we hire the right people that can close that skill gap? And you know, one of the things that we've done is really taken the time to vet out the different skill sets, 'cause you have to be creative in the skill sets that you're looking for. And in one of those, you know, if you find people that already know how to code or that already can close these skill gaps, chances are even if you hire them, you might lose them in your own organization to development. So how do we find these people that might want to stay testers, because they love that sort of creativity of testing and the analytical nature of testing, yet they don't want to become developers?

And you know, one of my nuggets I give is, find people that are musicians. With, they have a musical instrument in their background, especially the piano, which, frankly, I can't play, but if people can do that, they make rock star testers. And they may have the capacity for potentially coding, which is really where we need a lot of our testers to go, if we want to keep up with the DevOps, the continuous deployment, in the age that we're in today.

Jennifer Bonine: Yeah, no, I think that's an interesting point for folks out there, is you find there's a lot of, maybe not initially, but when you think about it, the similarities between learning a musical instrument to learning how to code or anything else and picking up a coding language. So, I think, a great tip for folks out there that are saying, "I'm struggling with hiring."

Obviously, again, one last time, if people wanted to get a hold of you and said, "Hey, I'm interested in some of the stuff you've said. I want to find out more about what tap|QA does and the organization," how do they find you?

Mike Faulise: They can find us at tapqa.com and go anywhere in the site, or send an email to [email protected].

Jennifer Bonine: Perfect, thanks, Mike.

Mike Faulise: Hi, Anthony, hi, Vanessa.

Jennifer Bonine: See you guys.

Michael Faulise is the founder and managing partner at tap|QA, LLC, a global company that specializes in quality solutions for businesses. Mike focuses on sales and delivery where he consults with clients in the areas of leading development, quality assurance and testing, technology and process training, and process improvement. He has seen software development evolve along the multiple paths of various methodologies but has found quality has remained essentially constant.