Being an Engineer
Being an Engineer
Robert States | How Engineers Can Thrive in Corporate R&D
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
Robert States is Vice President of Technical Services at Cormica Medical Device & Pharmaceutical Testing, where he supports clients across medical device, pharmaceutical, and combination product testing. His work spans development strategy, risk management, testing strategy, process development, supply chain optimization, and regulatory-minded technical problem solving. Cormica’s announcement of his appointment highlighted his role in strengthening global technical services across UK, US, and EU laboratories.
Before joining Cormica, Rob spent more than 20 years at Stress Engineering Services, where he held leadership roles across medical device and pharma, consumer products, strategic client engagement, and consulting. Stress Engineering’s medical and pharmaceutical practice focuses on product design, analysis, testing, failure analysis, material science, packaging, manufacturing support, reliability, and regulatory-grade engineering solutions—areas that align closely with Rob’s career-long focus on helping organizations solve difficult technical and business problems.
Rob’s technical foundation is in plastics engineering, supported by an MBA from Ashland University and a BS in Plastics Engineering from Penn State. Over his career, he has worked across companies including Procter & Gamble, Newell Brands, Stress Engineering Services, Accelitek, and now Cormica. His experience gives him a rare perspective that bridges hands-on engineering, product development, failure remediation, consulting, business strategy, and executive-level technical leadership.
A central theme of this conversation is how engineers can thrive in corporate R&D environments. Rob wants to explore the intersection of budgeting, project success, layoffs, and business performance—and how engineers can use that understanding to make better decisions, protect their careers, and create more value for their organizations. Rather than treating corporate realities as distractions from engineering, Rob sees them as forces engineers can learn to understand and navigate.
LINKS:
Robert States LinkedIn: https://www.linkedin.com/in/plasticpro/
Cormica Website: https://www.cormica.com/
Aaron Moncur, host
PDX 2026 is October 20-21 in Phoenix, AZ. Learn more and register at https://pdexpo.engineer/
Subscribe to the show to get notified so you don't miss new episodes every Friday.
The Being An Engineer podcast is brought to you by Pipeline Design & Engineering. Pipeline partners with medical & other device engineering teams who need turnkey equipment like cycle test machines, custom test fixtures, automation equipment, assembly jigs, inspection stations and more. You can find us at www.teampipeline.us
Watch the show on YouTube: www.youtube.com/@TeamPipelineus
startup R&D people, first off, they probably don't like structure and, um, and they like the freedom, and they like the freedom to think, and they just… They really are not caught up in process at all. They just wanna get it done. And when you get into big corporations, they're managing risk and, you know, they're risk management companies, whether-- whatever it says on the door, that's really what they are, is risk management companies.
Aaron Moncur:Hello, and welcome to the Being an Engineer podcast. Today, we've got Rob States coming back to us, who is wearing two hats as a founder and owner of AccelaTech, a management consulting firm, and vice president of technical services at Cormica Medical Device and Pharmaceutical Testing. With a background in plastics engineering, an MBA, and more than two decades across product development, testing, consulting, and technical leadership, Rob brings a practical perspective on how engineers can thrive in corporate R&D by understanding the connection between budgets, project success, staffing choices, and business performance. Rob, thanks for being with us on the show.
Rob States:Uh, great to be back. Thank you
Aaron Moncur:Yeah. This is, uh, round number two for Rob. So if you haven't heard his first episode, be sure and go through the archives and find, find that one. Today we're, we're gonna have, uh, a conversation that is loosely focused on this idea of how engineers can thrive in corporate R&D environments, and understanding budgets and, and staffing choices and business performance, things like that. And I feel like Rob is particularly well-suited to this conversation more than maybe any other engineer I've gotten to know over the years, and Rob and I have connected for, for several years at this point. He really has a keen understanding of the business of engineering and, and not just the business, but the, the macroeconomics of engineering. He, he always seems to have a finger on the pulse of where the industry is, who's hiring, who's not, who's got money, who doesn't, and that's, that's kind of a, a, a unique knowledge base that I just don't find in, in other engineers. Rob, may- maybe we start there. What, what got you interested in kind of like the behind-the-scenes, um, macroeconomics of engineering?
Rob States:Yeah. Engineers always wanna figure out why stuff works and, and, and of course, that's why I ended up in an engineering career. But beyond that, um, you know, I, I came in previously in a partnership model where you had to go off and build your own business, and I really wanted to understand why people bought and sold. so I s- would… You know, I was always just going off throwing, you know, spaghetti at the wall to see what would stick. started zeroing into why would they buy this and not buy this? And then why would this corporation with, you know, oodles of talent and equipment and money, why would they outsource these kind of tasks? So I spent a lot of time understanding that nuance and understanding the value in the market. And, you know, that's where it just then it parlayed into my curiosity just kept me going and, and digging into this, and then forming friendships with other services firms, understanding what made them tick, and then spending a lot of time with doing voice of customer activities with clients, and then really understand the value that you can provide to them and why services companies needed to exist versus what corporate R&D would do
Aaron Moncur:Yeah. Um, uh, help me define the difference between corporate R&D and, like, a startup R&D environment. What's the difference?
Rob States:Oh, there's a big difference. Um, startup R&D people, first off, they probably don't like structure and, um, and they like the freedom, and they like the freedom to think, and they just… They really are not caught up in process at all. They just wanna get it done. And when you get into big corporations, they're managing risk and, you know, they're risk management companies, whether-- whatever it says on the door, that's really what they are, is risk management companies. they're managing risk all the time. So they have all these procedures in place and all these different parts of the organization, you know, regulatory, quality, R&D, operations, and they all operate in their silos, where if you go to a startup, you wear 16 hats, guaranteed. And, and, and, uh, what I find is, is that startups are actually, because they're uninhibited, a lot better at innovation, and the big corporations are the lot more corp-- uh, lot more capable at scaling, getting stuff across the finish line at the reliability levels they need. They're not generally good at innovation. If you look, they generally buy it. Um, you know, uh, where the, the startup people are the, the, the innovative types here, and those worlds sometimes merge when, you know, someone grows a company, then sells it
Aaron Moncur:It makes sense that a startup might not be, um, immediately effective at taking something across the finish line, especially at scale and at a high level of, of quality and consistency just by the nature of what a startup is. But why, why do you think corporations, larger companies out there, why can't they be innovative like startups?
Rob States:Um, because they're busy following a process, you know. And I-- And that may-- That's not good or bad, that's just who they are. You know, there was, um-- I'm just taking some lessons from the services world and reapplying it. So there was, there was these, these books out here, and they talk about like services firms, and there's three kinds of services firms generally. It's like expertise, gray hairs, and process-oriented, right? So firms, you know, that are expertise in gray hair offer something different than firms that are process-oriented. Organizations follow process. They value process a lot. And when you value process, it sort of cuts off the tails. When you cut off the tails, that's where the innovation is, right? It-- That's not perfectly true a hundred percent of the time, but I'm gonna say companies are more likely to give you another flavor of what they do or another s- or another revision of what they do than they are to create something new. It's very hard to create something new. And so just have the horsepower to get it across the finish line, really understand reliability, really under supply-- understand supply chain, know how to sell it, know how to get it to volume, know how to get it through the regulatory pathways. where they're strong. Innovation, they wanna do it, but I mean, they struggle
Aaron Moncur:You mentioned earlier that, uh, a lot of these corporations, no matter what it says on the door, they're, they're really risk mitigation companies, which is an interesting way to, to think about it. And you have an interesting way of thinking about a lot of things. Uh, another idea that you have or, or a principle is the idea of this, the quote unquote real contract between an employee and, and the company, uh, especially in an R&D environment. What, what do you mean when you say the real contract between the company and the employee?
Rob States:Well, you see it, you know, in the layoffs, and I've seen it throughout my career, and I've been trying to understand, um, you know, 'cause you value individuals and you, you go to work for these big corporations, and I've done it and, you know, and I've enjoyed it and I've got a lot out of it. They are super focused on the process, whether they tell you that or not. Your managers may be super focused on you, but the company's focused on the process. And so when they're focused on the process, they're gonna get that through. They're bringing people in and running them through that process and developing over a, a period of time If you think they're hiring you because you stand out technically or you're smart, you're gonna be disappointed because they are-- the ability to hire smart people is common. They are all over the place. I run across them all the time. There's so much wonderful talent out there. And so they, they really value people they can put in their system and run it through, and they're gonna manage those costs accordingly. And then once you've been there long enough, they're gonna say,"Hey, we've had enough," and they're gonna bring in people behind that. That's not a bad thing. you know that, you should act accordingly. I think there's a real opportunity. If you wanna stand out in an organization, you need to develop your own brand in parallel, and your brand has to be able to ha-- go after the same thing that the company's going after. So if you're gonna go be, you know, an expert in robotics, go tell the world, go get on committees that are gonna work on the controls. Go on committees that are gonna work on human factors, whatever it is, and start developing your brand simultaneously. The c-company wants you to do it because they need to be involved, but also build your brand simultaneously that you are now insulated from any decision that that company ever makes because you have now developed a brand that has value. so if you go into your employment doing that, you're gonna be great. If you go in and just ask them, "What should I do next? What should I do next? You know, how do I get to the next level? How do I get to the next level?" You can have a long, wonderful career, but the odds are not in your favor you get to choose the end
Aaron Moncur:That's really smart advice. I know as, uh, a small business owner myself, when I see that a team member at Pipeline is aligned with helping, helping me… I guess for me it, it kind of comes down to personally me since we're such a small company. But, uh, my focus is keeping the machine going, right? Making sure the machine is fed. We have enough work for everyone to do. The, the families that, that work here are all supported and fed. At the end of the day, that's really what, what my focus is. So when I see a team member who, who gets that and is helping, not just do great engineering work, but, but helping the business perform well, I will never get rid of that team member, right? That's someone who's gonna be here for good a- a- a- as long as they're willing to be here, right? How, how often do you think engineers forget that and confuse success with, uh, simply exceptional technical performance?
Rob States:Uh, so I wanna compare and contrast a few things about, you know, working for, let's say, you versus a large corporation,
Aaron Moncur:Yeah
Rob States:Um, you know, I'm in the space where, where I'm in private equity, and it's very common that we buy founder-led firms, and our job is to convert them from a founder-led firm to a small cap. And that, that's a very interesting play. What I find about these people that you value, they're wonderful people, and you definitely want them part of the team. But they don't have a lot of reps maybe at making the decisions. And so sometimes they, they have a hard time in this environment where they're now part of a small cap, right? And there's nothing wrong with that, but that's, that's-- I've seen that behavior, so I spent a lot of time helping them transition through that to, to be successful. In big corporations, they might not ever experience something like that. They just would have no idea. and a lot of times they think that they're the most important part, mo-- cog in the wheel because you know what? Everything has to go through me because I'm the, the, the technical person. Um, that's not how they view it at the top. How they view it at the top is, how are you helping me get there fast? And they're-- and they actually the engineering as a given. I've seen that a lot. It's just a given that's gonna happen. And it, it's largely because the decision makers may not understand the technical aspect of it. It's, it's actually a nuance to them that they don't understand. It's hard for non-technical people to work with technical people and lead them 'cause they, they don't understand the nuance. But when you and I are in the details, right, we're paying attention to a lot of details, and we know that these small things really matter. it takes a long time to develop that perspective
Aaron Moncur:Yeah. Um, so in, in a, a larger corporate environment At Pipeline, again, we're very different, right? Small company here. Um, we don't have budgeting seasons, right? W- we don't really define a, an annual budget. Maybe we should. You know, that's a conversation for another time, but we really don't. I mean, loosely, of course, we have project budgets, right? When there's a project, we quote a qu- a customer, there's a specific budget in place. Of course, for a project that, that's true. But, you know, generally for the business, we don't really go through formal budgeting seasons. But larger corporations do, and you have some unique perspective and insight into what's really going on behind the scenes when, when budgeting season comes around. What are some of the decisions and conversations that leadership is having that maybe the engineers don't really see or, or, or appreciate?
Rob States:Yeah. I mean, I, I, I got a dose of this a few years ago when, you know, we just had this… There's been a lot of layoffs in med tech and pharma in the last, you know, couple years. And I saw something recently that just got my attention where the client's organization, say it's a larger company, they, managed, uh, their headcount reduction via-- They looked at their portfolio projects across their enterprise. And if there was, let's just say there was 15 major projects going on, they just looked at the three lagging ones, and that's-- And all those people from the VP down to the person who started two weeks ago were let go. And it was pretty indiscriminate because somewhere in that line, you could have people that were the best in the company, but it was, they really didn't care because I think the legalese gets in the way. I, I, I stepped back and looked at that and I go, "Oh my gosh, the, the, the budgeting process for projects is a zero-sum game." If you have really good people but it's underfunded, you could end up one of those three out of 15 that are at the bottom and then, you know, you get cut. And you have no idea You know, from a certain level down, director level down, maybe, you know, associate director, depending on how they're structured, you have no idea. You're coming to work every day, you know, doing your best, and you just happen to be caught up in a project that just had maybe poor leadership at the top or not sufficient budget, and you're out. And so you just have to accept that that's what's gonna happen, right? And ideally, the luck of the draw, this doesn't happen to you for a long time, and you can build your brand simultaneously. But what you see with technical people, particularly engineers, the unemployment rate is like one or 2%. I've never seen any of them not land on their feet, go somewhere else, and just be successful, right? And so just know that's g- it's just a disruption in your life. Uh, but you're-- if you know it could happen and you're prepared and you're building your brand, you might be surprised what happens when you move on to the next role
Aaron Moncur:Let's talk about that a little more, building your personal brand. So you talked about how corporations are-- they're really misc-- risk mitigation, uh, companies or, or organizations. And I, I think the same should be true to some extent for the individual as well, right? You, you should be mitigating risk for yourself. And like you just said, there might be situations in which you just don't have visibility to what's really happening, the conversations going on at the top, and those conversations may greatly impact your, your future, right? Near term anyway. You might get let go. The whole division might get shut down. And doesn't matter how good you are or how well you're performing, y-you might just find yourself out of luck in that situation. So what can engineers can do? What are a, a few practical suggestions that you have that engineers can, can use to build their personal brand so that if the unfortunate thing should happen, they get let go, um, they can get back on their feet as quickly as possible?
Rob States:Yeah, I'll start with some extremes. I've seen, uh, folks that were prolific in their organization, very much the face of the organization to the rest of the world, whether in industry groups or whatever it is. You know, ISO committees, AST committees, or, you know, conferences or industry conferences, everybody knew who they were. Those people, whether they did it with intention or not, built their own brand, and I've watched them then leave or retire, and they just get sucked into all these other organizations. I talk to them, and they, they're like,"I had no idea." you know, but there's, there's a, you know, there's a basically a case study on, you know, what you should do, whatever is your lane, right? First thing, my advice to anybody is only do what you're good at. You know, you know, quit being something else. Don't emulate me or emulate you if that's not who you are. Be who you are, find your lane, and then go. And then go-- And there, and then, like, if you can't find a lane, then you picked the wrong career, right? You know, it's like just, you know, there's, there's something there for you. And then be focused on what is the value, right? I've, I've been, you know, in services a long time, had, you know, over $100 million go across my desk where people had to spend money. So I understand value, right? And you've had money come across your desk. You know where the value is, right? time on that. If you can understand the value of what's being done by your organization and what, and what the value is in the market, out there and be the leader of it. And oh, by the way, that company wants you to do it. Like, they want you to do it. Go do it
Aaron Moncur:It's, it's a little bit sad in a way that engineers go through all this training, right? We're excited to be technical. We're excited to be technical problem-solvers, use CAD, you know, prototype things, assemble things, test things, all these things that we, we kind of think of as being an engineer. And, and that's great and for sure necessary, right? Um, but then there's this other layer, the, the, the financial layer, the business layer. And oftentimes I think that engineers, a- and to no fault of their own, because they were never trained like this, and no one ever took them aside and said,"Hey, listen, like, at the end of the day, this is kind of what really matters." But they don't tie their efforts, their technical efforts, to the, the financial outcome, the business performance of, of the company, right? And i- sometimes you get let go anyway, because like you talked about, you know, an entire division might get shut down no matter how good you are, no matter how well you understand the connection between your performance and the business goals. But, uh, there, there are probably other situations where you can save yourself. Do you have any advice for engineers on, on how to go about connecting those dots between what they're-- the technical problems they are solving and how they affect the bottom line of the company a- and also how to, how to market yourself, right? Y- you might, you might understand the connection and know that you understand it, but if your leadership doesn't know that you understand it, well, you might as well not understand it.
Rob States:So one of the things that I had to personally focus on, you know, and through the, these trials of, you know, you know, going on 20 some years tw- of consulting is that I had, uh… One day it just dawned on me, 'cause I worked for the biggest companies in the world with the biggest budget in the world, the most talented people and everything they want. 100% of the clients had problems on 100% of the projects, right? And I could just tell you that's the case. And so I then viewed, I then went after what is the highest value thing I could do to help them with that? And I went after that. And I would just tell anybody they need to go after the highest value thing from the thing, the perspective that they see. So I see this, and so I then focused on big… I'm a technical person, I'm still fal- solving technical problems, but I went and focused on bigger technical problems, and I solved them. And the other thing is, here's a little secret to all of it. There's a pattern to it almost always. So if you recognize the pattern, you will see it faster than your clients will or the people around you. You can be-- You can start predicting it. You can get the nickname Nostradamus in your organization Be that person, right? That's just one lane. But, you know, it probably took me 20 years to figure that out, right? But if, if you-- I had to find it out the hard way, and I'm just bouncing off of walls, and then it dawned on me one day. But I wish I would've known what I know now, you know, 15 years ago. It would've been a lot more effective, right? But go seek out that niche-y thing allows you to be an engineer where you can monetize it and it has value in the market. And then, uh, you know, I can then tell you all about that. So I go, I just go talk to senior leadership now. You know, every-- You know, when I first started going off talking to people, I'd have a PowerPoint and this and that, and like, do that anymore. I basically tell them what's about to happen and how I know. And what the… You know, the interesting part is, is, of course, I got a lot of reps at this now, is they start telling me their stories that match what I'm telling them. And at that point, know, you are aligned with their needs.
And then I s- they start asking me:"Well, well, what would you do?" And I start making suggestions to them, and that's how you-- then you, you build this career and this demand of your own brand, whatever it happens to be, and then you go down that road
Aaron Moncur:I wonder, is there a specific story or example that you could share in your own life that illustrates that point where you were able to identify some kind of pattern or that, that niche thing that really moved the needle for the company?
Rob States:Oh, right. Uh, it-- this one is very universal, and I talk to clients about this a lot. You're gonna go endeavor to do this new whatever, and it's a big corporation, so they don't do small things. I just ask them, "How many decisions are gonna be made in this project?" You know, let's just say it's 10,000. So 10,000. How many are you gonna get right the first time? If you're really, really, really good, maybe 8,000 And most people are not that good. You got 2,000 that are not gonna be right, and that's for a variety of reasons. That's not because someone made a mistake. Maybe there's a tariff, maybe there's a hurricane, you know, maybe there's a new regulation. There's something, right?'Cause these go on over time. Of those 2,000 remaining, you know, uh, 1,000 of them you probably could solve in an hour or less But just recognize, you know, when you live in the services world, that equals a half a effort here The next 500 you could probably solve in a week or less But that's a long time The next hundred will take a month. You get down to the last fifty, and that's twenty to forty percent of your time and budget. And right there, they stop me, and they tell me all their stories. As engineers, we go into it thinking that's never gonna happen again. That's a one-off. But I see it every day. And so the way that you impact them is that you talk to them about what is your strategy around recovery? You know, and so for the engineers that are listening to this who are thinking about their career If you turn yourself into the hero on projects, you win. Go be the hero. The hero is knowing how to recover fast. The hero is not about being the best at the design because that design will have problems. And so, you know, I might have a b-biased point of view, but I'm just telling you, like, there's an infinite appetite for that
Aaron Moncur:Yeah, there, there are a lot of engineers out there who are technically very good at what they do, but there are not very many engineers out there who are both technically savvy and business savvy who can do both of those things. And those people are rare and very valuable. So to the extent that you can become one of those people, you're, you're set. You're kind of set for your career. Um, going back to, to R&D, uh, especially in corporate sit- environments, you, you mentioned, uh, you know, sometimes there might be 15 different, uh, uh, programs going across, uh, a, a company's portfolio and, and maybe three are underperforming and just get cut. What, what are some of the common reasons why an R&D program might get cut?
Rob States:Uh, because they didn't recover fast enough. They had-- See, they, they discover problems often in a serial manner. And, you know, when I get a phone call to go help a client, you know, and they're, they're late and over budget and it's not working, you know, it's funny as I'll-- you know, you meet with the team and I ha- like, it, it's, it's sort of a trick question, not intentionally, but I'll ask them, "Well, when's the last time you discovered something new?" And they'll enthusiastically tell you, like, yesterday. Because they're like, "Oh, look what this magic engineering I did," and blah, blah, blah, right? Okay, great. And I said, "Are you done discovering problems?" And oh yeah, that's the last one. Now it's-- Right. The me- the meantime be- between discovery needs to be about this long, you know, in order to say that you're near and done. And, and so the, the, the problem that a lot of people do is they solve it in a serial manner. I go in assuming they're never solved, and how am I managing this risk? And then how are you pressure testing these? Because, you know, they'll go… You know, there's a lot of momentum in a project'cause they'll go sit in a design review. So, you know, you know, working in services, I think in hours, right? That's my universal currency is hours. And okay, I went and may have to do these 10,000 decisions and, um, you know, I don't know, each one took, you know, 10 hours or something. You know, so there's 100,000 hours into this, right?'Cause these are big projects. you're like-- And then you get, you know, you sit in a design review for one hour with, you know, six experts. You, you, you, you can't keep up, right? And then I-- A lot of times I'm dealing with, you know, issues in late-stage development, either pre or just immediately past launch, they start scaling up. the problems that get the clients are often three sigma and four sigma and five sigma events.
Aaron Moncur:These edge cases
Rob States:that's what grinds everything to a halt, you know. And they discover that way too late Good companies don't do that
Aaron Moncur:Okay, so what you're saying is that one of the primary reasons that R&D programs can get shut down is because they don't have the internal capability to recover fast enough. So if you're an engineer and
Rob States:often very capable. Let me interrupt you. They're very capable, the problem is they're discovering in a serial manner and they don't retire risk fast enough, and then they basically run out of time and that they just get yanked
Aaron Moncur:Yeah, yeah. Th-they don't recover fast enough anyway. If you're an engineer working in an R&D environment and you want to make sure you're mitigating risk for yourself and your own career, what are some of those telltale signs? You know, how do you know if you're not recovering fast enough? Or, or are there other signs or patterns that you should be looking out for as indications that, hey, this program might be in danger, and I might need to start thinking about what's next for me?
Rob States:Oh. If there's a lot of rework loops, a bad sign. Um, and you know, if you keep on going back, that, that's a bad sign. If you're not seeing enough risk be-- you know, you haven't-- you're not identifying the risk early on, and you're discovering, you know, the methodology is discovered in a certain manner but not try to, try to seek it out fast and have alternative pathways identified early on, it's a problem, right? You know, here's a telltale sign for me. I'll ask them, like, "What is the reliability of this device?" If they can't tell me what it is right-- If everybody in the organization can't tell me it is off the tip of their tongue, I already sort of know they're in trouble. The next thing is, is that, you know, I'm gonna just say, "Well, what is the reliability?" "Well, we'll find out when we test." Ooh, you're in trouble, right? You know, you don't hear that a lot, but on occasion, right? Or they'll tell me what it is, but they'll say, "We'll verify that in testing." Oh, that's a, that's a problem because that's-- you're getting to late stage. Everything's being built up and you're going, right? Really good people have reliability models on day one The first thing I do on a complex program is I go build a reliability model, and I then bring in people who have been there and done that
and tell me:What can these be? then identify those risks, and then, you know, then you send a team off to fill in the-- 'Cause at, at first it's a, you know, it's an educated guess, right? Or, you know, it's been there, done that. but then I send the team off.
They're like:We need to get these numbers in a hurry, and I need to know this fast. If they come back and they can't start hitting the numbers from an engineering perspective, then advising the team, "You need to have a plan B or pivot right now," right? a lot of times they just, you know, it's like the end of the movie of "Dumb and Dumber," "So you're saying there's a chance?" So they wanna go off and go do it again, and they wanna go do it again. those, you know, maybe they can find an answer, but rarely, right? And so when they're saying,"Well, I just need one more. I just need one more." Right? If you don't know the outcome of what you're about to do, at that point, you know, it's like the odds are not in your favor.
Aaron Moncur:Yeah
Rob States:where you see things get really and specifications get tighter and, you know, there's a lot of OEE problems, you know, are very low when they're launching. It's just, it's, it's just not robust
Aaron Moncur:Hmm. Yes. May the odds be ever in your favor. Brings to mind a, a ominous voice from a movie. Um, uh, let's see. I had a, a thought here. What was it? Oh, right. So what, in your experience, leads a product to be a commercial success versus other projects that might be technically successful but not so commercially?
Rob States:Oh, it got it across the finish line. I it's the-- particularly with the big corporations, it is nobody gets across the finish line with extra gas in the tank. They're all wore out. And, know, and, and, and so I think that they, they, they basically, they-- the-- they caught lightning in a jar on a few things. They, they, they got-- they were able to recover fast enough or-- and they were able to get it to go through. But this is where the big corporations sort of shine because if you watch the pattern, all of a sudden it's gone up the ladder, right? You now there's a daily call with whoever at the, you know, the very senior level. You then see-- because the projects have project teams. Even though I work for a company ABC, I'm only… That has a hundred thousand employees, I'm on project team with thirty people, Even though there's another hundred thousand somewhere else, you only got that. But when a push comes to shove, what they can do is they can summon another two hundred people, experts in the company, and they come on that project and they get it done. That's what happens, right? I, I've seen that more often than not. In addition to that, that's when they start calling the consultants, right? right. You know, you-- they, they bring-- Because remember, you're making those ten thousand decisions. Well, every decision wasn't made by an expert. And, and if you did make every decision by an expert, the project would take too long. You just can't do it. It would-- You, you just-- It, it would never get done. so there's a lot of heuristics and things like that to go into the decision-making process. so there's a tad better luck on these. You know, there's the resources of the corporation to push these through. They start peppering talent, you know, where needed, and they just get all these things across the finish line. That's what happens
Aaron Moncur:So it sounds like you're saying maybe not 100% of the time, but a large portion of the time, the projects and the products that end up being commercial successes were such because the company had enough resources to just throw more people at it, throw more money at it, throw more experts at it, as opposed to,
Rob States:game, right? It's that
Aaron Moncur:yeah
Rob States:game, right? If your project doesn't have the money and resources
Aaron Moncur:Yeah. Either everyone works late or bye-bye
Rob States:Right. There's a lot of that
Aaron Moncur:For engineers listening to this who went through the, the traditional engineering, uh, education, right? Four-year university, bachelor's or a master's, or heaven forbid, a PhD in engineering, what, what are some of the things that they didn't learn at school, especially around the subjects of budget and finance and, um, uh, commercial KPIs that, that they should really go out and intentionally learn?
Rob States:They should know the value of their work. I'm gonna do a simple thing. I need directions from Cincinnati to where you're at in Arizona, right? If I give you turn by turn with every landmark in between, gonna be a, bigger, lar- that's a larger, um, effort compared to if I'm saying, you know, 71 to 80 to whatever, to whatever, and you get there. Both those answers are correct They're both correct. Sometimes they just need to know if I needed to turn left and right. So if you give them this whole thing here, that, that was value not, uh, realized. And so I-- with engineers, you have to understand the value of what you're doing. you know, as a service provider, what I really had to learn to get, you know, to get the clients to spend money with you and provide value to them is I had to know when did I have to go deep and when did I have to just tell them turn left or right And clients need it all, right? So if you're, if you're a highly technical person, you're going deep on these things here all the time. But the value is I just need to know left or right, gonna miss. And, and if you give them a left or right and call it in, but they needed more details, you're gonna miss. Hone that skill to understand the value of the work that you're providing
Aaron Moncur:When it comes to things like, yeah, I don't know, y- you get an MBA and you learn about finance, right? You learn about revenue. You, you learn about gross margins and net income and things like that. Uh, are, are there some basic, um, let's, let's call them MBA principles that, that you should understand as an engineer to, to really understand what's going on with your project from, from a, a commercial success standpoint?
Rob States:Um, you know, if the company is on a no-fail mission, they're gonna throw all the resources at it, and so learn to be the hero because you can make it in your… You mean, 'cause winning on a big project will accelerate your career in the organization. Um, And so I, I think that's part of it. But again, go back to understand the value of the decision you're making at the time. And I think I, I've run across really talented individuals and client organizations, particularly when you're dealing with problems, and they start telling me about three layers of deep on a nuance that, I've, I've done 100 fail… or excuse me, 1,000 failure projects and it's never been the solution. It's never that deep. And, you know, and so they then are-- They get frustrated 'cause no one's listening to them. They're demonstrating technical excellence to you, but, everybody, you know, I, I'm listening to it and, you know, I'm being nice about it, but I'm like, "That's not it." And they don't understand that value, And so… But it's also hard because I, I have an unfair advantage. I, I-- and I'm sufficiently paranoid. I've seen it, right? And that's the value that I offer that they haven't seen it before. So, and then they, they go down these trails and then, you know, take it a step further about technical people. I have a problem and I take it and I set it on the table and I to my colleagues or the clients, and I talk to the design guy, and the design tell-- guy tells me it's a design problem. I talk to the materials person, and that person tells me it's a material problem. I talk to the ops person, it's being made wrong. Then you go talk to the human factors person, "Oh, they're just using it wrong," right? Who's right? Right? the answer is they're probably all correct. But the smart one, the one that will advance, is the one that knows h- which one to pull on that gets you to the answer the fastest with the least amount of changes to get it to market.
Aaron Moncur:Yeah. Right
Rob States:And if you can do that, you're way ahead, and you understand that there's this rest of the world working around the niche that you work in, and you understand how you fit into the ecosystem, whether it's the technical ecosystem or the business ecosystem. Because, you know, 'cause in the end, imagine you have this passion that it's this, and that answer could be true, but that creates a regulatory barrier to get it through, don't appreciate that, you're gonna end up frustrated
Aaron Moncur:Yeah. Yep. Great point. Okay, well, I think we'll wrap this up here. Um, what is something that you are working on, Rob, that you could use some help from the audience on? Maybe it's a, a technical question, maybe it's a, a person that you're trying to meet or, or technology that you're trying to ba- bring up, but there are, um, a lot of engineers listening to this episode right now. So what, w- uh, for, for those listening, what is something that you hope they could reach out to you and help you with?
Rob States:I, I have this, this vision that in the future that specifications will no longer be on a piece of paper, but a digital model And, you know, I, I talk to a lot of people about it, and there's, there's a lot of interest in it, but there are big barriers to getting it done. Most people are not willing to risk their career on it, and I get it because the, the system is built around the way it's built today, and if you were a maverick and you don't get it right, it's gonna be a problem
Aaron Moncur:Now, are, are you referring to what is commonly called model-based definition or something different?
Rob States:Uh, what I, what I would really like to see is a, a digital model is a physics-based model of whatever this device is. Let's just say, for example, I'll use an auto-injector. And everybody puts all these specifications together about how the plunger fits in the barrel and what the spring forces are and what, you know, activation forces are, and those are all fine. Um, but I have this perspective from dealing with a lot of failures. The first thing I do is I build a model, and then I figure out why it failed. And why am I waiting for it to fail to build the model? Uh, what I really like to do is have a virtual model every device that where you get the unique constituent components that you then build into a surrogate model that you fire at the end of the line virtually and know that in fact it's gonna be safe on a high reliability device So I like to-- the release criteria that it passes a digital model at the end, whether it's a physics-based model, whatever it is. That's, that's where I wanna go. And so what I'm looking for is like-minded people that are looking to accomplish that.
Aaron Moncur:Okay.
Rob States:And,
Aaron Moncur:like, like,
Rob States:around it
Aaron Moncur:like next level simulation. Not, not just simple FEA or CFD, but, but something a more advanced that takes into account all the different components at the same time, and maybe even assem- things like assembly. Uh, what's the word I'm looking for? Assembly process and variation in that process. Is, is that what you're referring to?
Rob States:Yes, right. And, and ba- basically the specification is it passes the digital model
Aaron Moncur:Yeah
Rob States:Right? And then you maintain that, right? And then there's more and more that can go from there because you can build deterministic models, and then you have things like, you know, these machine learning tools and things like that where you can start building stochastic models. And I have this desire to predict recalls. And the thesis that I will put out there is, is that when the deterministic models and the stochastic models deviate the probability of a recall goes up because the number one reason I don't know why something works is because I didn't know I needed to know that. And if I can force myself to know things There's an opportunity. And I think it'll transform, know, how companies work in these silos from oper- R&D to operations, right? And, you know, they hand stuff over, they shake hands, and then they say, "I'll see you on the next one," and then they both mumble under their breath as they walk away. you know, it doesn't need to be like that, I wanna find people that wanna change that
Aaron Moncur:We did a project recently. This was a, an automated machine that we built for assembly, and the company that came to us did so because there were errors in the manual process. It was, uh, it was an assembly operation with some small parts that were intricate and, and, um, and the operators, the, uh, operators' defense, difficult to work with, right? They're under a microscope looking at these things, trying to put them together. And there were problems, and they didn't catch those problems until the end of the line when all the value had been put into this product. So they came back and said, "Okay, we need to build a machine and just automate this so it happens the same way every time." Which, which we did, and it's working great. Um, but they spent, you know, whatever it was, six, eight, 10 months before they learned that it was a problem assembling these parts manually. And if they had had a model like you're telling-- talking about, right? Physics-based model that took into account operator error and process deviations, then they, they presumably could have saved whatever that time was, six, eight, 10 months. They still would have had to build an expensive machine, but they would have done it, you know, that much earlier. So I can see the value of, uh, a model like that that you're talking about. Great. Well, anyone listening to this, if you're interested in, in developing something li-like that or working with Rob on it, please reach out. Which brings me to the last question of the interview. What is the best way for people to get ahold of you, Rob?
Rob States:Uh, yeah, I'm prolific on LinkedIn. They can reach out to me on LinkedIn. I really appreciate the time here. And I would just point out, you fit the pattern with the description of that project, you know, and, uh, the… Yeah, it's, it's a very common problem, right? So
Aaron Moncur:Yeah
Rob States:that together and, you know, and yeah, I can be reached on LinkedIn anytime
Aaron Moncur:Wonderful. Wonderful. Rob, thank you so much. Uh, appreciate all the insight. Always a pleasure to talk with you. And is there anything else that you'd like to go over before we sign off today?
Rob States:Uh, no, let's do this again in four more years
Aaron Moncur:All right. Sounds, that's about the, the right cadence, yeah. Okay, Rob, thanks again so much
Rob States:Take care. Thank you
