With over 24 very sincere recommendations on his LinkedIn page, it is clear that Rob’s teams over the years have loved working with him. Join our conversation as we explore how he has developed these loyal teams, as well as how he has helped hardware and software engineers work together to develop new products. Rob’s current role is VP of Product Development at Cubex, LLC.
Pipeline Design & Engineering partners with medical device engineering teams who need turnkey equipment such as cycle test machines, custom test fixtures, or automation equipment but don’t have the bandwidth or resources internally to develop that equipment. You can find us on the web at www.testfixturedesign.com and www.designtheproduct.com .
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
With over 24 very sincere recommendations on his LinkedIn page, it is clear that Rob’s teams over the years have loved working with him. Join our conversation as we explore how he has developed these loyal teams, as well as how he has helped hardware and software engineers work together to develop new products. Rob’s current role is VP of Product Development at Cubex, LLC.
Pipeline Design & Engineering partners with medical device engineering teams who need turnkey equipment such as cycle test machines, custom test fixtures, or automation equipment but don’t have the bandwidth or resources internally to develop that equipment. You can find us on the web at www.testfixturedesign.com and www.designtheproduct.com .
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
Welcome to the Being An Engineer Podcast. Our guest today is Rob Newsom, who is Vice President of Product Development at Cubex, where they develop software and hardware to manage controlled drug access within their proprietary inventory system. Rob has served in many roles over the years, including systems engineer, software engineer, R&D manager and director of software development. Rob, welcome to the show.
Rob Newsom:Thank you. Glad to be here.
Aaron Moncur:All right, I'll start with the same question I ask everyone, how did you decide to become a software developer?
Rob Newsom:Well, I grew up in Florida about 60 miles from the Kennedy Space Center or Canaveral Space Center, whatever it's called today. And so like, every boy, my age, in that area, we all wanted to be astronauts. And eventually, I was just very attracted to to sort of the logic and the engineering and the science that went into everything. And not having a lot of resources at my disposal for a lot of hardware projects, I just naturally gravitated toward software development, where the entry level was a little bit easier. And also, it was a very new field at the time, and just just sort of fell into that liking the, the intellectual stimulation there. Also, I was fairly introverted, so I didn't gravitate toward a lot of people areas, if you will. And so software development just seemed to fit very well for me.
Aaron Moncur:Introverted is something I hear a lot from engineers, including myself, I am happiness when I am in a quiet room by myself. So I apologize, I'm going to date you just a little bit here. But when you you started getting into software that was in, what, the'70s, maybe?
Rob Newsom:That was in the'70s. Yes.
Aaron Moncur:Okay. And what were the tools like back then? I mean, if you're getting into software today, there's so many ways you can do that. What, what was it like them?
Rob Newsom:Yeah, the tool tools were pretty limited, I really didn't get a chance to really do anything. This, this was pre Apple days even, didn't get a chance to do much on my own until I went to college. And at that time, got exposure to some mini systems called PDP. I don't think PDP is around anymore, but PDP systems and then and then also, in our labs and our physics labs, we had Apple some Apple IIs. So got into into using the Apple II, which is basically doing 6502 assembly language and Apple soft basic, which was just a form of basic language.
Aaron Moncur:That's interesting that you were working with with the Apple ecosystem back then. Apple wasn't so prominent as it was now what what major department decided to go the apple route instead of the, or maybe the PC wasn't really even born yet.
Rob Newsom:The end, the PC wasn't around the around yet. So so everything was on PDP systems, the PDP, mini computer, which everything in that case, of course, was all text-based, it was all green screen. We also actually had teletypes. And to do anything with color, you had to have special permission or be part of the physics department, which I was at the time to get access to the Apple IIs and what what the physics department, there was one particular professor that was very interested in micro electronics, so I was taking micro electronics classes. And in order to actually work with boards and stuff and use Apple II, also had some very small breadboards and processors that we used for very simple things just just for learning.
Aaron Moncur:Interesting. Okay. So your first I think it was your first job out of college. In 1989. You were developing DOS based compilers.
Rob Newsom:Yeah.
Aaron Moncur:What what was, what was it like back then when software was maybe this isn't an entirely accurate way to say it, but to some extent, kind of still in its infancy. You know, what were some of the challenges back then that that don't even show up on the radar today?
Rob Newsom:Yeah, the tools were much cruder of course. So being done Essbase meant you didn't have multiple programs open. I mean, you stayed in one environment pretty much the whole time. So I actually was a little bit fortunate I missed the very, very early days. So the development group I worked with, they had actually developed a text editor. And we used our text editor, which was called editor to write our own software, and then eventually, and compile it with a compiler called wizard C, which eventually became Turbo C, which was part of Borderlands portfolio, that they had the first real major language after basic called Turbo Pascal. And then eventually, we moved into using Microsoft C. And that eventually became Visual Studio and the more advanced tools, but the original tools, you know, there was no text highlighting the syntax highlighting no help with functions or anything, you you had to do it all yourself. And all the structure of the programs was all done yourself, you had to be very organized. Everything was pretty much done yourself or with what other developers you were working with. So all the structure, all the help that you needed, you had to find the right resources. Our editor was a fairly advanced editor, and that you could have more than one document open all the time. So that assisted in searching things like functions and things like that. But yeah, it was a much slower pace, just because the type of tools and yeah, you really had to to be very structured and very organized in your work.
Aaron Moncur:Did it? Did it feel like it was a slower pace? Or was that just normal? And that's kind of how everyone did things, so it felt fine?
Rob Newsom:Oh, it felt fine. It was great. I mean, you know, loved it. But But of course, looking back, there weren't libraries that you could just use and things like that back then. I mean, there was a standard C library. And that was about it.
Aaron Moncur:Well, nowadays, we're standing on the shoulders of giants, aren't we?
Rob Newsom:Yeah, absolutely.
Aaron Moncur:Yeah. Okay. All right. This, this is a amateur hour question here. Is there a difference between an application developer and a software developer,
Rob Newsom:In my mind, as a software developer is a little more broad based. So application developer stays just on applications or applications that are used strictly by people, whereas a software developer tends to think a little bit deeper, and can also be making, say, programs that that run on a schedule or behind the scenes without any human interaction, that type of thing. So software developer tends to think a little bit broader based. That was sort of the original term for everybody. And then And then things kind of became segmented into applications developers or systems developers or solutions, architects, you know, architects type things and designers. So things became a little more specialized in the last, say, 20 years or so.
Aaron Moncur:Okay. Now, you you're a Certified Scrum Master?
Rob Newsom:Yes, that's correct. Yes.
Aaron Moncur:Yes. Can you share a little bit about kind of what Scrum is what that process looks like how it's used, and maybe like some of the pros and cons?
Rob Newsom:Sure, sure. So Scrum is a form of agile development, which can be applied not only to software, but to other other disciplines as well. And agile development, it basically arose from, you know, originally, software following software development followed a very waterfall technique. In other words, you did all of your requirements gathering, and then all of your design specification, and then, and then you actually began doing some coding. And then once you finished coding, when you did testing, everything was very stepwise. And what eventually people figured out was that, you know, by the time you got to testing the industry, or the market may have changed or something happened, or some new technology became available. And so you'd have to go and restart all the way back from the very beginning and change your requirements. And then, it was very laborious process.
Aaron Moncur:And that's gust because software and technology were changing so fast back then that six months after you start things might be entirely different.
Rob Newsom:Exactly, exactly.
Aaron Moncur:Okay.
Rob Newsom:So the agile methodology started and there was all various different forms of it. Scrum is one one form of agile and essentially means developing an iterative process. So don't try and design the entire system upfront, do small portions to get them completed to the next portion, get it completed, then if you have to change directions, you can change. And so of course, it gets harder to change the farther down you go or the farther you go. But still, you have a lot more flexibility. So So typically what scrum means is it's it's organized into different types of people, people that actually do the work, whereas people that are interested in the work, if you will. And the the idea is to keep the teams small and keep the the sprints, as we call them, where the iterations down into very short increments, typically somewhere between one and four weeks, we usually use two weeks, we find that that's usually enough time to get something done and also enough time to be able to change directions quick enough. And the idea is that you lay out what you're going to do for the next couple of weeks. You get it done. It's a complete session. In other words, testing and documentation and everything is done within that two weeks. And then at the end you have you review it you have a retrospective to see what you did what you've missed what needs to fall over into the next sprint, and then you organize the next sprint and go for the next two weeks. And in doing that once it takes a take some time to get used to doing it. But once you get used to it, you tend to think of projects in terms of number of sprints. And and then you can lay out the goals and the milestones based on the number of Sprint's one particular milestone may take three sprints, one may take one when they take five, something like that. And so it begins to make the development process more predictable. Not only agile, but more predictable.
Aaron Moncur:Very interesting. I'm the the scrum process is something that I've started looking into just really rudimentary level four for my company, Pipeline. And as someone who has worked, you, Rob, is someone who has worked in both software and hardware environments. Do you feel like the scrum method can work as well for hardware development as software? Or is it best suited towards software?
Rob Newsom:I think I think it works well for hardware, maybe not quite as well as software but works very well. I've actually seen it used in schools in all kinds of disciplines. Software course works very well because software is very changeable. In hardware, I've seen it used in in breaking down of course, we build cabinets. And so it's natural to break down things of okay into a zone or into how the cabinet moves or what the power situation is the cabinet and focus on those things in a stepwise way. Hardware, you have to be a little bit more careful because some of the lead times on stuff where for for example, if you need plastic molds made, you have to do usually do those type of Sprint's earlier in the process. So they show up at the same time. And and and it tends to work pretty well. The main thing, not so much as the the Agile nature of doing Scrum, but more in the predictability. So so it's much easier to predict timelines by using an iterative method like Agile and Scrum.
Aaron Moncur:That makes sense. So for anyone out there that's that's interested in exploring Scrum. Are there any most of the people who listen to this are probably in hardware development? So for those individuals, maybe they're interested in learning more about Scrum? Are there any any downsides that we should be aware of, particularly when it comes to hardware?
Rob Newsom:Yeah. Well, one of the downsides in general is it does take some time to get used to how to do the process. And I tend to find that each organization will do things slightly different, they'll modify the process a little bit to fit their organization. Obviously, if you have a very big company, you can hire the exact people to be the exact fits that you need. But in a small company, you tend to mold the process. Like a scrum master may be a project manager sometimes or it may just be, you know, a mechanical engineer or sometimes usually you want the scrum master, the guy that runs the meetings, to be the person that is best suited to remove roadblocks from the project. So, so that's, that's in general. In hardware itself, I think it's best if you have some experienced people. It does. The whole team doesn't have to be experienced but experienced just because they can And intuitively know some of the lead times on some of the some of the pieces like I said making molds or it could be getting metal fabricated. You know, they have a general idea of what that lead time is. And so they can more easily lay out where those sprints should lie and where they should focus on first as opposed to toward the end.
Aaron Moncur:Okay, so when you say it's good to have some inexperienced involved, you're not necessarily referring to experienced, I'm sure this is a plus two, but not necessarily very experienced with Scrum, but experienced in the manufacturing process that you're involved in the particular design process.
Rob Newsom:Yes, exactly. Exactly.
Aaron Moncur:Got it. Okay. Okay. All right. So one of your roles was overseeing a remote team, I think it was in Romania, some time ago. And we sometimes work with remote engineers that pipeline, usually it's fine. But once it comes time to start building hardware, it can be problematic. Is software just as easy to develop remotely as it is in close proximity? Since there's no hardware involved? Or are there still some some pretty significant challenges with remote software development?
Rob Newsom:It kind of depends. If you have a large enough organization where you have sufficient documentation, documentation becomes more important with software development done remotely. Just because the the exactness of the language makes a difference. So if you're, if you're working next to the guy, it's very easy just to ask the question immediately, you know, and get clarification, you know? When you said five, did you mean five millimeters or five inches, it's very simple to get clarification like that. Whereas working like with Romania, they were typically nine hours ahead of us. So a simple question like that would take an extra day to get answered, just because just because of the timeframe. Also, the language makes a big difference, you should always try and find someone that that has good language skills. And it's not just just English, for US English speaking people, it's also do they understand what you're talking about, when you say, you know, you know, make a call to a function, do they understand what they mean, when you say call a function? That type of thing. And the, what I find works best, especially with software, is if the remote team actually has a person that is local with you. So when working with an Indian team, what worked very well was we actually had one of their team members, another Indian person that also spoke the language, they would work the mornings with us here in Phoenix. And then they would go and take care of their kids or take a nap or whatever it was. And then they would start working again around nine o'clock at night and work directly with that team. So they would be the person that would actually do almost all of the direct communication. That's a great strategy. And in doing that, it meant that there was far fewer surprises. You know, usually surprises are negative and doing projects, but and things just flowed much quicker with that. And that person does become very important. So it's important. So we would have a daily meeting with our team, our daily Scrum, and then they he would have he would go and happen to be a guy. He would go and have his daily scrum with the team in pruning, for example, or somewhere else or in the case of Romania, it was in Tina short. With the Romanians, we did not have that luxury, so it did not work out as well with them. It worked better with the Indian. So
Aaron Moncur:And that was mostly because you had this this, I don't know, I call him a facilitator.
Rob Newsom:Exactly, exactly. And the other thing you'll find out is working with other cultures as they they tend to gravitate toward different things like the Romanians all tended to be exceptional at math, and, and exceptional and quality assurance. So over time, we started sending those parts of the project to them, whereas we worked more on what the user interface should look like or maybe the database calls and that type of thing. So it takes a little bit of time to get used to the culture. Then with Romania, I found that it was very good that if I actually went over there at least once every three months, just to just to say hello to the people and just walk around and be around the building. And they may have some questions that they were afraid to ask an email or whatever, just just to put some faces there. So
Aaron Moncur:That's a great strategy. Something I hadn't heard of before, but very useful. You'd worked with a company called it I'm not sure how to pronounce this. Is it O-C-E? Or Oce Reprographics?
Rob Newsom:Yes. Oc Reprographics.
Aaron Moncur:Oc Reprographics. Okay. All right. And so in the beginning of your career there, you let a team of eight, which grew to 16, and then to 30. And then if I did my math, right, looks like over 75. And that was a combination of mostly on site, but also a sizable remote team, as well. How did your management and leadership style evolve as the team over which you had responsibility grew?
Rob Newsom:Well, fortunately, everything was very technical. So that sort of fit in with with with my interests. As the team grew, I was lucky, maybe good, I don't know, I had, I had some very good leaders, not necessarily managers, we really hesitated on calling people managers. And so it was, it took me some time to figure out the right sort of balance of delegation versus what I should take charge of myself. And I tended to be around those leaders that I had, almost constantly. So I'd see them pretty much every single day and see what their roadblocks were, where they were going, were they on the right track.
Aaron Moncur:And the leaders that you have, these are kind of like the I don't know, project managers or project leaders within that group?
Rob Newsom:Yeah, yeah.
Aaron Moncur:Not your leaders, not your executive leadership team above you?
Rob Newsom:Correct? Correct. Correct.
Aaron Moncur:Got it.
Rob Newsom:My own leaders, we were, we were pretty autonomous. So so the company was owned by Jose technologies BV out of the Netherlands, which wasn't too bad, because pretty much everybody in the Netherlands speaks English very well. And the communication is good, and that sort of thing that for That, that makes me think a little bit of anecdotes here easygoing people as a culture. And so being separated by 1000s of miles, and about eight to nine hours time difference. We were pretty autonomous. So we were given some directives, I did meet my boss about once a month, whether it was going to Romania or him coming here. And we talked weekly on the phone to see where we were. But Oce was a very large company. And they had a very strong structured project management system. Being a hardware company, they made printers and scanners, wide format, printers and scanners. They were they had that sort of waterfall mentality. And so so we were kind of the, the the wild and crazy cowboy Americans over here doing this agile stuff. But but the results were good. And so we were kind of left alone, along that that path. So so my leaders that I had were all very technical in nature, they had all either been software developers, or quality assurance engineers, or some type like that, that had that had some level of people skills and some level of organizational skills. And I relied on them heavily. And again, I met with him informally every day. And we met very formally on a on a weekly or bi weekly basis, also with some people from the Netherlands or from Italy, or Germany, wherever, whatever was involved. And, and developed a pretty good product and portfolio management system. And that we really, at the high level, we really never focused on anything except the either the end goal or any issues we were having. So we did not do you know, status updates. Like, Jim did this today or this week, I didn't care about that. We would focus on we're having a trouble with this, how do we fix this problem? Or where are we in the tab? Do we need to communicate that we're going to be late or early? Or do we need some additional help in some area? Do we need to have a technical writer or a translator? We actually had translators come over from Europe to help us translate our software into various languages. So it was really about problem solving, which of course, really fit my engineering mentality. So today where like every kid on the team gets a trophy but back back then you guys weren't patting yourself on the back for we did this today. We accomplish that last week. Nope. Forget about that. No one gets a obligatory pat on the back. Let's just focus on what the problems are and high level what we're trying to get accomplished. Right? Exactly. Yeah.
Aaron Moncur:Love it. All right. Well, let's take a quick break here and just share with the listeners that the being an engineer podcast is brought to you by Pipeline Design & Engineering, where we work with medical device engineering teams and the turnkey custom test fixtures, automated equipment, or product design support. And you can find us at testfixturedesign.com and at design.product.com. We're speaking with Rob Newsom today, who is the VP of Product Development at Cubex. You can learn more about the his company at cubex.com, C-U-B-E-X dot com. Okay, so Rob, over the years, you've interfaced with hardware engineers, and of course, software developers, what are some of the the challenges that you've had, as a software engineer communicating with hardware counterparts? And how can these two types of engineers kind of enhance their communication?
Rob Newsom:That's very good question. Of course, we're all engineers at heart. But software software engineers tend to be a little less organized, I want to say to put it bluntly, so software software engineers can be very distractible or, or very much chasing the latest thing, whereas hardware engineers tend to be a little more discipline a little more of, let's get this particular job done. On the other hand, a software engineer when when they see a problem, they tend to look at it a bit broad more broadly. So a hardware engineer, you know, someone says, 'I need a light here.' A hardware engineer says,'Okay, I put you a white light there.' Well, a software engineer may think, 'Well, we should put an RGB light there, that way we could do white line, we can do blue line, we could do red, we could do green.' So so they tend to be a little bit broader thinking, and there's good and there's bad
Aaron Moncur:So maybe some complementary skill sets is what I'm hearing.
Rob Newsom:That's, that's exactly right, exactly right. Part of it. And I find this just in working with other cultures, like working with Romanians is, is just just being in their shoes or being with them for some time, you start to understand how they think and how they act, and then you naturally gravitate toward working well together, almost all the time, there are some occasional instances where they don't necessarily work well together, but usually just working well, you tend to you tend to see, 'Okay, this is how they're thinking, this is how they're looking. I understand that, let me see how I can complement that.' So that that tends to work very well and over time, you find the software engineers tend to become more disciplined and organized. And the hardware engineers tend to be a little more broad minded, if you will, kind of a converging of, of the different roles, and the different cultures that those roles attract. So that's, that's one thing is just almost have to force the people to work together. Even if they don't like it, the software engineer is going to go, 'Oh, the hardware guys are so slow, they have to plan everything out. And the hardware guys on the software guys, they're off doing all kinds of crazy stuff, chasing wild things.' But over time it gets it gets better. And that's probably the best way to do it. If you have a time crunchy, you sort of have to force that. And, and, and, and part of it is you just may have to remind people, you have to remind the software guys, you know, hey, these hardware guys, they're dealing with long lead times on things they have to deal with a lot of third parties to procure parts and stuff. And so you have to you have to be patient and see that, you know, they need a high level of documentation, or they may need extra amount of time to do this type of thing. And same with the hardware guys. She said, 'Okay, the software guys, they see things a little different.' You know, that when they say, 'I want a wheel,' you know, it's not necessarily any type of wheel, they may be thinking a bit too broadly. So help them narrow that down to help you find the right part that you need, or design the right part that you need. So it's a lot of it's just about communication.
Aaron Moncur:As so many things in life are. But that's that's great advice. Thank you for sharing that. What are one or two of the challenges that that you see at work, what are the things that keep you up at night? What are some of these recurring things that that just seemed to be problematic that that you've had to deal with in your career?
Rob Newsom:Well, I think I've always gravitated towards smaller companies. And with smaller companies, there can be some different challenges. Usually the the challenge is funding, you know, usually don't ever have quite as much funding as you'd like to have. And because of that, people tend to wear many hats. So so for example, right now, we don't have a true project manager. So that means someone else has to do some of that project management, and they're probably not going to do it very well. But they're not a true project manager. So you have to, you have to live with a bit of compromise. In those other kind of disciplines. The the other, the other thing you have to realize is that, you can't just always do exactly what you want. You know, there are always other factors to think about, like, as an engineer, I tend to think of solving problems, almost always in an engineering fashion. Whereas for the good of the company, it may be better not to spend the money and solve it in an engineering way, but solve it in a more organizational way. So it may be that we don't have to develop a cabinet that actually is on wheels and has motors and will drive itself and mount itself in the proper place. We could actually pay a delivery person to actually go into the, a dolly and put the cabinet in the right place. So you can do things, you have to realize that there's areas broader than just engineering that you don't have to solve everything in a technical fashion, there are some other ways to solve problems. So that that's taking me a number of years to realize, and, and I have to remind myself of that, quite frequently
Aaron Moncur:Well, attacking problems that are more broad fashion, that sounds, spoken like a true software developer, based on what you just said.
Rob Newsom:Yep.
Aaron Moncur:I read several recommendations that have been given to you on your LinkedIn page. And by the way, you have 24 of them, which is far more than I have ever seen. I mean, I see two or four, maybe six, yep, 24, which I thought was just astounding in itself. But but maybe equally or more interesting was the message that I read over and over was and I might embarrass you just a little bit here but was what a tremendous leader you are. Some of the words used to describe you were approachable, puts you at ease, light and fun positive attitude integrity candor friend, not friendly, but friend, which I thought was really interesting, savvy, calm, humble, fair, fair, kind of the list just kind of kept going. It was really clear that, that people genuinely like working for you. How have you been able to foster such loyalty of the people who work for you? And maybe what suggestions would you give to to other managers or leaders out there so that they can build impactful and rewarding team relationships like you have?
Rob Newsom:Well, I think a couple of things, I think, I think, first of all, one of the best pieces of advice I ever got was from one of my mentors, who happened to be happens to be an Italian guy. And he said every morning, of course, he's Italian, so he has a bit of a way of expressing himself. Every morning, make sure you look at yourself very hard in the mirror, you know, very hard every day. And what he was saying was not how you look. He was saying look at look at yourself as to what your strengths and weaknesses are what you like to do, and not like to do really try and know yourself. So so if you really know yourself and you try and present that to your team, you become more genuine and that and that's extremely important because if you're not being genuine, people are going to pick up on that. And then the trust will waver and die eventually, and that was never good. So that's probably the most important advice is really know yourself, know your strengths, know your weaknesses. Of course, you want to work on improving your weaknesses. And you know, one of my big weaknesses, of course, was the introversion that I experienced and I've worked on that very hard throughout the years ticket ticket over that. And then the other ways is, is really take a genuine interest in all your people's lives. Know if they have kids, know if they have teenagers, know what they like to do, what they don't like to do. Really take a genuine interest in them. Don't just feign it because if you feign it, it'll, it'll come and go. And you may have a large number of people. So you may not be able to spend a lot of time with everybody, but spend some time with them, not just on work stuff, but on other things. And then the the other thing is, is when when you're not going to know, everything that everybody does, like, I'm not, I don't know how to use how to how to write SQL queries near as well as some of my guys. But I've taken enough of an interest that I understand it to a certain level. And that's all I can expect. And that's all they can expect, as long as you can talk with them on a on a reasonable level, they'll have respect for you, and they'll like you, and and really just be genuine.
Aaron Moncur:But I really like what you said about being genuine. I have a mentor, not Italian from New York. And he, he said to me, in terms of communicating with others, take what's on the inside, put it on the outside and talk about it. And and what he meant by that was, you know, every now and then you're going to be speaking with someone, you're going to be having a conversation. And just due to the nature of human interaction, there's going to be something on occasion that doesn't feel quite right. Or maybe you're unsure about. And all too often I think we kind of suppress those thoughts, or we don't vocalize them anyway, we don't share them for a myriad of reasons. Maybe we feel like,'Oh, I'll sound dumb if I bring this up. Or, or maybe I'm going to give something away strategically that I shouldn't,' or whatever the reason is, And his point was was, you know, there's no, but the most effective way to communicate with someone is is to be open and transparent and honest. And I've found that to be so true. And when it comes to being genuine, I think that's that's so critical is take what's on the inside, put it on the outside and talk about, 'You know, Rob, I'm kind of getting the feeling here that you feel such and such. Is there any truth to that? Can we talk about it?' That's been that's been huge for me in a great way, I think to be genuine with people.
Rob Newsom:Yeah, that's a great way to express it.
Aaron Moncur:Yes. I, I'm curious here and this going back to some of the recommendations that were written for you. And if this gets too personal, feel free to suggest that we just move on to another topic. But I'm kind of curious, what what was your home life like growing up? I mean, you seem to be there's that word, again, genuinely kind of a just kind and calm person who knows how to help others get the best out of themselves? Do you think that that that skill or ability comes from the environment in which you were raised? Or was it something that you kind of just developed over time on your own?
Rob Newsom:Definitely, a lot of it came from from being raised, my father had an eighth grade education, not well educated all he sold cars, that was what he did for a living. But but he really, he really stressed the importance of, make sure you're enjoying yourself at what you do. So enjoy, enjoy your work, enjoy the people you work with. And the only way to really enjoy it is to get to know them. And so he was very much more of a people person than than I am. And I took a lot of that from him also took a lot of sort of his humor from him. So, yeah, there's several people in various industries that talk about using humor as a leadership or management technique. And I believe very strongly in that, when something strikes a person that's funny, they tend to retain it much longer. And they tend to enjoy being around you and enjoy, it helps with building a team. That type of thing. So, you know, practical jokes are fine. Of course, if you're the manager, you have to be a little bit careful. You can't really belittle people and and that type of thing, but you know, and part of that is be self-deprecating, there's no reason why you can't make fun of yourself. People, people seem to gravitate toward that. So
Aaron Moncur:That's great advice. Back when I was an intern right out of college, or towards the end of college, text to voice was a very new technology. And it was, it was really cool that you could get on a computer and type something out and have the computer speak what you just typed out. And we had we had a lot of fun with practical jokes using using that technology. Okay, well, last question for you. Rob. Can you share what, what is it? Do you think that motivates you as a person? I mean, what is it that compels you to to get out of bed every day and do what you do? And maybe what are some of the experiences you've had that that have helped you learn what it is that motivates you?
Rob Newsom:Um, I've always enjoyed building things. And making things I mean, as a kid, and you were building rockets that we shot up in the air force being around wanting to be astronauts, that was kind of a natural thing. And of course, we built, you know, gas powered airplanes, and model airplanes, and that all that type of stuff. So building that stuff, and sort of doing stuff that was new, so technology always enticed me. So I'm always looking at technology and how to use technology and how to use technology to make make the world a better place and make it a more interesting place. And so that, that has always been, you know, one of my key focuses is building things. And over time, it's kind of graduated into into being more of building teams to build things, I've sort of learned that, you know, there's only so much I can do by myself. But if I can help a team of seven, or a team of 10, or 75, build stuff, they could certainly build much more than one person can do on their own. And so that sort of has always been, what motivated me is, how can I build something that's really nice and really helpful and really cool. You know, of course, we don't always get to do the cool things. But build something that that that is useful and gets used. And to me, the, the, I forget who it was, but someone asked me how I defined what what a successful product was, and I'd say, a product that's, that's used and enjoyed and is successful that way. And, it's it's not how many features it has, or how much it costs or anything, it's just is something being used. And so that's always what's motivating me, it's just building things, and then eventually building teams that build things.
Aaron Moncur:I love that I, at one point was a photographer for several years in parallel to engineering. And there's the saying in the photography industry that the best camera is the one you have with you. And so I love what you said just right now the best product is the one that gets used. I've never heard it quite put like that. But that's fantastic. The best product is the one that gets used. Very good. Well, Rob, how can people get ahold of you?
Rob Newsom:Let's see. I think the best way is probably through LinkedIn. So so I'm just on there as Rob Newsom or through my personal email, which is rnewsom@cox.net. It's R N-E-W-S-O-M at cox dot net. I'm usually fairly responsive. I don't check LinkedIn every day, but pretty frequently. But yeah, LinkedIn or directly through my personal email.
Aaron Moncur:Terrific, thank you. I just have to ask this one more question now. We're on video. No one else is going to see this. But did your cat just licked the screen?
Rob Newsom:The cat was gonna be find the computer and reached over and was rubbing his face on the camera. Yes.
Aaron Moncur:That's terrific.
Rob Newsom:He likes some attention every once in a while. So
Aaron Moncur:As we all do it Sure.
Rob Newsom:Yeah. Yeah.
Aaron Moncur:Well, Rob, thank you so much for spending some time. It's been terrific hearing more about your background and in your career and some of your, your tips and advice on on leadership. So thank you so much for being on the Being An Engineer Podcast.
Rob Newsom:Thank you, Aaron. I certainly enjoyed the opportunity.
Aaron Moncur:I'm Aaron Moncur, Founder of Pipeline Design & Engineering. If you liked what you heard today, please leave us a positive review. It really helps other people find the show. To learn how your engineering team can leverage our team's expertise in developing turnkey custom test fixtures, automated equipment and product design, visit us at testfixturedesign.com Thanks for listening.