Being an Engineer

Daniel Servansky | Electromechanical Engineering, Root Cause Analysis, & Engineering Ethics

March 10, 2023 Daniel Servansky Season 4 Episode 10
Being an Engineer
Daniel Servansky | Electromechanical Engineering, Root Cause Analysis, & Engineering Ethics
Show Notes Transcript

In our discussion with Daniel Servansky he shares the one thing he would change about how engineering companies operate, a wonderfully educational example of the engineering process that is root cause analysis, as well as how to get started learning electronics as a mechanical engineer.

Daniel is an electromechanical system engineer with over 12 years of experience focusing on the design, prototyping and development of complex and technology-rich medical devices. He has rich working experience in the full NPD process including concept generation, design feasibility, requirements cascading, FMEAs, Verification & Validation, Design Transfer and product launch.

https://dservansky.wixsite.com/intro
Aaron Moncur, host

We hope you enjoyed this episode of the Being an Engineer Podcast.
Help us rank as the #1 engineering podcast on Apple and Spotify by leaving a review for us.
You can find us under the category: mechanical engineering podcast on Apple Podcasts.
Being an Engineer podcast is a go-to resource and podcast for engineering students on Spotify, too.
Aaron Moncur and Rafael Testai love hearing from their listeners, so feel free to email us, connect on Facebook, Twitter, Instagram, and subscribe on Apple Podcast and Spotify!

About Being An Engineer

The Being An Engineer podcast is a repository for industry knowledge and a tool through which engineers learn about and connect with relevant companies, technologies, people resources, and opportunities. We feature successful mechanical engineers and interview engineers who are passionate about their work and who made a great impact on the engineering community.

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 such as cycle test machines, custom test fixtures, automation equipment, assembly jigs, inspection stations and more. You can find us on the web at www.teampipeline.us

Presenter:

Hi, everyone, we've set up this being an engineer podcast as an industry knowledge repository, if you will, we hope it'll be a tool where engineers can learn about and connect with other companies, technologies, people, resources and opportunities. So make some connections and enjoy the show.

Daniel Servansky:

I think one of the most important things that I would ensure was true was that what we say as a company what we say we value as a company was true. If we said that we put the customer first we put safety first, that we actually do it.

Aaron Moncur:

Hello, and welcome to the being an engineer Podcast. Today we're speaking with Daniel Servansky, an electromechanical system engineer with over 12 years of experience, focusing on the design, prototyping and development of complex and technology rich medical devices. Daniel has rich working experience in the full NPD process, including concept generation, design feasibility requirements, cascading FM Bas, verification and validation, design, transfer and product launch. Daniel, thank you so much for joining us today.

Daniel Servansky:

Oh, thanks for having me.

Aaron Moncur:

Great. I also want to point out that we have a second Aaron with us today. Aaron Robison, who is our director of business development, Aaron, thank you also for hanging out with us on the podcast.

Aaron Robison:

Glad to be here.

Aaron Moncur:

All right. So Daniel, first things first, what made you decide to become an engineer?

Daniel Servansky:

Well, for me, it seemed like it was a natural thing for me to become an engineer, my parents tell a story about how before I was able to walk, I was disassembling an oscillating fan that we had. That's kind of the story of my childhood, I was always working with my hands, taking things apart. And in my younger years, most of the time, not able to put it back together. But eventually I did figure out how to get things back together. And my parents were very appreciative of that. But, you know, that led to me spending most of my childhood building things, you know, I had literally 10s of 1000s of Legos and connects, I built rockets and airplanes, and I tend to, you know, Lego camps, robotic camps. It was just what I love to do. So it was just natural, that that was the direction that I was heading.

Aaron Moncur:

That it sounds like your parents were very supportive of this organic desire that you had to be an engineer were there. Can you think of anything that they did as you were growing up that kind of helped facilitate or nurture that that instinct that you already had?

Daniel Servansky:

Well, you know, when I said, you know, I wanted the latest and greatest Lego kit, you know, they were usually willing to get that for me. birthday presents, Christmas presents, things like that. I remember one Christmas, my favorite gift that I got was the connects big ball factory. It was brand new sometime in the I forget the mid 90s. And I remember seeing the commercials for it. I was like, I had to have it. And it was so cool. I put that together in probably like a day. My parents just beside themselves. I got this whole thing together. It was something like six feet tall. I think it was Wow.

Aaron Moncur:

Wow feet tall. Yeah, it was they do big ball said you said it was

Daniel Servansky:

a it was called the big ball factory. And it was basically like a connects Marble Run. You know, they had these big, maybe like inch and a half diameter balls and there was a chain system that would take it up to the top. And then there was maybe like three or four different paths that the ball could go through. One of them was a loop, one of them was a jump, like there's a just kind of went back and forth through the whole structure all the way back down to the bottom. And that that was pretty cool. I really love that. When I got a little bit older, I got into Lego Mindstorms. I remember when that first came out, like that was the thing I wanted again, like that was my big Christmas present that year was the original Lego Mindstorms kit. And I literally spent like, every afternoon building something new out of Lego Mindstorms and that's kind of my first foray really into like programming and electronics and, and how I, you know, got interested in that. I do kind of remember even younger than when I had the Lego Mindstorms like I liked electronics even though I really didn't understand what they were just when I would, you know, naturally take things apart. I find a circuit board in there and again, back in like the 90s. We didn't have this, you know, nice surface mount components. It was those big chunky through hole resistors and stuff like that. So I'd look at this old dusty circuit board and just be like, What the heck are these components? These are so cool. And I remember, you know, like, I would take like snips and kind of snip components off of there and keep them in a drawer somewhere, not knowing what they were what they would do, just thinking maybe someday I can make something out of this. But yeah, so you know, my, my parents were, for the most part pretty understanding about, you know, me destroying half the stuff in the house.

Aaron Moncur:

That's wonderful. it sounds like from a very early age, you were an engineer of the truth type, just passionate and getting into all the nuts and bolts and everything. So you are an electromechanical system engineer now, which, which I think is a really super powerful combination. It's not a combination that you find a lot. Although I think more and more these days, it's becoming a little bit more common. You shared a little bit about how you got into the electronic side growing up, how has that helped your career versus only having the mechanical background?

Daniel Servansky:

Well, in a way, I've been a little bit lucky that a lot of the jobs that I've worked have lived in the electromechanical realm. So like my first job out of college, I was working for an insulin pump company. So you know, there's electronics in that a micro drive system, and that that was really kind of like my first foray into a real like product development and working with electromechanical as a career, and I just really enjoyed it. And you know, I stepped from that to a company called plasma surgical, where they were making a laparoscopic surgical tool that literally shot plasma out the end of it. So that it was like something from Star Trek. So that was pretty nifty, too. And then I did a couple other things and ultimately, ended up at Philips working on oxygen concentrators, which, again, electronics, compressors, motors, displays, like there's a whole bunch of stuff and in those concentrators, and so it's, it's just kind of been, it's nice that my career has followed that path. And it's certainly something that I've sought out. When I was looking, you know, from, I guess that first job with animus was sort of luck, it was one of my co ops, through Drexel. And I really enjoyed it and kind of stuck with it. But after that moment, I kind of sought out those electromechanical positions and tried to stay in it as much as possible. Granted, I also graduated the middle of the recession. So it was at times difficult to do that. But ultimately, I got back to it. And it has been extremely beneficial throughout my career, not only for continuing to learn and progress through my career, but also, it's, you know, it's been kept my career interesting, I've enjoyed going to work because I get to work on things that I like to play with.

Aaron Moncur:

That's probably a big deal that you were very intentional about it. I imagine there are engineers listening to this right now who, maybe they're mechanical, and maybe they don't have a lot of experience with electrical and they're thinking to themselves, Man, I sure would like to pick up some electrical skills, any tips that you can suggest for how mechanical engineers or you know, anyone that doesn't really have that electrical background can can get started in that area?

Daniel Servansky:

Yeah, I would highly recommend picking up an Arduino or teensy or something like that, and just start messing around with it in your free time. Honestly, more recently, I got back into electromechanical by finding a reason to need those. So when I was working at Philips, you know, I started as a sustaining engineering got to do a little bit of development work, but it wasn't, you know, that wasn't my normal job. I wasn't until I moved into new product development and ultimately advanced development in Philips, where I got to, you know, sort of, in a way, pick my own path. And I found reasons why I needed to incorporate these components into what I was working on. Like, you know, when I was working on the next gen oxygen concentrator, I said, Well, hey, you know, we go out to these circuit board manufacturers give them a schematic that our electrical engineers put together, so we can get a prototype board so we can build the system and test it out. And that's, you know, four or five months turnaround time from start to finish till we can actually start testing product. Or let me spend a couple $100 on a teensy a breadboard, some solenoid set, you know, these various components, and I'll put something together build a simple program that runs it. And in the matter of, you know, a few weeks we have a system up and running that we can totally customize and change as necessary. If we find one valve doesn't work, or maybe we want to try doing proportional valve control, or maybe we want to change the disk Lay or do something different have different UI. And so you now have this super customizable system that lets you do much faster turnaround times and prototyping. And it was something that really hadn't been considered before. But I threw that out there as a, hey, I really think we need to do this. And by the way, I'll do it for you. And that was my opportunity to actually build it, test it learn. I mean, I spent a lot of time on Google learning how to program, C Plus Plus, and all that just so I could get the system up and running. And it, it was a lot of fun. I really enjoyed it again, that comes back to the, you know, I'm doing stuff that I enjoy doing. But yeah, I found a reason to do it, convinced everyone we need it, and then went out and do it.

Aaron Robison:

Have there been any obstacles or downsides to you doing it yourself doing so much? I mean, it sounds wonderful for you and your employer. But is there ever been any trade offs with you doing it all?

Daniel Servansky:

I mean, sure, as long as you have the bandwidth to do it, it's no problem. But a lot of times me doing those side things was exactly that a side thing, it wasn't my main focus at work. And so all of my other priorities obviously took precedence. And, you know, I got to work on that on the side where I could, at times, I would carve out time to do it, or spend a little extra time a few extra hours here and there working on it. So it is a balancing act. Once I moved into advanced development, then that more or less was my job. So I that was a little bit more free to do and work on those things. But when I was a new product development, it was really more sort of putting this together on the side.

Aaron Robison:

Great, that's helpful. So now you say you're also a principal product development engineer. Can you explain to our listeners, what principle means and what responsibilities we different now versus someone if you weren't a principal engineer?

Daniel Servansky:

Sure. One thing I've noticed from company to company is, titles mean very different things. And you know, the, the hierarchy of the titles are different from company to company as well. Generally speaking, though, Principal Engineer is based on experience and skill. And it's really more about leadership and decision making. You're kind of the person that the team goes to for advice and for decisions and for insight. But honestly, I've been doing that for a long time anyway, without the principal title. So I guess theoretically, that's what principal means. But that's not necessarily always the case. It's it's very company dependent and project dependent, and what's going on in your particular company or project.

Aaron Robison:

Makes sense? Yeah, I think we see that, in almost all words from company to company, they mean different things. Yeah. One of the things you talked about us doing in the past was performing root cause analysis on manufacturing and product failures. Can you give some give us an example of something that you did, and maybe how you would have liked to have done it differently, so we can all learn from it?

Daniel Servansky:

Well, when it comes to root cause analysis, you know, I've been doing that for my whole career. Part of what engineering is, was figuring out what went wrong and learning from it. When I was working for plasma, surgical, that was really my day to day job. I was a process development engineer. And so I wasn't necessarily working on products, I was working on the processes and the equipment that makes the product, which that in and of itself was a very interesting part of my career and gave me tons of insight into how to better design products for manufacturability. That's something that I often see lacking, generally speaking, in the engineering world. So anytime you can get that experience, I highly recommend it. It has helped a lot. But anyway, so I was working on this product. It had a stainless steel tube, which was about five millimeters in diameter, it was thin walled, and inside of it, there was a polysulfone core that was extruded, and it created three fluid paths down this five millimeter stainless steel tube. And the way that we got that polysulfone core into it was we compressed the tube slightly. So it was, you know, elastically deformed, we would slip this core into it, release the pressure on it, the tube would spring back into shape, clamped down on the core, and create these three fluid pads. The problem was, you know that clamping was so sensitive to how much was being displaced how much displacement there was at the ends of the tube versus the middle. And the equipment that was designed to do that press just wasn't consistent enough to be able to get consistent results. There were three different length tubes that were being made. I think, if I remember correctly, it was like 10 centimeter or 15 centimeter and 20 centimeter, and the 10. And the 15 worked fine every time. But the 15 was getting long enough that the mechanism that did the compression, it was a manual toggle press. So you basically had like a, maybe two inch square push point in the center. And then there was this steel bar that kind of went horizontally across this press plate, and then the press plate itself that had like a C channel built into the top and bottom that the stainless steel tube would fit into, and you do the compression. But because of the amount of force being applied to it, and the small amount of travel that we're really talking about, if I remember correctly, it was maybe like half a millimeter total press, I think there would be enough variability from the ends to the center that you would over compress the center to be able to get the ends to compress down to where they needed to be. So you would end up plastically deforming the metal in the middle elastically deforming it on the outside. So when it sprung back, you'd end up with leaks down the center of the tube. So that was an exercise in Well, it's kind of like sleuthing, you look at everything that's happening and try to figure out what was really going wrong here. You know, what we saw was what we were getting leaks in these channels, when we got to that point of the test, all of a sudden, these 20 centimeter tubes were leaking all over the place, and we couldn't quite figure out why. So it started out with, you know, looking at where the leaks were occurring and trying to track down where they were occurring in, you know, we're finding, okay, they're kind of happening towards the center as to what would cause it to happen more consistently towards the center of the tube, and took some measurements down the whole length and found no, you know, the center was not actually circular anymore, it was kind of oval shaped. Alright, so why is it becoming oval shaped? And that led to our will, you know, there? Is there a different amount of compression happening in the center. And, you know, I found that by literally taking pin gauges and slipping it down the channel and finding Oh, yeah, we're slipping fine in the center. And we're getting stuck in the middle. So now we know, okay, there's a difference in the way that this compressing, and then that went to Alright, I'm going to create a finite analysis model of this whole press and figure out what's going on here. And from that, I can see oh, yeah, you know, we're getting, you know, a half a millimeter deflection on the outsides and a millimeter deflection on in the middle. No wonder we're compressing, and you throw the model the tube in there. And yeah, we're, you know, deforming that it's not springing back. And then that led to how do we redesign this so that we get more even consistent pressure across the whole thing. So ended up with this cache, I Roberto's like, 30 pound block of steel on the top of this thing, this huge, like, stainless steel piece, and those press plates were maybe like three quarters of an inch thick. And it had this, you know, we're trying to minimize weight as much as possible, because people did have to slide these in and out of place. So I did a lot of work in finite element analysis to figure out, you know, like, how can I sloped those, that push piece so that we're minimizing weight, but still getting the adequate even distribution of forces across the whole plate? And so you know, that was kind of the step by step, how do we get there. And then once we got to solution, actually had this thing machine, put it in the press started doing some testing, we found much more consistent, even results. And then it became how do we make sure this doesn't happen in the future. And so New preventative maintenance tasks were put in place I created new, you know, go no go gauges, I basically did exactly what I did find the problem, which was slipped, pin gauges through the bore to make sure we are getting even compression down the whole thing. And if we started seeing a slip here or there, we knew something wasn't quite right with the press and had to adjust something. So that's, you know, that's kind of the process of how you do root cause analysis. It's all sleuthing, you know, it's using what you learned in college, those theoretical equations and problems and actually applying it to find what's going wrong, and where and why.

Aaron Moncur:

That's such a great example. I love how you tie that all together. You've got, you know, hand tools, you've got sophisticated tools like FDA, and it all worked out at the end. I think probably we we've all been there at some point where we release a product and it doesn't quite work exactly like the way we expected it to work. What are some things you think that engineers engineering teams can do to prevent these failures from slipping through? Of course, we're never going to prevent everything but you know, what, what generally leads to a product getting released that still has some flaws, and what can we do to prevent that?

Daniel Servansky:

Well, I mean, first of all, we are all humans. You know, we're not perfect. We do our best and a lot of the work that we do is all risk based, you know work So that's why we have factors, safeties built into everything, or at least, hopefully, that we're designing things, a factor of safety is because a lot of the, you know, assessments that we do are all, again, based on theoretical, and not necessarily real world. And there's always a little bit of fudge factor in things that happened. But again, like, we do everything based on risk, it's all about understanding the problem at hand, understanding what risks do exist. And sometimes that really is, you know, like, we don't know exactly what the risks are, we have to try to figure it out. And, you know, modern 3d printing and stuff like that has made it so much easier to find some of those risks beforehand, quickly, mitigate some of those risks. But you know, it's our job as an engineer to make sure we are doing thorough diligent analysis of the designs we're putting out there. That's not to say, again, that mistakes haven't been made. I mean, it does just happen sometimes. But hopefully, through the testing that we do the verification, the validation of our designs, you know, really kind of catch all those flaws. You know, another part of it, unfortunately, is, I've been in a lot of situations where it wasn't my call to release a product or get a product out there was management's call. I've been in situations where I've had to make some tough decisions about, you know, how do I proceed forward, knowing that there may, this may not be how I wanted it to go out there, theoretically, could be problems here, we could see issues in the field. That happened, you know, sometimes in my sustaining work, because we didn't want to disrupt production, you know, it was all about making sure production keeps running, and how do we rationalize that this is going to be okay? That can be a very difficult situation to be in, that has come back to bite us quite a few times in the past.

Aaron Moncur:

I'm curious, during those situations, if you had to do over again, if the whole team had to do over again, based on the average results you get after the fact? Do you think the team would have decided? No, we really should have gone back and fix these things? Or on average? Is it? Yeah, it's probably okay to just move forward on some of these things.

Daniel Servansky:

It depends. Some situations ended up it really was okay. It really didn't end up being too problematic. Other situations, you know, we did start getting a lot of product coming back with issues that we sort of predicted would happen. And again, that that's like, you know, way beyond my call to say whether or not these are acceptable. I personally don't like the idea of putting stuff out where I know, there, there could be a known problem. I mean, I worked for Philips in the respiratory care division. And I mean, look at the hot water that we're in right now for doing exactly that, with their CPAP apps. Thankfully, I was not part of that team, I was not part of those decision making processes. But that just goes to show you how there can be a known issue, and you can bring all the data you want. But sometimes it just doesn't matter. And as a as an engineer, especially medical device engineer, that can be really difficult sometimes to deal with. Unfortunately, that's just part of part of the job. Another thing that I see a lot is, there's a lot of push for what's known as D effects right now. You know, the X being whatever you want it to be, it's supposed to be designed for whatever it's supposed to be a way. Yeah, exactly designed for manufacturing design for assembly design for quality. This was a big push in a few of the companies that I worked for accept all those things that x could stand for, it only ever stood for one thing and that was cost down. That that can be another reason why, you know product goes out with design flaws because you're inherently building it with something that is of lower quality. You know, one thing that I drove me crazy was this idea of moving away from quality vendors to cheap vendors, whatever, whatever we could get for the cheapest price possible no matter what it meant further down the line. It was always a short sighted investment. Essentially, we're going to cost out on everything now and what that means further down the line, no matter what data we presented to say that Haze is going to cause us a lot further, further down, we're going to start getting product coming back, we're going to have a lot of fallout in manufacturing. That x just meant for make the bomb cost cheaper than that was, that's another one of those that's tough to deal with. Because then usually, as the engineer, you're picking up the pieces and trying to make everything work again,

Aaron Moncur:

management who needs them, right?

Daniel Servansky:

It can certainly be frustrating at times.

Aaron Moncur:

Well, let me take a very short break here and share with the listeners that Team pipeline.us is where you can learn more about how we help medical device and other product engineering or manufacturing teams develop turnkey equipment, custom fixtures and automated machines to characterize, inspect, assemble, manufacture and perform verification testing on your devices. We're speaking with Daniel Servansky today. So Daniel in college, at least this was the case for me, I learned a lot of kind of theoretical knowledge, lots of formulas and equations, you know, like heat transfer this and fluid dynamics that in practice, how often do you find that you're using what Oh, call these predictive equations in your day to day job?

Daniel Servansky:

Well, the short answer is a lot. At least me personally, I'm using them all the time. I do a lot of upfront analysis, when it comes to design work, I try to do a lot of research and learn as much as I can about whatever it is that I'm going to be designing. And I run through tons of calculations. Excel is my friend, I have just tons and tons of spreadsheets, I've got notebooks filled with sketches and equations and formulas, and, you know, calculating this or calculating that. So I use it a lot. But the longer answer is, it really depends upon the project. I've worked on some projects where, you know, it was start to finish all theoretical, figuring things out, like I've done flow analysis, I've done thermal analysis for, you know, cooling systems and and figuring out, you know, how do we like in the oxygen concentrators is a compact box that's running the compressor that's making a lot of heat by compressing air and through the electronics, and how do we keep the whole thing cool. So there was a lot of, you know, heat transfer work in the air. When I was working in digestive health, there was a lot of fluid dynamics work there because I was working on feeding tubes and figuring out how do you get this thick goop that is the feeding formulas that are used through these small bore extruded tubes. But then there's been other projects that really didn't use a whole lot of theoretical at all. A lot of it was experimentation. I wish I could tell you about this one project I was working on. Before I joined Okta, den. Unfortunately, I can't share too many details. However, you know, it was roughly based on the Bernoulli principle, but all of it was experimentation and figuring it out. Yeah, so So it really depends upon the project.

Aaron Moncur:

Any any favorite equations? This is like the nerdiest question that can ever be asked by. But anything that you find yourself going back to a lot, I know it depends on the project. But any favorite equations that you use mechanics, fluid dynamics, statics,

Daniel Servansky:

I personally have always been a fan of mechanics of materials. So going back to my statics and dynamics equations, I think those are my favorites.

Aaron Moncur:

Fun classes. Yeah, I agree. All right. Well, you seem like just like the quintessential engineer, you have already accomplished a lot in your career, it seems like the amount of knowledge you have is impressive. From an engineering standpoint, you just you know how to do so many things. I have to wonder, do you work more than 40 hours a week? Because it seems like it would be difficult to acquire as much knowledge and experience as you have by capping yourself up off it at 40 hours a week?

Daniel Servansky:

Well, I'll start by saying that right now, I am in a company that values work life balance a lot. So I really for the most part can and do stick to my 40 hours per week. Occasionally I go over but for the most part, it's pretty much about 40 hours. That certainly has not been the case in the past. But my breadth of knowledge isn't necessarily because of the hours I worked It's really been more my desire to learn. I guess in a way, I've had a unique opportunity again, like graduating in the middle of the recession, I sort of had to bounce from job to job just to stay employed. So I got a little bit of a lot, a little bit of a lot of different kinds of experience, and a couple of years. So I got exposed to a lot of different things. But a lot of it also comes from the fact that I never stop learning, I never want to stop learning, if I stop learning, then I'm not doing my job as an engineer. So, you know, I spend a lot of time just learning, reading, doing learning by doing. And that's where a lot of my experience has come from. Now, as for working hours, like I said, in the past 40 hours a week hasn't necessarily always been the case, when I first started out, you know, young, not married yet, I worked a lot of hours, because I enjoyed it. And, you know, didn't have a whole lot else to do. So, you know, I learned as much as I could, in those early days by sticking around and doing and, you know, just I would literally walk up to other engineers just be like, Hey, what are you working on, just kind of curious. And I'd end up in, you know, hour long conversations about what was going on, and what they were doing and what challenges they were having and how they were going about fixing them. But then, you know, later on, I got married and ultimately had kids and, you know, working more than 40 hours a week was not always an option. Though, I have to say, a lot of times it feels like it's required that you work more than 40 hours a week, it's not necessarily a written role. It it's an expectation set by management and by your peers. One thing that happened a lot was the expectation that you were always on call. And if an email came through with a question, you respond to it, whether it's, you know, you log off at five, and it comes in at 5:30, or you log off at five and

it comes in at 10:

30. The expectation is that you're going to answer it. So, you know, that's definitely working more than 40 hours, I know, there's been plenty of times where I'd come home from work and I said, you know, I've got this deadline, it's really clamping down on me, I just need to, you know, after dinner, I just need to go work for another hour or two, just to knock this out and try to get it done. And that's certainly working more than 40 hours. I think the worst though, was when I was working at how yeard, which was the Kimberly Clark spin off, I was part of the largest cost project in the history of that company. And it was, you know, we were pioneering a new technology and a new method for assembling this medical device. And it was really cool. But the expectations from management were really high. I was there was a point there where I was consistently working 60 plus hours a week, I was putting in 12, 14 hour days, every single day, I would you know, do five or six hours of my desk work. And then I'd head down to the wall, we actually had a miniature production line in the basement of the building for doing kind of prototype work. And I'd spend the next, you know, six, seven hours down there with the production team trying to get this product production figured out. And that was consistent. And you know, even with putting in that many hours, you know, who can say that we're not putting in our work and management was still pushing like, why isn't this done? Why isn't this working? What are you guys doing? We're we're giving you all this equipment, all this money? Why isn't this working? And so there was this constant pressure of you need to do more, you need to do more, you got to figure this out. Why is this taking so long? But again, thankfully, that's not the case for me anymore. And unfortunately, no, it's still the case for a lot of people. And for those people, I really hope that they they are able to find a company that values work life balance as much as OCTOdent does.

Aaron Robison:

it, Daniel, between this conversation right now or that that comment and the dfx conversation? I certainly hear a lot of maybe pain from your career, and some strong biases, you know, based on how things have been lived out in your life. If you were to choose something to design and accompany you know the way that it's run maybe on how processes are run or how to prevent failures or launch products or how to control you know, how much pressure there is to spend a lot of time what what's something that you would design differently about a company

Daniel Servansky:

that, you know, if I were running my own company and able to kind of build things from the ground up. I think one of the most important things that I would ensure was true, was that what we say as a company, when we say we value as a company was true, it wasn't just, you know, it wasn't just to make us sound and look good. If we said that we put the customer first we put safety first, that we actually do it, that we say that we value our employees, and we want them to have a good work life balance, that we do it. I think just building that culture of MIT taking a stand and actually standing by it is one of the most important things that I could implement into any company.

Aaron Robison:

Do what you say you're going to do? That's what you like. Yeah, great.

Aaron Moncur:

I don't disagree with that at all. Daniel, I'd love to hear a little bit more about that. Why do you feel that's the case?

Daniel Servansky:

Well, that's not been the case, at a lot of places where I work. You know, like, you know, I'll go back to the, the Philips recall thing right now, that was, you know, for years and years, Philips mantra was patient safety and patient first, always, and that is 100%. That was not the case that it was, well, if we actually implement these changes do you do like, it's going to cost a ton of money, and we're gonna have to go back and replace all these devices. And we're gonna have, you know, that it was about bottom line, the whole time, it wasn't about patient safety. You know, that's, unfortunately, just the way a lot of companies work. You know, there's, there's a lot about also, you know, the, the talking about having great work life balance, but again, when it comes down to it, the expectation is that you're available when you're needed, whether it's, you know, your working hours or not. And a lot of companies will say, well, we don't operate that way. We don't ask our employees to be on call after hours. But the fact of the matter is they do it. That's what is communicated through management, maybe not by words, but by actions. And actions are just as loud if not louder than words. So whether or not you say you have that type of company culture, the way that the management and the other employees act and behave, speaks more about what the true culture is.

Aaron Moncur:

And when that incongruence does exist, it probably fosters some level of resentment among employees, I would I would guess, it almost might be better for a company to say, Yeah, we expect our employees to work crazy hours and be on call all the time. And just own that, then it would be Oh, no, we're good with work life. We want everyone to, you know, take it easy and relax. But oh, no, this weekend, you got to work the next weekend, you can hang out relax with your family this week, and you need to work. Right? Right. Yeah, that's a difficult topic, I, I fully understand both sides of the coin there. You want the patient to come first. But you also need to make sure that the company is profitable to continue producing devices that will allow the patient to be safe. So like, how do you draw the line? Sometimes? I just recognize that that's a complex question. Without an easy answer. So of course, yeah. Let's see just a few more questions, I think and then we'll, we'll start wrapping this up. It feels to me often, like I spend so much time trying to communicate with with other people, whether it's community communicating the scope of a task to someone, or the scope of a project to a customer for quote, that we're putting together a presentation, whatever it is, so I, I wish I could just take what's in my brain and put it in someone else's right, but I can so I painstakingly write emails and I have phone calls and I join meetings and, and, and do all these things. And is there what is one way that you've found to effectively communicate what's in your brain to someone else in as little time passed as possible?

Daniel Servansky:

Well, yeah, communication is certainly one of the most difficult things that an engineer faces. You know, we are a unique breed, we think and communicate in a way that's different than any other person out there. But I mean, you know, there are a bunch of different communication styles. I personally am a very visual learner and communicator. And I've found that That is one of the most effective ways to communicate in general to anybody. And it's all about knowing your audience more than having the right the right particular information in the way that you communicate. But that visual tool is really the thing that I found that works like 90% of the time. My go to is usually PowerPoint. Because I love PowerPoint, its great, because you can throw pictures with arrows in there, you can throw videos in there, you can throw charts with data. And the thing about it is color is king. When it comes to PowerPoint, it is such a powerful way to communicate important things to your audience, whether it's you highlight a particular word and a different color, you highlight particular data in a particular color. You want to draw the person's eye to the most important thing on that slide. And of course, you don't want to overwhelm the slide with information. But knowing who your audience is, and kind of tailoring the, what you're trying to communicate to that particular audience and using these key elements has, more or less been a surefire way to get my point across, I have convinced so many people have so many different things that otherwise would have felt like a daunting task through verbal communication to try to get them on board with because they can actually see like, what's happening, they can see like, when you highlight this particular set of data is like, Oh, wow, you're not kidding. That's like that's hugely different. Or when you're highlighting like, this is bad, you we need to fix this, like when you highlight that particular word that just draws their attention to bad, or something like that. It's just such an effective way to communicate.

Aaron Moncur:

That's great. I love your focus on color there. I had a manager a long time ago, I worked with who you know, every now and then you get an email from someone and they're like, I don't know, half a dozen different bullets or items that they want you to respond to. And he was he would always respond in a very specific color in line with, with all of their comments. And it just made it really easy to pick out where his comments were in someone else's comments where so color is a big thing. And PowerPoint, you know, gets a lot of slack. But I haven't found a like a better general tool than PowerPoint for communicating a lot of the stuff I think you're you're spot on there.

Aaron Robison:

So maybe another question for you changing topics a little bit. What role have you seen intellectual property play in engineering? And how big of a deal has it been, in your experiences at different companies?

Daniel Servansky:

My experience has been that IP is very different from company to company. I mean, generally speaking, everybody wants to protect their ideas. You know, so like the I've worked for a few startup companies. And so they've been very careful about what they pursue in terms of patent because of patent is not an inexpensive thing to pursue. But at larger companies, I've also seen kind of the exact opposite, where patents are used as strategy and not necessarily for protecting their particular intellectual property. Whether it be there's a product on the market and you want to, you know, you're trying to create a competitive product. So you're going to want a patent around whatever you're designing so that the other company can't expand to that. Or alternatively, I've seen it some times where we've generated IP around an idea that we never had any intent of commercializing, just to box another company in to being stuck to the idea that they already have, and they can't necessarily improve upon it or expand upon it. So larger companies have the bandwidth and resources to be able to do that kind of IP work. A couple of companies I've worked at intellectual property has been incentivized, and other companies I've worked for it's been, you know, they actually kind of pushed away IP as like, this isn't something important we need to worry about. And then, you know, some of the companies I worked for would literally take any idea you had and run it past the attorneys, as is this something we could possibly patent, whether or not it has any use for what we're currently doing or any particular product we have in mind for the future? Is this something we could patent? So it is so vastly different from company to company and what their particular strategy is?

Aaron Robison:

Yeah, I've seen something similar and also from Engineer To Engineer, and how closely they get involved with patent attorneys. Sometimes they're working side by side constantly. Other times it's kind of throw it over the wall. It sounds like you've worked pretty closely with the patent attorneys. Is that correct?

Daniel Servansky:

Yeah, it is. I actually enjoy working with the patent attorneys. I've had quite a few and they've all been wonderful to work with with, you know, typically a patent attorney was an engineer at one point in their life. So it's good, you know, communicating with a patent attorney is a little bit easier than communicating with more of a general attorney, they, they kind of get what you're talking about. But I've always had a positive experience with them. And, you know, it's, it's been good, I always try to, you know, limit what I am, you know, seeking protection around to things that I find to be useful. You know, I'm not necessarily the one trying to, you know, box someone else into a particular design, though, you know, it's happened in advertently, at times. But generating IP is actually something I quite enjoyed doing. It's, it's, it can be a little bit tedious at times writing out, you know, disclosures and, and going through the different ways that this project could be designed or different combinations of features that could do different things. But I actually enjoy doing that.

Aaron Robison:

So we're getting close to the end here, maybe kind of a little bit higher level, can you share one thing within your role as an engineer, you've shared a few, but when you're bogged down, what's something that's really frustrates you? But conversely, what's something that really brings you deep joy?

Daniel Servansky:

Well, the frustrating one, we've kind of talked about this a few times. And I would just say that it's not so much like any one particular thing, it's just when the business gets in the way of innovation or making quality products, whether it's management or business cutting a project for, from an engineering standpoint, seemingly no reason I'm sure there's, you know, well thought out business reason for cutting particular projects. But it can be really frustrating when it feels like you're working your innovation is being stifled by some overarching plan that the business has that you know, really get or understand or privy to the information.

Aaron Robison:

If I could take what you said, or throughout this part of this recording of the podcast, you just want really clear input to you as to why something's happening or not happening. If you have a value live by the value. I mean, that's what I'm really hearing from you is let's just be straightforward.

Daniel Servansky:

Exactly. That's, that's exactly who I met at, you know, that's my personality is, you know, I'm honest with people, I expect people to be honest with me. And and, you know, that's not always the case, when it comes to businesses or, you know, it's maybe it's not necessarily that they're intentionally lying, but they're kind of hiding information and hiding, you know, what the long term plan is, for whatever reason it might be, that can be irritating at times for sure.

Aaron Robison:

What else? What's brought you joy?

Daniel Servansky:

Yeah, I was gonna say now, on the flip side, what's brought me joy is and you know, I've talked a lot about things that have been frustrating through my career. But I do want to just say that, generally speaking, I've really loved being an engineer, for all the time that I've been an engineer, it brings me much more joy than it brings me frustration. But that one moment that is better than anything else, is that first time that your prototype of whatever you're making gets placed in your hand the first time you can hold it, look at that physical thing. And think, man, I created this. And even if it doesn't work that first time or the second time, or however many times it is, you still learn so much from that physical thing being placed in your hand. And that I think that right there is the moment that I love the best as an engineer, at first time I get my hands on and think, Wow, this is really cool. Especially when it works the first time. That's just icing on the cake.

Aaron Robison:

Yeah, I agree with you. That's I experienced the same thing when you've designed something, tested it done analysis, whatever, and it's there in your hands. For some reason, the act of creation is really powerful. Yeah. Well, maybe to wrap this up, Daniel, how can people get a hold of you if they'd like to reach out to you?

Daniel Servansky:

Well, I am on LinkedIn. They're welcome to touch base with me on LinkedIn. I also have a professional website at Dservansky.wixsite.com/intro

Aaron Moncur:

Amazing. Daniel, thank you so much for hanging out with us today. This has been a lot of fun. What a pleasure. It's been to get to know you and learn about some of your experiences and backgrounds. And thank you so much for sharing your time and your insight with us in the the being an engineer audience.

Daniel Servansky:

I really appreciate you giving me this opportunity reaching out to me. It's been fun. I hope that I've been able to provide some insights. And, you know, I'm definitely going to tune into these moving forward.

Aaron Moncur:

Awesome. Appreciate it, Daniel. Thank you.

Daniel Servansky:

Thanks.

Aaron Robison:

All right, take care.

Aaron Moncur:

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 turnkey equipment, custom fixtures and automated machines and with product design, visit us at Team pipeline.us. Thanks for listening