Scaling without breaking — what an ex-SpaceX exec teaches B2B GTM founders

Welcome back to another episode of the Bridge the Gap podcast powered by none other than Revenue Reimagined. Today's guest is none other than Michael Gin, who is the president and CEO of SQA Services, a company that helps some of the world's most regulated and high-stakes industries maintain quality, trust, and operational control. Before joining SQA, he held leadership roles at SpaceX, Rocket Lab, and Heliogen, where he scaled operations across everything from rocket systems to renewable energy and medical device supply chains. But this episode isn't about theory. It's about what it actually takes to build systems that don't crack under pressure and what go-to-market leaders can learn from the world of quality and operations when things get messy. Michael, thanks for joining us.

Thanks for having me, guys.

We want to jump right into it and talk about what quality actually means. You've worked in high-pressure industries—SpaceX, Rocket Lab. Now at SQA, what does quality mean when the cost of getting it wrong isn't theoretical?

Yeah, that's a big question for sure. I think in its simplest form, you have an engineer or a designer or someone with a vision that has a product or a thing that they want to do a particular function. I think quality is the entire process that ensures that that intended function happens the intended way every time you use it. So it's very tied in with reliability and all sorts of other things that people talk about. But I think at its core, it's just making sure that the product or system or software or whatever I designed does what it's supposed to do without any sort of surprises.

So if you bring that to the next step, what would separate a quality initiative from a quality system?

Yeah, I see a quality system as kind of the overarching or underlying process that you set up in order to run your business. And people will talk about a QMS, or a quality management system. And now that's kind of evolved into this concept of a BMS, or business management system, because it is larger than just when you call something quality. People tend to look at the quality engineers or the inspectors and they're like, "Oh, that's their job." But there is a big push philosophically to be like, "No, quality is everybody's job." And so I think the quality system is kind of the structure you're setting up so that when I release a design or I revise a design, that it's going through the appropriate steps to make sure that all of those changes are appropriately cascaded throughout the entire manufacturing, supply chain, end-user aspect of what you're doing. And so I see a quality system as kind of like the system—for lack of a better word—that you're running your business on.

I think quality initiatives are really more around, I want to get from point A to point B, and I need to do something to enact that change. And so I see initiatives usually as having a scope and it's something that you want to change, you want to improve. And that may involve making changes to your quality system, but it's typically a more finite, fixed thing.

How do you balance that? Because in the software world, we talk a lot about, you know, perfection is the enemy of progress. Do you ship fast or do you ship right? Or as we say, ship an MVP? And flipping that to the world where you come from—you know, SpaceX, aerospace—you can't make a mistake. So how do you balance operational safety at scale without slowing things down?

Yeah, I think SpaceX is a very interesting case to look at because they really did flip the paradigm around like quality and risk posture in the aerospace industry. Because historically, especially space has been very much a government project, right? It's taxpayer dollars going towards these multibillion-dollar programs to get people on the moon, to launch a space station, to send probes to Mars. And so the tolerance for failure is basically zero because I'm spending taxpayer money on this. I need to make it look like a good decision, so I can't have a rocket blow up. That looks really bad and ends up killing my program.

I think it was cool to see the approach that Elon really took of taking calculated risk, and he really did take more of a software approach of kind of MVP, fail fast, learn fast—very much the way the software startup world works. And they did it in a way where they built themselves enough tolerance for failure. And if you go back to the early days of SpaceX, the first three Falcon 1s failed, and they basically had no money and they scrapped together a fourth Falcon 1, and it happened to work. But if that fourth one would have failed, like you can ask anybody that was around at that time that predates me, but they were like, "Yeah, we all knew this was our last shot."

And so it got to a point where they had a zero tolerance of failure. But then past that point, they unlocked the necessary funding and got some contracts. And at the end of the day, they were launching cargo, not people, for a long time. And so you still had some tolerance of failure to say, well, if I'm moving the industry forward and doing things that have never been done before and I'm trying to land and reuse rockets, which is a game changer from a financial perspective, then you have to acknowledge that I'm never going to make the progress at the speed that I want if I wait for everything to be perfect.

And so they really did introduce this concept of iterative design and test, fail, test again. And it's cool to see how that has rippled through the whole industry because after SpaceX, I went to Rocket Lab, and we had a mission failure as well. And even just simple things like reading the YouTube comments, people were like, "You guys got this. Space is hard. You'll figure it out. Keep up the great work." And I was like, man, pre-SpaceX, that would have not been the overall vibe. It would have been people saying, "See, this is why private space doesn't work. Leave it to the experts. You guys are wasting money." But there really has been a huge culture shift industry-wide to realize if I want to innovate and I want to keep up, I have to have some tolerance for failure.

Now, that whole equation changes when you start putting people on these things because SpaceX will be the first to acknowledge they cannot afford to fail on a manned mission. And so what they've done really well is created the opportunity for them to launch exponentially more frequently than everyone else, launching their own satellites where they can have a very high tolerance for failure. And so they'll design the Falcon 9 to last 10 times. They wanted to be able to reuse it 10 times. And now they're launching them 15, 16, 17, 18 times. But they're doing it on their own satellite missions so that if one of them happens to fail, they don't have angry customers. And that allows them to learn what is the actual failure limits of all the components on the vehicle. So now when they put people on it, they know what their factors of safety are. They know that they've got margin. And that's been really helpful in allowing them to be more and more reliable.

It's fascinating, the differences as well as the parallels between what we'll call non-software and software. We do a good amount of work with companies on both sides, and I think that a lot of software folks don't realize that things outside of software could benefit the big, sexy SaaS industry so much. Where it's like, "Oh, we're SaaS, and we're the best, and let's do it our way." So hearing you talk about all this certainly makes my brain think.

You're running a company now that steps in, probably safe to say, when supply chains or quality issues, when things break down. Maybe sometimes people call you and it's like, "Oh, you know, we're starting something new and things are great. We're just looking for a change." But I would imagine, similar to my business, it's not like, "Oh, things are wonderful. Let me call Michael at SQA." So where are you finding most people are exposed, and how do you actually come in and get control and bring things back to the way that they need to be?

That's a good question as well. I think there's a fundamental bandwidth problem that is really hard for any one company to solve by themselves. When you look at most aerospace companies and pharmaceutical companies, those are kind of the two big swim lanes that we play in amongst some other industries. But most of the large companies have supply chains in the 1,000 to 10,000 plus suppliers all over the world. And at that size of a supply base, your ability to know what's going on at 10,000 different facilities all over the world is close to zero, right? You would need armies and armies of people to put out there and understand what your risks are. And so I think that's probably like the biggest shared gap that everybody has is just you've got a huge supply chain, and depending on the...

Size and maturity of the company—you've got a team of supplier quality engineers or auditors that maybe is a couple of people, maybe a hundred people, but it's not 10,000. So you have this kind of juggling act where when I first started at SpaceX, I had 262 suppliers that I was personally responsible for. I was straight out of college and I was a mechanical engineer, and I got thrown into avionics—all the electronics parts. So I just spent the first two years traveling every single week, flying all over, going to these suppliers, trying to understand what they were making, how they were building it, what the potential risks are there, feeding back any issues we were seeing internally—test failures, those types of things. And yeah, it's just you have to prioritize and use some sort of risk ranking and spend your time where you think it's going to have the biggest bang for your buck.

World class is, you know, people say you should have like 10 to 20 suppliers per supplier quality engineer. But very few people actually have the resources to achieve that ratio. So you end up spending a lot of your time with a very small number of suppliers that generate the majority of your problems, and you have this long tail of suppliers that you may never even visit.

Is there a way to identify what suppliers are higher risk or might burn you beforehand?

Yes, there's quite a few different approaches people take to that. None of them are foolproof, and I think this is a big area that we're starting to see some really cool advancements in, and we're trying to invest in this as well. But AI and analytics are light years ahead of where they were even four or five years ago. So trying to really look at what leading indicators do I have that maybe something is going to go wrong. But at the end of the day, those models are only as good as the data that you can feed into them. And that's a huge problem that people have—if you're trying to collect information on 10,000 suppliers that you work with, in most cases you're sending out a survey or you're scraping website information, or it's something where you're highly reliant on them being truthful about their situation. And whereas I would love to think everyone is truthful, some people will nicely polish over areas that are huge risks.

So I think that's one of the fundamental challenges that everyone has that's trying to apply all this advanced analytics to help them understand where they should be spending time. You can come up with really cool risk models, but if the data you're plugging into them is poor, then the output is going to be poor. And that's where I think we have a big advantage just in the nature of our business—we've got a thousand associates, quality professionals in 65, 70 countries all over the world that can collect unbiased, third-party, factual information. I went there. I saw with my own eyes what's going on, and I can feed you that information. And now you can put that into your risk model and you can trust it. But that's something that is probably the biggest challenge that I think people are facing right now—just obtaining reliable data to make any of those decisions off of.

But once you have it, you can look at things like past non-conformance history or honestly on-time delivery history, which can tell you a lot because one of the key reasons that things are late is due to quality issues that the suppliers are experiencing internally or they're experiencing with their sub-tier suppliers. And so you can infer a lot by symptoms that you're seeing. But then you kind of need to send someone out there so you have firsthand perspective of, okay, I see the symptom, but what is the cause? And that's something you can usually only get by going and seeing yourself.

We're going to swap up a little bit. This segment we're going to call "Leadership Under Load." So you've gone from the tech leadership type of world where you're managing really technical teams to now the entire company. So you have a lot of other things besides the technical load. How has your leadership style evolved across those transitions?

I think it's involved a lot of learning on my part. It's one of the things that always attracted me to supply chain and supplier quality—I am a relatively technical person. I have a mechanical engineering degree. I always liked math, science, engineering type stuff. But I also really like the people element of business and understanding what motivates people, what drives people. I think that was one of the key things that allowed me to be successful early on in my career. Like I mentioned, getting thrown into SpaceX with 200 plus suppliers and technologies that I didn't have previous experience in was just figuring out how to have those conversations with people and learn.

So that's generally the first step of my leadership approach to any new situation that I'm plugged into—just spend time with the team, understand what they do. Sometimes I can probably get a little too into the weeds there because I'm a very detail-oriented person. And so after a while I have to kind of consciously tell myself, okay, you understand enough—pull out of the weeds and let's look at a little higher level strategy.

But I mean there's pros and cons to managing very technical teams too. Sometimes it's nice to be able to throw a very technical problem out there and have extremely technically skilled people that can problem solve and diagnose it. But sometimes engineers are really bad at categorically getting myopic focus on something and going down the rabbit hole to solve this little issue and kind of losing sight of the bigger picture. So I think there's benefits to managing some less technical teams as well because they can kind of take a step back and help me understand, hey, yeah, there's a system problem, but ultimately there's a philosophical difference that needs to be solved here. I'm reading the emails that this person's sending and I'm feeling that they're not bought into this path forward. And those are things that I think, as a more technical team and a more technical person, sometimes I don't naturally grasp.

So I've had a lot of positive experience working with less technical teams too, because it's taught me the importance of seeing the full picture and focusing on interdepartmental relationships and customer-supplier communication and all those types of things.

How do you handle pressure today versus like five years ago? Because I'd imagine, maybe five, seven, 10 years ago, but I'd imagine SpaceX and Elon is very different than SQA and your board and your owners. But at the same time, recognizing like you're ultimately responsible to some of the largest, most regulated companies in the world that while they might not be Elon or SpaceX, have very high expectations. And I'd imagine there's immense pressure in what you do. What's changed in the way that you handle that pressure going from employee to CEO?

Yeah, I mean, I think I am naturally wired to handle pressure pretty well. It actually kind of—my wife often comments on how she gets frustrated at the fact that things just don't seem to phase me. So I don't know, some of it is just, you know, I've learned to just take things one step at a time. And I think that applies to really any type of pressure you're under—you can't allow yourself to get overwhelmed. You have to just focus on the next problem in front of you that you can solve. And learn when to escalate, when to ask for help. Those types of things I think are really important.

But I'd say the biggest difference is probably the scope and the focus of the pressure. Under the Elon SpaceX environment, there was always a million different projects going on, but at the end of the day there was one goal and one company that we were working towards advancing. So I think that while the intensity of the pressure was extremely high because that's just kind of how Elon is and he sets goals and expectations that are borderline impossible at times.

I vividly remember when we were first unveiling the Dragon capsule—our first manned version of the Dragon capsule. SpaceX has been launching Dragon since 2010 as a test mission. They had cargo Dragon for years, and then we were coming out with basically the first one that was going to carry humans. I don't remember what year this was, but it was in like January, March somewhere in Q1, and our goal was to release it in October and have this big...

Unveiling event and right around that time was when the tensions with US and Russia really started to escalate. And at the time with the space shuttle retired, we were sole sourced with Russia as a nation to bring our astronauts to the space station. And so we had this kind of ten month timeline on releasing this Dragon capsule. Elon sends out an email and it's just like, "Hey, with the escalations between US and Russia, I want to make sure that the US knows we're ready for manned space flight. So you have thirty days to get it ready for unveiling." And it's funny because at SpaceX, it's just a giant bullpen, right? You know, low cubicles. You can see everybody across the entire room. Elon doesn't even have an office. He has a cubicle. But he sends out this email and I'm on the third floor and like everyone just stands up and is looking at each other like, "Wait, what?" And so it kicked off this thirty-day scramble. But we got it done. We had a mockup that we could unveil and show the world what Dragon was supposed to look like, and that continued to evolve dramatically between that point and when we actually launched the first one. But those are the types of deadlines and pressure that were just commonplace. It's just taking something that a normal company would take a decade—our deadline would be a year—and then halfway through it, that deadline would be pulled in sooner. You know, it's just constant, constant go.

Here, there's probably a little less of that. However, we still work with companies like SpaceX, so we get the flow down of those crazy requirements and deadline shifts. But I think the bigger challenge here is we have a hundred plus clients that all have their own critical path priorities and deadlines and things. So whereas that direct pressure isn't necessarily there, you have this big distributed pressure and it becomes really a prioritization challenge. And you know, we never want to let a client down. And so we have to really look at which of those deadlines are real and which ones are actually going to impact the client and how do we make sure that we're resourcing ourselves and prioritizing our teams appropriately to keep everyone focused on those goals so that we're keeping our clients' goals moving.

So we talk a lot about systems versus heroics on the show. You're relatively new to the CEO role. There's a lot in place. SQA is not a new company, and I'm going to put you a little bit on the spot here. When you took over SQA, what did you see that made you think, "This needs rewiring. This needs to be changed. We're going to fix this"?

Yeah, I'll start by saying I was very pleasantly surprised. So yes, SQA started in 1995. So we've been around for thirty years. I stepped in two and a half years ago, you know, so like twenty-seven years into this journey. It was founded and run by the same guy as CEO, Mike McKay, for twenty-seven plus years. And he and I are very, very different. And he'll be the first to admit that he is very much a relationship builder, sales guy. He's super good at reading people. I always describe him as the type of person that will go out to dinner with a stranger and he'll be like godfather of their children by the end of dinner. He's just really good at building those core relationships. So he's more like you and less like me.

Yeah, probably. But he's not technical at all, you know? He doesn't have any engineering background, just like me. And so when he first approached me to bring me in, and you know, just for context, I was for a while at SpaceX leading the source inspection program and some of our supplier assessment and approval and onboarding processes and things. So I worked very closely with SQA when I was a client, essentially, and that's how I got to know the team and got to know Mike, the former CEO, still owner and chairman of the company. But he approached me and was just like, "Hey, I love this company. I built it with my dad. You know, I really want to see it succeed, but I'm also at the point where I know it needs somebody other than me at the helm—someone that's going to bring a different approach because you know, he grew it from zero to where it was, which was extremely impressive when you look at the list of our clients all being some of the biggest names in pharma and aerospace and we're a relatively small company out of Palisades, California working in ninety countries all over the world every year. So I mean, that was him and the team that was here, and many of the people that I have on my team now have been at the company ten, fifteen, twenty plus years. Like, it's a very stable environment with people who really love this company. They love the culture. They love what we do. They understand how important our work is. And so I was blessed and pleasantly surprised when I stepped in and got a vibe for the overall team, the culture. Everyone's really bought in. They want to do the right thing and they're really hard workers and make sure that come hell or high water, we'll find a way to get it done.

And so I think, you know, at first I was kind of worried about what I'm stepping into here, you know, a young kid coming into this company where people have worked here longer than my entire career at other companies. And the team was very, very welcoming and open and ready for something new, which I think was great.

I think at the highest level, to answer your question of what I saw that needed to change—some of it was some team dynamic stuff. I think it was eye-opening to me. I had never been in an executive position, much less a CEO position before. And so I've always been used to just being able to throw my opinion out there in a meeting, be like, "Oh, I think this would be a good idea," and for the first couple of weeks here, I started to realize that once I threw my opinion out, people were like, "Okay, that's what we're going to do." And I was like, "Whoa, whoa, whoa. I'm new here. I don't know if that's a good idea or not. I was just stating that as an option. We should talk about it and we should evaluate the pros and cons. And if it's a dumb idea, you should tell me it's a dumb idea."

And has anyone told you that any of your ideas have been dumb ideas?

No one's used that word specifically. Yeah, at least to my face. Probably behind my back, right?

But no, I remember like a couple weeks in, one of our guys, Ed Snyder, who's been with the company for twenty plus years, and I worked with him when I was at SpaceX. He was the program manager for me, so we know each other well. But I kind of threw out an assumption in a meeting and he was like, "Actually, no, that's not true." And he gave me the data to show it wasn't. And I called a timeout. I was like, "Ed, thank you. Everyone, please do that if I'm wrong. Tell me." And so that's been, I think, one of the biggest things that I've been focusing on building over the last two and a half years here—this comfortability with conflict and the ability for the team to just debate openly and not hurt each other's feelings or feel like, "Oh, well, my idea got shot down, so that guy thinks I'm stupid or he's trying to make me feel bad." It's just like, no, the way for us to come up with the best idea is for all of us to argue for a little while and then see the pros and cons and weigh them and then choose a path forward.

So I think that's probably the biggest cultural change that I wanted to make, and I think we've made really awesome progress. And I think you guys even kind of pointed that out when you started talking with some of our team, seeing the dynamic of the meetings and things. I think hopefully that shows that we're on the right track there.

And then I think from a more technical perspective, we have really scaled this business model from zero to where we are now. And it's been a very siloed approach in many ways where client A has their team and client B has their team, but then each of those teams develops an entirely different process for doing the same thing. Could be source inspections at suppliers or supplier quality audits. But we've got so many different flavor variants of what we do now. So you have client A, B, C, and D that are all trying to do the same thing, but they're doing it in four different ways.

And so I think that's what we're working on now—trying to drive some standardization where we can and use best practices from all four of those clients to say, "Hey, actually, if we do it this way, we can schedule more efficiently or if we do this, we can get you data instantly instead of you having to wait for us to fill out your form and send it."

And so that's still a work in progress, but I think it's looking at where can we centralize some of those resources, create some synergies between different programs while still allowing that very customer-centric approach from a customer service perspective that made SQA so successful to begin with.

I love that, and it leads in really well to the next question because we were kind of talking about as we were engaging with SQA and go to market. This question comes from: how can go to market learn from quality?

So most go to market organizations only think about quality when something breaks. What should they be trying to do sooner? Because, you know, we originally had this conversation when we were together in Utah at an event, and as we start doing the work through the process and you've come in from a quality perspective, what can some of the go to market leaders do to get ahead of that so it's not breaking too late?

Yeah, I don't know that I have a great answer specifically on what can the go to market leaders do. I think at a more holistic level, when people think of quality, often they're thinking of probably a very small subset of quality. And to your point, talking about products breaking and things like that, that's the worst case scenario quality problem when you have an end customer that goes to use your thing and it doesn't work. So those are the ones that get the highest visibility and the most priority, justifiably so. But I think from working in manufacturing my whole career, there's so much throughout the process. And this goes for software and any other industry as well. But when you start to really drill in and look at the amount of rework loops that are happening throughout the entire design, pre-production, production, release process, there's so much opportunity to save money and time if you invest in controlling quality upfront and doing it right from the jump.

And that's where I think a lot of companies probably find that out a little too late—once they have a product that's out there and they're ready to scale—is when they run into all types of those issues. And I mean, that's something that the launch industry taught me pretty well: building one rocket is very hard. Building 50 rockets a year is hard in an entirely different way. And you have to transition this mindset from being like a science project into being a production company like a Ford or a Toyota or something like that.

And so the level of focus on the details you have to have—that's not always there from the beginning when it is kind of R&D startup mode. You have to get this mindset shift across all your engineering teams and everybody that's involved in the process to just realize that it's not okay for me to take five minutes every time I do that to redo something that somebody upstream didn't do right. And people learn to just live with those little things. They're like, "Oh, well, I found these parts that are super cheap because they're originally used for a remote control car, but they're like a pretty good motor, so I can use them in my rocket motor." But I have to sort through them and do all this testing. And I order a hundred and I throw 50 of them away and then I use the 50 that are good. But it works because overall it's like 1% of the cost if I were to buy this fancy aerospace grade motor. And like that works kind of well when you're in scrappy startup stage.

The problem is I can't guarantee that 50 out of 100 are always going to be good. So I may get one batch where 100 out of 100 are good and that's great. But then the next time zero out of 100 are good and now I'm delaying production because I don't have parts. And so I think that's probably the hardest shift that I think people have to understand and that I've seen as those companies grow and mature is like variability becomes really, really important. And minimizing that is almost more important than improving your yield to 100%. If I can have consistent yield of 80% every time, at least I can plan around that and I'm not going to let my customers down or cause unnecessary delays. But when my yield goes from 20 to 90% on any given day, I just can't plan my business around that.

And that's where I think a lot of the supply chain problems come in as well. If you're not really understanding that variability all the way through your supply chain, you're setting yourself up for surprises. And surprises are almost always bad.

Surprise always bad. Surprises are always bad. I agree.

All right, as we come up on time, let's go to some quasi rapid-fire questions. We're going to try to lighten the mood a little bit, but we'll see. Let's have some fun. Um, what in your mind is the one leadership skill you think took you the longest to develop?

Effective delegation. I think that was tough. Yeah. I think especially early on as I kind of started getting direct reports and things, I had this mindset of: "I know how to do this really well and you don't know how to do it as well. I could train you, but that's going to take me a lot of time and then you're still probably not going to do it the exact way I do it."

And as my scope grew, I came to finally realize, "Hey, somebody else spending 80% of their time on this is almost always going to be better than me spending 1% of my time on it." Um, and so I'm still working on developing that skill, but that was one of the harder ones for me.

Who's one leader you've learned the most from?

Yeah, this is an interesting one. So I actually hired him here. Wow. But, uh, yeah, former director of mine at SpaceX named Paul. And I actually worked for him at Rocket Lab as well. And then we worked together at a Heliogender company I was at before here. Um, we are very, very different. He's ex-British special forces. Very regimented, like just hardcore ops guy. And you know, we almost always approach problems from the exact opposite direction. Like my gut instinct is almost always the opposite of what his is. And I've learned from working with him over the years that it's great to have that counterbalance because my gut instinct is not right all the time and his isn't right all the time either. It's right a shocking amount of the time, I will admit. But it's been cool to now have him on my team and still, even though I'm his manager now, I'm still learning a ton from him because his natural style is just so different from mine.

I love it. What's your favorite guilty pleasure snack?

I'm not a huge snacker, but like, probably ice cream. I just—there's always room for ice cream. And especially anything like peanut butter chocolatey. That's always a go-to for me.

Last one as we wrap up: dream vacation destination.

Ooh, um, my wife and I travel a lot. We have two young kids now—a three-year-old and an eight-month-old. And we just got back from Europe for two and a half weeks, so that was an adventure. But one that's been on my list for a while is Patagonia. I'm a big hiker and outdoors guy and every time I see photos from there, I'm just like, "I gotta get down there." So that's probably top of my list.

I love it. I absolutely love it. Michael, thank you so much for joining the show. We appreciate it. It has been great chatting with you and talking about how we tie quality to go to market and to software.

Awesome. Thank you, Michael. You guys.