S7E19 Ryan Schoonmaker | How to Take A Structured Approach to Solving Engineering Problems

Ryan Schoonmaker has spent roughly two decades in medical device product development, building a career around solving hard engineering problems in high-stakes environments. Today he is the founder of Tight Line Solutions, where he works with growth-stage product development teams to reduce chaos, improve execution, and build the kind of systems that make technical organizations more efficient and predictable. His messaging consistently emphasizes that innovation is not just about ideas, but about disciplined execution, sound principles, and the ability to lead teams through complexity. 

Before launching Tight Line Solutions in late 2025, Ryan served as Director of Mechanical Engineering at Beta Bionics. Prior to that, he held senior R&D leadership positions at BD and spent more than seven years at Dexcom, progressing from Staff Mechanical Engineer to Director of Mechanical R&D. His background also includes product development work at Safety Syringes and Helbling Precision Engineering, where he worked on drug delivery systems, insulin-related devices, infusion sets, and other life science technologies. That combination of consulting, hands-on engineering, and executive leadership gives him a rare view across the full arc of product development.

One of the most compelling parts of Ryan’s story is that his work has touched products with enormous real-world impact. In his own words, helping bring the Dexcom G6 and G7 to market reinforced the lesson that meaningful innovation requires structure, rigor, and strong execution. Public patent records also show his name on multiple Dexcom-related design patents, reflecting direct involvement in device development. He pairs that technical depth with a strong focus on team culture, communication, and breaking large problems into manageable pieces—exactly the kind of perspective that resonates with engineers trying to grow into stronger technical leaders. 

Ryan also brings a strong academic foundation in mechanical engineering, with a B.S. from the University of Maryland and an M.S. from Tufts University, where his thesis focused on vibrotactile feedback in minimally invasive surgery. That blend of technical depth, medical device experience, and leadership philosophy should make for a rich conversation on product development, risk mitigation, engineering culture, and what it takes to build products that truly matter.

LINKS:

Guest LinkedIn: https://www.linkedin.com/in/ryan-schoonmaker-59048411/

Guest website: https://www.linkedin.com/company/tight-line-solutions/

Aaron Moncur, host

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 

Transcript

Ryan Schoonmaker: 0:00

I think a big, a big piece of that is having that discussion up front in terms of, you know, what does good look what does success look like? And if you have a good clarity and definition, and you've already had the debate as to what success looks like then when you get there, it's a lot easier to say, Okay, we're here, we've we've met the objective, we've met the goal

Aaron Moncur: 0:28

Hello and welcome to the being an engineer podcast today, we've got Ryan Schoonmaker with us, founder of Tightline solutions and engineer extraordinaire. Ryan is a medical device product development leader and the founder of tightline solutions, where he helps growth stage teams bring more structure, predictability and disciplined execution to complex product development work. Over the course of his career, he's held engineering leadership roles at beta bionics BD and Dexcom, where he helped lead mechanical R and D efforts tied to products like the Dexcom g6 and g7 he also brings earlier experience in drug delivery and medical device innovation from Helbling and safety syringes, giving him a deep perspective on what it really takes to move meaningful products from concept to market. Ryan, thanks so much for being with us on the show today.

Ryan Schoonmaker: 1:41

Thanks for having me. I've been looking forward to this, so really excited to get into it.

Aaron Moncur: 1:46

Awesome. All right, we'll do some rapid fire Q and A before we get into the meat and potatoes of our interview today. So first rapid question for you, if you could apprentice under one engineer for a year, who would it be?

Ryan Schoonmaker: 2:01

Oh, man, that I was not expecting a question like that apprentice under one engineer for a year. Wow. That is really difficult to answer. I would say I'm not sure I could pick a specific person, but I could pick a type of person that I would like to apprentice under, and that'd be someone that is very curious, very disciplined, loves to learn, and then someone that is just an excellent leader, because I'm a student of leadership, so someone like that is what I would say,

Aaron Moncur: 2:43

awesome. I've always thought it would be interesting to apprentice under, like, one of the old old school. I mean, old school is not the right way to say it, one of the original scientist engineer types, right? Like, like Isaac Newton or Leonardo da Vinci, something like that. That would be interesting. Okay, next one, I think this is going to be a quicker answer, coffee, tea or energy drink.

Ryan Schoonmaker: 3:06

Oh, coffee, absolutely, 100% coffee.

Aaron Moncur: 3:11

All right, fail fast, or plan meticulously.

Ryan Schoonmaker: 3:16

Fail fast, I'd say, Yeah, fail fast, all right, and

Aaron Moncur: 3:22

last one, one invention you wish already existed.

Ryan Schoonmaker: 3:28

Oh, time machine.

Aaron Moncur: 3:33

Oh, that's a that's a good one. Yeah,

Ryan Schoonmaker: 3:36

Marty

Aaron Moncur: 3:37

and Doc Brown, here we go. Yeah, there we go. All right, great. So Ryan, what made you decide to become an engineer?

Ryan Schoonmaker: 3:46

Yeah, awesome question. It's actually, for me, I'm someone that likes to think very thoughtfully and be very meticulous about my decisions and so on. But this one didn't really fit that mold for me. I could remember sitting around my kitchen table, you know, before I was going to go into college, and just discussing with my parents, what direction am I going to go, what's my major going to be, and so on. And it was actually a very quick discussion and a very quick decision where I was like, You know what? I like to understand things, I'm very curious. I like to tinker with things. I like to be hands on. So, you know what mechanical engineering that's, I think that fits me. So that's, that's, that's the way I'm going to go

Aaron Moncur: 4:36

see,

Ryan Schoonmaker: 4:37

yeah, go

Aaron Moncur: 4:37

ahead. So you knew what a mechanical engineer was. At that point in time,

Ryan Schoonmaker: 4:42

I had a general idea. I understood kind of very high level and generally what what a mechanical engineer did. But it wasn't until I got into the curriculum that I that I really found my my specialty within it, because mechanical engineering is pretty broad. Right? I mean, you can go, that's one thing I liked about it, is you can go many, many different directions with it. But I remember very vividly being in my fluid mechanics class, and actually, not just the class, but in the lab. And part of the curriculum was to develop, well, not develop, but make a prototype of an artificial heart valve. Put it into this little test suite, this test chamber, and then look at the flow through the heart valve. And that was the first time it clicked for me, like, Oh, wow. I can use my mechanical engineering degree to do some pretty remarkable stuff with the goal and the benefit of helping people and helping helping their quality of life. That's when things really click for me, and I've been on a mission ever since that point.

Aaron Moncur: 5:53

That's a great story. Wow, tell us a little bit about that, the journey that you've been on ever since then, some of the major stops along the way?

Ryan Schoonmaker: 6:05

Yeah, sure, I so, I mean, from that point on that that was my track, that's the direction I was going to go. And so I specifically sought out a master's program that had a connection with a hospital, and that really had a professor of that specialized in that area. So I ended up at Tufts University in the Boston, Cambridge area, and I did a my master's thesis, master's thesis on vibro tactile feedback and minimally invasive surgery,

Aaron Moncur: 6:43

vibro tactile feedback, yeah, so that's

Ryan Schoonmaker: 6:46

yeah. So this

Aaron Moncur: 6:47

tactile feedback through vibrations,

Ryan Schoonmaker: 6:51

yeah. So it was so for minimally invasive surgery, at least at the time. This was granted about 2020, years ago, but at the time, there's no robotic surgery or anything like that. But the feedback for surgeons doing minimally invasive surgery was was almost nothing, because you have the device going through the trocar into the body, and they lost all their tactile feel. They couldn't really feel what was going on. So my thesis was to what's a way to give them some feedback, a feedback loop back as to what they're touching and feeling and so on inside the body, and the way that we did that was through a vibration feedback. So so we slapped a force sensor onto onto the tool is able to get that data, in turn, that into a vibration signal that the surgeon could feel on their feet. And so anything that that they're feeling, they're getting that, that feedback and magnitude and so on.

Aaron Moncur: 7:59

Interesting. What drove the decision to place the feedback mechanism on the feet as opposed to the hands,

Ryan Schoonmaker: 8:05

yes, so that, yeah, this was, well, this was coordinated with the HF, the Human Factors department, which actually, at that time, human factors was just up and coming as well. And part of the feedback from the Human Factors data that we had at the time was that was a good, a good not saying it was optimal, but a good location to put it, or at least to test it out. Let's see how it let's see how it does. Let's see how it performs. Let's see what the response is.

Aaron Moncur: 8:34

Nice. Okay, let's talk a little bit about the difference between ideas and execution. I hear, I feel like I hear a lot of good ideas, and sometimes I feel like people believe that an idea is worth as much as the final result that idea is intended to produce. And what I've found is, I won't say ideas are a dime a dozen good ideas anyway, but I feel like the execution is more valuable than the idea. And I don't know how common that belief is, but what are there any experiences that you've had in your career that lead you to believe one side or the other. It's the idea, or it's the execution. Obviously, it's both. It's some mixture. But where have you fall? Fallen in that spectrum. PDX is coming back this October. I'd love to see you there this year, and I'm going to share with you the most cost effective way to do so, PDX is not your typical trade show attendees gain practical training and real answers across dozens of relevant engineering topics like GD and T project management, advanced CAD model. Link design for manufacturing, scanning and reverse engineering, additive manufacturing and much more regular pricing starts at $375 but early bird tickets are only$165 a savings of over 50% the early bird sale starts may 18 and ends May 31 so there's only a two week window to grab that discount to learn more, visit PD Expo. Dot engineer, that's p, d, e, x, p, O. Dot engineer, you

Ryan Schoonmaker: 11:46

Yeah, I definitely agree with you, and I I look at that perspective, and I say, I've experienced that many times in my career, where there is a good idea. I mean, companies wouldn't pursue new ideas, new innovations, new things, if they didn't think it was a good idea to begin with. Part of it is vetting, vetting it out. You know, is this as good as idea as we think it is? So that's part of it. But I think a lot of it is in the execution. And I've seen this time and time again, where a program gets shelved or canned, and it's not necessarily the idea that wasn't there, but somewhere along the way, the execution went off. It went wrong, it went it went sideways, and people lose patience and and things things get dropped and they get canned. And I, in this case, we were able to save the program. But I have an example from a time in my career where, I think speaks to this pretty well. So I came into a I came into a program that, you know, it was a good idea. It had momentum, it had a plan, and it had really good people, smart people, working on it, but it was in it was in real trouble, and and the way that the company and the program was able to get out of that trouble was really to focus on the execution side of things. And when we talk about execution, we're talking about clarity and requirements. You know, what? What are we building? What are we making? What are the design inputs? And are we all clear on what those are? We're talking about really foundational first principles, understanding of what we're trying to do. And I was that was a big gap on that program. They had some what I would call loosed first principles understanding, but not the depth of first principle understanding that was really needed to execute and make this make this thing real, make it something that's going to be sold. I'd say Clear, clear phase gate requirements as well. When is the right time to go to that next phase of the program, and having very clear requirements as to what the team needs to meet to be able to get to that next phase, and then from there, robust design specs, assembly specs, which i i have seen be a gap quite a bit in teams. They have their component level specs, but they don't go to the level of assembly specs near to the level of detail that's needed. And that's where most of the problems happen. Is that the assembly level.

Aaron Moncur: 14:44

Give us my experience. Few examples of that. What's an example of insufficient assembly specs, or maybe good assembly specs? What does that look like in practice?

Ryan Schoonmaker: 14:55

Yeah, so let's see. So a good assembly spec, I think it needs to take into account the process. Itself, the capability of that process, and then it needs to be specific enough that an operations team understands and knows what a good part is versus a non good part as the output of that process, I've seen many times where the spec is not clear at the assembly level, and the person implementing the process and developing the process kind of fills In the gaps, instead of having that robust discussion with the designer to really understand what exactly are you trying to point out here as a good part versus a non good part or output of this process? So I it's, it's very common. I don't really know the root of. Why that is, but I've seen it time and time again within my career that I don't know there's, there's just a gap there.

Aaron Moncur: 16:12

Yeah, because you hear about component documentation all the time, right? Almost every engineer out there understands what it means to create a drawing of a part. Put tolerances on it, put surface finishes on it, put material call outs on it. But you're right. The same level of rigor, I think, is often not applied to assembly specifications. It's not something you hear a lot about,

Ryan Schoonmaker: 16:38

yeah, and it's critical. It trips people up all the time, or teams up all the time, especially when scaling and you're going from, you know, your pilot line to a, you know, an automation line or a high volume line, etc,

Aaron Moncur: 16:52

yeah, this, this project that you were talking about where execution was Not being performed appropriately, and the project was struggling. What were some of the signs as you entered that project that made it clear to you that was the case?

Ryan Schoonmaker: 17:14

Yeah, I think there's a few signs there. I mean, there's a there's a few things to look at when trying to understand and determine, you know where things are going wrong and so on, I think team dynamic is, is really the first place to look. How is the team interacting with each other? Is there trust? There? Is there a high, high volume of communication? Are people communicating? I'd say. What I'd say is, is robustly, is there energy to their discussions? You can pick up, you can you you could, you know, sitting in on a team meeting, you can probably identify you. Couldn't identify if, if a big part of the root cause of, you know, where you're failing in execution is just simply coming from team dynamic versus anything else you know, I don't need to see your product. I don't need to see anything technical, I can just sit in in a meeting and observe the team dynamic, and kind of get a sense, as if, you know, is this where the where a big part of the problem, anyway, is coming from, from, you know, execution standpoint.

Aaron Moncur: 18:40

So does that mean more in the soft skills than in the the tactical skill side. Yes,

Ryan Schoonmaker: 18:50

yes, definitely. I think, I think the soft skills, they call them soft skills, but I think they're, they're hard, they're

Aaron Moncur: 18:58

hard, hard, required anyway, and and difficult,

Ryan Schoonmaker: 19:02

yeah, well, I mean that the quote, unquote soft skills are the ones that are hardest for people to, I think, Master. So they're, they're difficult, but I think, you know, they're, they're imperative for, for the success of of any project and any program.

Aaron Moncur: 19:21

Yeah, right,

Ryan Schoonmaker: 19:23

yeah.

Aaron Moncur: 19:23

Okay, let's see. You've worked in, you know, a variety of different environments, right? You've worked in large companies, BD, Dexcom, these are huge organizations. You've worked for consulting firms, and you've worked in your own startup currently, how? How have you seen product development, the development process, differ in these different environments, or does it differ much?

Ryan Schoonmaker: 19:55

No, it does differ. I think it differs quite a bit. I kind of liken it to the concept of technical debt. Have you ever delved into the concept of technical debt? Not at all. I mean, I'd say so. The the concept, anyway, is that there's a certain amount of certain, certain amount of work that goes into developing a good product. So that was what you would call the principle like it just this is what has to be done to produce something that is good, something that customers are going to like and and something that's going to have a high quality and be done well,

Aaron Moncur: 20:49

I heard Sorry to interrupt. I just thought of this. I think it's interesting. An old manager of mine said that every project has its own Hold on What was the word he used, timeline.

Ryan Schoonmaker: 21:03

I. Or

Aaron Moncur: 21:05

something like that. Every project has its own timeline or amount of effort that needs to be put into it. The project manager's job is to figure out what that timeline is, what that amount of effort is. Just sounded like it aligned with what you were saying.

Ryan Schoonmaker: 21:20

Yeah, it's probably similar. It's probably similar, but if you start with that, just assume that you need a certain amount of principle to go into, into the effort that I think small companies are willing to take more debt on to go faster and larger companies sometimes are not willing to take on as much debt, because debt equals risk. So they they and they have more capital, more resources to put into things up front. So it's, it's not cutting corners, because I, you know, there's a certain amount of like I said principle that needs to happen, but it might look like, let's say you have a clinical phase gate, right? And what you're going to put into that clinical you're saying is going to be good enough to achieve that milestone. So a a smaller company, a startup company, might say, Okay, we're going to do that. We know we have this additional technical work to do. That's part of the principle for something that is usable at the product level, in the customer's hands. However, for this clinical we're not going to do everything yet, because we need to hit this milestone to be able to get our next round of funding, which that gets us to this next step. However, where you need to be careful with this is that the more debt you take on, the more irresponsible it is. So you need to be very clear as to how much technical debt, how much you're putting off to the future that you're willing to take on, because you always, there's always interest that comes with it. There's always a trade off. There's always an interest that needs to be paid on any debt that you take on. So I don't know, I look at it from from this technical debt standpoint, I think, you know, working with a small company, you need to be willing to take on a little bit more debt, be very upfront about it and communicate, hey, this is the debt that's going to be taken on. There's going to be some interest to pay. This is what it's going to cost, and that it's your job to kind of find the best rates and the the best, the best deal for for for that small company, whereas that's less of an issue for for larger companies. But I think where they get into trouble, or can get into trouble, is they don't want to take on any debt, and, you know, they they just inefficiently spend too much overpay for, for what, for what they're trying to do that, that capital, that, that is the principle. Sometimes they can overpay on it, and then that's that's not good either. You want to find the most efficient path to to launching something.

Aaron Moncur: 24:19

It's a little bit paradoxical, isn't it, that a large company with ostensibly lots of resources, right cash, people, time, is perhaps less likely to take on the risk that is inherent in R and D and development than a smaller company who has a lot less resources, but maybe is willing to go out on a limb a little bit further in terms of their What did you call it? Development debt, technical debt.

Ryan Schoonmaker: 24:50

Technical

Aaron Moncur: 24:51

technical debt. Yeah, right. What do you think that is? I mean, it feels to me, and this is probably my personality, right? But if I had the kinds of resources that large companies have, I would want to spend it doing interesting development work and but a lot of these strategics, so called strategics, right? The large medical device companies out there, for a lot of them, their their MO is to find smaller startups that have taken on that technical risk and then just gobble them up. I guess, as I'm talking through this, it does occur to me that they don't just gobble up anyone. They gobble up the ones who are successful. So automatically, they've filtered out the ones who have taken on that that technical debt, and it didn't work out. So I guess they automatically circumvent the situations in which taking on that debt did not work out.

Ryan Schoonmaker: 25:46

Yeah, I think for most large companies, they want, they want a certain amount of capital to have already been been paid, and in a lot of the technical get debt to be burned down. It's. To a certain level, and then once it's at, at the point where you know that that what the risk looks like that they're taking on is acceptable, and they know can, they can get a good, good return on that investment at the end of the day, then they're willing to to pull the trigger, yeah, and and then move forward on, on that stuff, yeah,

Aaron Moncur: 26:28

I guess, if I'm just making up some numbers here to illustrate the point, but let's say that it takes a million dollars to develop something to the point where a larger company would want to would be interested in acquiring it, And maybe the acquisition cost is $5 million but maybe only 10% of the time does a company actually get to the point where their idea has come to fruition, to that point where a strategic a larger company would want to take it on. So if you say 10 companies are going to spend up to a million dollars developing something, that's $10 million and only one of them is going to be successful and then sell for 5 million. You could ask yourself, well, why doesn't the large company just do that themselves? They could spend a million instead of 5 million, but really, if it's only a one in 10 success ratio, then they're spelling spending 10 million, not 5 million, and all of their internal resources and time as well. So I guess that makes sense.

Ryan Schoonmaker: 27:25

Yeah,

Aaron Moncur: 27:27

shocker, these people who have been doing this forever have probably thought of this, right, all right. How do you think about the difference between, I mean, we kind of touched on it already, but getting really deep into a problem which takes time versus being I don't want to say fast and loose quite but you know, like you said, maybe trimming a couple of corners Sometimes moving fast is more important than being exponentially detail oriented or thorough, especially in the beginning, I find the best engineers that I work with know where that point is to say, this is good enough, and stop going down that rabbit hole. Have you seen that a lot in engineers that you've worked with and like, how do you coach engineers to understand where that point is, where it's good enough and time to move on?

Ryan Schoonmaker: 28:35

Yeah, I think I definitely have seen that quite a bit. I and I think part of what I've been able to do in my career, because I am a very structured person, I tend to my de facto way to solve a problem is very methodically and to think things through thoroughly. But that doesn't always Jive well with the world we live in today where speed rules. I mean, everyone, I have never been part of a program where they have said, let's give you more time. We need to go a little bit slower. We don't need to go it's always we need to go fast. It's urgent, you know, so on. It's just the world we live in. And I totally get it. I understand that, and I understand why. So I've had to adapt myself to to that world. And I think part of part of doing that, is doing exactly what you said, and that's being able to discern what's important and what's not important, and then when is what is done, and when you know, do we need? We need to keep going. And I think a big, a big piece of that is having that discussion up front in terms of, you know, what does good look what does success look like? And if you have a good clarity and definition, and you've already had the debate as to what success looks like, then when you get there, it's a lot easier to say, Okay, we're here. We've we've met the objective. We've met the goal. We don't need this nice to have. We don't need to be this much better than where we already are. We've hit it. We're already there. It's clarity for the team, it's clarity for leadership. It's, it's clarity for everyone. So I think, I think having that upfront discussion early on in a program in terms of what success looks like, it really, it really helps with that significantly. I'd say another thing. Another thing is, I. Um, oh, shoot, I lost my train of thought.

Aaron Moncur: 31:50

That's okay, no worries. Let's talk about building teams for a little bit. You've, you've led teams. Are there any particular strategies that you found specifically for organizing engineering teams to help them be light, nimble, productive, not not weigh them down with a lot of bureaucracy and red tape. Pipeline now offers procurement of custom machined parts at significantly lower costs without sacrificing speed or quality. We design and build custom machines ourselves, so we consume a lot of precision machined components. Over the past several years, we developed a proven overseas supply chain to support that work, and in 2025 we successfully piloted that capability with select customers. Now we're opening it up more broadly. If you'd like to see how our prices and lead times compare. Send us a drawing or two for quote, visit team pipeline.us. Or message me directly on LinkedIn.

Ryan Schoonmaker: 33:03

Yeah, definitely. It goes back to what we were just talking about in terms of clarity helps significantly. I think clarity and success, clarity and mission, clarity and ownership, clarity and roles, who are the decision makers and so on. So just providing clarity helps significantly in terms of having productive work streams. I say also,

Aaron Moncur: 33:35

how do you like to do that? Sorry to interrupt. How do you like to provide that clarity? I mean getting like concrete with that do. Is it just a conversation, one on one, with an engineer. Is it a document that's shared? Is it some kind of application that's used, or is it all of the above? How do you how do you ensure that clarity has been achieved? What are the tools that you use?

Ryan Schoonmaker: 34:02

Yeah, I it. I think it's, it's it's a team thing. It has to be the team. So it's not going to be a one on one conversation. But, I mean, I think having a core team for a program is important. So the core team is going to be, you know, a cross functional team. And that's where things should start in terms of, you know, defining a program for a team, defining ownership, success, mission, etc, and then it builds, it builds down from there. So let's say, you know, you have a technical team that, that is, you know, there's a design team, maybe there's a process development team, there's a firmware team, there's all these different parts that are going to bring the technical piece together. Ideally, they're taking the mission from and the definition of success at that top level, program level, and they're defining it for themselves at the team level, at their specific functional level, and if they're defining it there, then what's defined at the high level is trickling down to very clear definition across the board, and that that creates alignment, and that creates, you know,

Aaron Moncur: 35:22

everyone's rolling the same direction.

Ryan Schoonmaker: 35:24

Everyone's rolling the same direction, yeah, and I did remember my when I lost my train of thought what I was going to say. So it's not only important to it's also important to have clarity on what things a team is not going to do. I have found so a lot of teams want to talk about what they're going to do so last program that I that I was working on myself and the team, sat down and we said, what has killed us from a speed perspective, in our in our careers? And we wrote it all down. We said, these are all the big roadblocks, the the points of intersection or discussion that you know caused us to delay and cause big headaches for the program. And we said, okay, what are we not going to do again? And we had, we had this charter, we had this list of we're not doing this. We're not going to do this again. We're not going to make this mistake. And we had, like a top 10 things, and we were able to, in the program to revert back to that and reference back to it, and say, Guys, we're doing this again. We said we weren't going to, that's awesome.

Aaron Moncur: 36:43

Let's, let's stop it. Right?

Ryan Schoonmaker: 36:45

Yeah. Yeah, and let's do you

Aaron Moncur: 36:46

remember what any of those things were your list of do not do these speed limiting behaviors anymore.

Ryan Schoonmaker: 36:55

Yeah, one immediately came to mind, and one place that I have found that has caused significant delays. This. This will sound, this might sound a little bit wild, but I think a lot of people might might relate to this as well. Is component color choice,

Aaron Moncur: 37:17

hmm, okay,

Ryan Schoonmaker: 37:20

here's why. Here's why. Because, especially in the med device world, it's very subjective choosing the colors. Or can be subjective choosing the colors, however, meaning at the executive level, at the leadership level, there's a lot of discussion, and sometimes there can be a change or a desired change, late in the program. However, the material choice, which in which includes the colors and the additive that you're adding into the plastic has a big regulatory impact. It has a big quality impact. It has impact on all these downstream things. I could be in the middle of a test cycle, and then all of a sudden someone wants to change the color, and I got to repeat all that biocompatibility testing again and so on, which is a long lead item. So that's one of the things we said. We said we're choosing the colors early, and it's it's done. It's defined like

Aaron Moncur: 38:32

that that can get tough, right? If someone at the very top comes in later is like, hey, thinking about it, actually blue and green stripes, I think would would be better. Did you have any of those conversations where you had to be like, I mean, we can do that. But

Ryan Schoonmaker: 38:49

they, they were part of the original discussion.

Aaron Moncur: 38:52

Okay, that's important

Ryan Schoonmaker: 38:53

that. That's very important. They were part of the original discussion. We said, Look, we, we've been burned by this in the past, or some of us have. Can we? Can we nail down our our materials in our colors early and not change from them and be committed to them. So that made their discussion to nail down those decisions a lot more serious and a lot more, you know, intentional understanding the impact and ramifications down the line and how it could slow the development team up. So there's a lot more thought that went into it. Yeah,

Aaron Moncur: 39:35

that's a great principle right there, just identifying those decisions that are going to have large ramifications on the project, and getting those decision makers to commit early, to enroll themselves, to very intentionally make those decisions once, so you don't have to go back and do things over later,

Ryan Schoonmaker: 39:55

right now, now when, if they decide later that they want to change it, change the color, they already know the impact. They know what it's you know the downstream effect it's going to have, yeah, and that's, that's their call. They can make that call, but then it's their decision to delay things. It's not, it's not the product development team's decision,

Aaron Moncur: 40:21

and it's very difficult to go back on something that you have personally said or agreed to, especially when that agreement is like, public and documented, right? I mean, people don't like to do that. No, all right,

Ryan Schoonmaker: 40:36

no, they don't.

Aaron Moncur: 40:37

Let's talk about tight line solutions for just a few minutes. What tell us, what is tight line solutions? How did that come

Ryan Schoonmaker: 40:44

to be? Yeah, it's I had an opportunity recently, I'd say, within that last six months, to go out on my own and start my own firm. It's something I've always wanted to do, something I'm passionate about, and so I I took the opportunity, I jumped at it, and I made started this program. It's called tightline solutions, and it is targeted at coming alongside product development teams to go from chaotic and unpredictable to something that is structured and predictable. Um, so we have, you know, a few focus areas that. That we key in on, and those, those focus areas include coaching teams through their most difficult technical challenges, doing audits, you know, their product development process, especially teams that are coming up on a launch. Are you? Are you ready for a launch? Do you have any vulnerabilities in your process that could could bite you and hurt you down the road? And then

Aaron Moncur: 42:15

we also do leadership coaching and and mentoring and career development work that's cool, I can see, especially coming in with an outside observers set of eyes, right? Someone who hasn't been so intimately familiar with the product this whole time, and just providing that outside opinion about areas the core team may have missed because they've got the blinders on, right? They they're so familiar with the product they can't see what they can see,

Ryan Schoonmaker: 42:48

yeah, absolutely. And that's something that I have written about recently, actually. So there's actually a cognitive science behind it, where people and teams put more value on the things that that they develop and they produce, and if you deviate from that original plan, then there's, it's, it's viewed as a loss versus A change, and then a gain from that, from that pivot. So there's, there's actually a cognitive science to it, and, you know, bringing in someone that doesn't have as much stake, or they haven't built it, so they don't feel the same level of ownership over it, they have a different perspective that I think leaders and teams can use to their advantage, to put their product in the best position to be to be successful when it when it comes to launch stage, to be able to find vulnerabilities and things that that may may may be a big problem down the road.

Aaron Moncur: 44:08

Yeah, just be more objective, right? When you're analyzing the product. I'm curious, do you have to put you on the spot, and if you can't think of anything, that's fine. But do you have a favorite failure in your career, something that was pretty painful at the time, maybe, but, but allowed you to learn some really important lessons that you've taken with you.

Ryan Schoonmaker: 44:34

Yeah, there was one, there was one instance. There was that it was actually the one of the programs I alluded to earlier in the conversation. And, you know, we're very we're on pretty good track. We're moving from prototype tools to manufacturing production tools, and we're we're getting good data with the prototype tools, and we moved to the production tools, and all of a sudden we put our assemblies together, and there was probably 20 to 30% of them, at least, were failing. So that was that was a big oh crap moment, but we were able to dig into it and resolve it relatively quickly. And I think part of the key there was to a, keep a level head. B, you know, there was a lot of work that had gone into getting us to where we were, so there's a lot we already knew, and there was a lot we already knew to be true, and there was a lot we already knew you know to be grounded in data. So I think getting to that point of just grounding yourself in and the data and what you already know, helped bring the the urgency level and the kind of freak out moment down to a manageable level for the team. And then it was okay, let's break this down. Let's, let's look at, you know, piece by piece, what, what could be the problem? What could be the issue? What? What don't we know? So we already said, what do we know? What don't we know, and what are the really important questions to ask right now? So at the end of the day, it was, there was a miss. Spec on the drawing missing, from a standpoint of the team just missed it. Something wasn't defined that needed to be defined. So when they spit these parts out, there was a dimension that was very important, that was never on the drawing, that was that was off and the people making the parts, the supplier, they didn't know, because there was no sure thing on the drawing.

Aaron Moncur: 47:13

Yeah, interesting, great story.

Ryan Schoonmaker: 47:16

We were able to, yeah, we were able to pinpoint it to that. We were able to correct the process and then put that dimension on the print and control it, control it down the road. So, I mean, I guess, I guess the lesson was, really understand what's critical in your design and what what isn't critical, and make sure you have that robust discussion and and a really good technical review of Your drawing before, before you, you know, kick off, move to that next, that next step in that and that next phase

Aaron Moncur: 47:54

you mentioned, looking at individual components, and it reminded me of an experience I had. This is one of my favorite failures. I was troubleshooting a motion control system. This is probably four or five years ago, six years ago, something like that. And there were four axes of motion in this system, and it was supposed to move a payload from, you know, point A to point B, wherever those were. And it would never get quite to point B. It would get close, but but not quite there off enough that I thought something's wrong here, and I spent hours troubleshooting this, trying to figure out what was wrong. It's embarrassing to say now, because even five, six years ago, I shouldn't have known better. But finally, after spending probably half a day trying to troubleshoot this and really getting nowhere, I finally dawned on me that, oh, I need to break this down into, like its constituent axes of motion and just test one at a time, not test at the system level. And as soon as I did that, I mean, it was painfully obvious that that one of the axes just didn't work. And I later tracked it down to there was an incompatible part that was being used, but it was so quick after I did that right look at the individual components, in this case, individual axes of motion, to figure out which one is failing or multiple failing. And that's something you never get if you're just trying to troubleshoot at a system level.

Ryan Schoonmaker: 49:25

Yeah, you see that all the time. That's actually, actually another thing that you see commonly, I think, is that people want to solve the problem in one fell swoop. You know, you, you, you want to, you want to be the hero, or the team. Wants to be the hero, so it you can get caught in this trap of looking for the solution before you really understand the problem. A and then you can get in this trap of, you know, trying to you're having a hypothesis that kind of goes straight towards one issue that could, you know, if you understand that could solve, you know, the entire, the entire problem at hand. But really, what I have found to be a better strategy, especially when you have complex systems, is to narrow in on what part of the system the problem is coming from first. So think of narrowing in kind of like you have this huge spotlight, and you want to go just a little bit smaller and kind of locate, well, I know it's in this area. I don't need to pinpoint it yet, but I know it's in this area of the system All right, now that I know that's in this area, now I can go a little bit deeper and maybe narrow it in even more, and then once I narrow it even more, okay, now I can pinpoint the actual root cause of the issue, and that tends to be a faster path than trying to get it, understand it and solve it, all in one fell swoop.

Unknown: 51:05

Yeah, yeah,

Ryan Schoonmaker: 51:06

where you're just bouncing around to different parts of the system and and different ideas. So in terms of, like, getting a structured, you know, process to a understand the problem and then find a solution for it, I've definitely found that narrowing in as a strategy and then pinpointing is a lot faster path to get there.

Aaron Moncur: 51:29

That's great, great advice. Yeah, all right, Ryan, let's, I'm gonna give you one more question, and then we'll, we'll wrap things up, and hopefully this is a question that that mostly benefits you. We have this wonderful community of. Engineers who are listening to this episode right now, and maybe they'll they'll see a short on LinkedIn or something on YouTube, see it in the newsletter. What is something that this community could help you with? What is there a technology you're trying to learn more about? Is there a subject matter expert that you're trying to meet what? What's something that a listener right now could, could potentially say, Oh, I know how to do that. I'll reach out to Ryan and tell him what I know.

Ryan Schoonmaker: 52:19

Yeah, I think, I think the what best way to help me, or what the community can do for me, is to have a conversation with me. I mean, my my goal and my mission, and the mission for our company is to propel products. I want to see products out there that are able to, you know, do what I said in the beginning, which is, help people live a better quality of life. And then I but I, you know, I also want to help people advance in their careers. And the best way to do that, I think, is, is to start with a conversation and discuss with people different things. There's always something to learn from someone else. I'm very curious and and generally want to engage with people. Understand where their pain points are, understand, you know, some of what they know that that that I don't know. So you know, or if there's someone that you think I should talk to. You know, make, make, make that introduction from all from a networking standpoint, I think that's, that's what I would look for most from from the community out there, great. And what is the best way for people to get a hold of you? You can get in touch with me by email. My email is our Schoonmaker at tight line solutions llc.com, or you can easily find me on LinkedIn and connect with me on LinkedIn and then send me, send me a note or a message. I accept all connections. I'm not one of those people that you know is, is puts a firewall up in terms of connecting with others. I want to connect, so I'll accept it and then, and then send me a direct message. It's great this way. And

Aaron Moncur: 54:20

we'll put a link to your LinkedIn profile in the show notes. And that's Schoonmaker. S, C, H, O, O, N, M, a, k, e, r, do I have that right?

Ryan Schoonmaker: 54:30

Correct?

Aaron Moncur: 54:31

Perfect. All right, Ryan, anything else that you want to cover before we sign off for today?

Ryan Schoonmaker: 54:38

No, I appreciate the time, Aaron, and I appreciate the the invite. And enjoyed this, this discussion, and I hope your audience finds it interesting and useful. Excellent. All right, Ryan, thank you so much. Thanks. Bye. Bye.

Aaron Moncur: 54:56

I'm Aaron Moncur, founder of pipeline design and engineering. If you liked what you heard today, please share the episode to learn how your team can leverage our team's expertise developing advanced manufacturing processes, automated machines and custom fixtures, complemented with product design and R and D services. Visit us at Team pipeline.us. To join a vibrant community of engineers online. Visit the wave. Dot, engineer, thank you for listening. Being an engineer has more than 300 episodes, and you don't have to listen to them in order. If you're dealing with a specific challenge right now, there's a good chance we've already interviewed an engineer who's been through it, you can jump around, search by topic and listen to what's most relevant to you see you on the next episode you.