Rob Newsom | Being a GENUINE Engineer/Leader

SUMMARY KEYWORDS
people, hardware, software, software developer, engineers, rob, building, bit, tend, software development, scrum, called, gravitate, software engineer, person, team, systems, work, develop, type
SPEAKERS
Rob Newsom, Aaron Moncur

Aaron Moncur 00:14
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 00:41
Thank you. Glad to be here.

Aaron Moncur 00:44
All right, I’ll start with the same question. I asked everyone, how did you decide to become a software developer?

Rob Newsom 00:52
Well, I grew up in Florida about 60 miles from the Kennedy Space Center 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 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 02:00
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 gonna date you just a little bit here. But when you you started getting into software that was in what the 70s? Maybe

Rob Newsom 02:17
That was in the 70s. Yes.

Aaron Moncur 02:19
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, then,

Rob Newsom 02:27
yeah, the tool tools are pretty limited, I really didn’t get a chance to really do anything. This, this was pre Apple days, you 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 twos. So got into into using the Apple two, which is basically doing 6502 assembly language and Apple soft basic, which was just a form of basic language.

Aaron Moncur 03:13
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 03:28
Yeah, 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, 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 twos 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, we used Apple two, and also had some very small breadboards and processors that we used for very simple things just just for learning.

Aaron Moncur 04:27
Interesting. Okay. So your first I think it was your first job out of college. In 1989. You were developing DOS based compilers. 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 04:54
Yeah, the tools were much cruder Of course. So being OS based 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. 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 no 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 of the type of tools and yeah, you really had to be very structured and very organized in your work.

Aaron Moncur 06:53
Did it? Did it feel like it was a slower pace? Or was that just normal? And you know, that’s kind of how everyone did things? So it felt fine.

Rob Newsom 07:01
Oh, it felt fine. It was great. I mean, you know, loved it. But But of course, looking back, you know, 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 07:16
Well, nowadays, we’re standing on the shoulders of giants, aren’t we? Yeah, absolutely. 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 07:31
In my mind, a software developer is a little more broad based. So application developer stays just on applications or applications that use strictly by people, whereas a software developer tends to think a little bit deeper. And it can also be making, say, 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 08:21
Okay. Now, you you’re a Certified Scrum Master? And that’s correct. Yes. Yes. Can Can you share a little bit about kind of what Scrum is what what that process looks like how it’s used, and maybe like some of the pros and cons?

Rob Newsom 08:39
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 followed software development, follow the 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, they needed 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 you know, it was very laborious process. And

Aaron Moncur 09:37
that’s just because software and technology were changing so fast back then that six months after you start things might be entirely different.

Rob Newsom 09:44
Exactly, exactly. Okay. So the agile methodology started and there was various different forms of it. Scrum is one one form of agile and essentially It 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 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 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 and 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 you 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, one may take five, something like that. And so it begins to make the development process more predictable. Not only agile, but more predictable.

Aaron Moncur 11:58
Very interesting. I’m the scrum process is something that I’ve started looking into just really, you know, 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 12:25
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, of course works very well because software is very changeable. In hardware. I’ve seen it used in in breaking down of course, we built 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 were 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 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 an agile like Scrum.

Aaron Moncur 13:40
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 14:01
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, sometimes usually you want the scrum master or the guy that runs the meetings, to be the person that is best suited to remove roadblocks from the project. 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 Sprint’s should lie and where they should focus on first as opposed to toward the end.

Aaron Moncur 15:21
Okay, so when you say it’s good to have someone experienced 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 or the particular design process.

Rob Newsom 15:39
Yes, exactly, exactly.

Aaron Moncur 15:41
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 at pipeline, and 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 16:17
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, 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 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, you know, 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. Usually surprises 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, you know, 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 Pune, for example. Or somewhere else or in the case of Romania, it was in Tina short. With it 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 19:09
and that was mostly because you had this this I don’t know a column a facilitator.

Rob Newsom 19:13
Exactly, exactly. And the other thing you’ll find out is working with other cultures is they they tend to gravitate toward different things like the Romanians all tended to be exceptional at math, and an exceptional at Quality Assurance. So you know, 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. That 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, you know, they may have some questions that they were afraid to ask in email or whatever. You know, just just to put some faces there. So

Aaron Moncur 20:09
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 OC E? Or repor? Graphic?

Rob Newsom 20:19
Yes. Oh, say reprographics.

Aaron Moncur 20:22
Jose reprographic. Okay. All right. And so in the beginning of your career there, you lead 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 20:53
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 you know, 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 21:44
And the the leaders that you have, these are kind of like the I don’t know, project managers or project leaders within that group. Yeah, yeah. Not Yeah. Not your leaders, not your like executive leadership team above you.

Rob Newsom 21:57
Correct? Correct. Okay, 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 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 Osei 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, you know, 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, you know, 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 fact that 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 engineer mentality. So

Aaron Moncur 24:48
that that makes me think a little bit of anecdotes you here 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. Love it. All right. Well, let’s take a quick break here and just share with the listeners that the being an engineered podcast is brought to you by pipeline design and engineering, where we work with medical device engineering teams who need turnkey custom test fixtures, automated equipment, or product design support. And you can find us at test fixture design.com. And at design the product.com. We’re speaking with Rob Newsom today, who is the VP of Product Development at cubics. You can learn more about the his company@cubex.com. See you bex.com. Okay, so Rob, over the years, you’ve interfaced with hardware engineers, and of course, software developers, what are some of 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 26:16
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 pointedly so software software engineers can be very distractible or, or you know, 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 hardware engineer, you know, someone says, you know, I need a light here, a hardware engineer says, Okay, I’ll put you a white light there. Well, software engineer may think, well, we should put an RGB light there. That way, we could do white light, we can do blue light, we can do red, we could do grid, so so they tend to be a little bit broader thinking, and there’s good and there’s bad, so maybe

Aaron Moncur 27:15
some complementary skill sets is what I’m hearing.

Rob Newsom 27:19
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 gonna go, oh, the hardware guys are so slow. Now, they have to plan everything out. And the hardware guys are the software guys, they’re off doing all kinds of crazy stuff, chasing wild things, you know, but you know, over time it gets it gets better. And that’s probably the best way to do it. If you have a time crunch, you sort of have to force that. 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, you say, you know, okay, the software guys, they see things a little different. You know, that when they say, you know, I want a wheel, you know, it’s not necessarily any type of wheel, you know, 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 29:40
as so many things in life are. Well, 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, you know, what are the things that keep you up at night? What are some of these recurring things that that just seem to be problematic that you’ve had to deal with in your career?

Rob Newsom 30:04
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, 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 you know, 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 you know, they’re not the true project manager. So you have to, you have to live with a bit of compromise. In those other kind of disciplines. 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, you know, 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 know, 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’s taken me, you know, a number of years to realize them. And I have to remind myself of that quite frequently,

Aaron Moncur 31:53
well, attacking problems and a more broad fashion. That sounds Spoken like a true software developer, based on what you just said. 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. And I mean, I see you know, two or four, maybe six, you have 24, which I thought was just astounding in itself. 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, and fair kind. And 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 the other managers or leaders out there so that they can build impactful and rewarding to relationships like you have?

Rob Newsom 33:21
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 when 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 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 is 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 way is is is really take a genuine interest in all your people’s lives. No, no if they’re if they have kids know if they have teenagers know what they like to do what they don’t like to do, you know, really take a genuine interest in them. Don’t just feign it because if you think You know, 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 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 35:47
I really liked 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 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 I’ll sell them down, 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, the most effective way to communicate with someone is, is to be open and transparent and honest. And I 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 and a great way I think to be genuine with people.

Rob Newsom 37:09
Yeah, that’s a great way to express it.

Aaron Moncur 37:11
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 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 37:49
definitely, a lot of it came from from being raised, my father had an eighth grade education, not well educated on P sold cars, that was what he did for a living. But but he really, he really stressed the importance of, you know, make sure you’re enjoying yourself and 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 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, you know, 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 39:16
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 have helped you learn more? what it is that motivates you.

Rob Newsom 40:03
Um, I’ve always enjoyed building things. And, you know, making things I mean, as a kid, and you were building rockets that we shot up in the air, of course, being around wanting to be astronauts, that was kind of a natural thing. And of course, we built, you know, gas powered airplanes, and you know, 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. 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, really cool. You know, of course, we don’t always get to do the cool things. But, you know, build something that that is useful and gets used. And to me, 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, you know, it’s not, you know, 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 41:53
I love that I at one point was a photographer for several years in parallel to engineering. And there’s a 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 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 a hold of you?

Rob Newsom 42:24
Let’s see. I think the best way is probably through LinkedIn. So so I’m just on there as as Rob Newsome or through my personal email, which is Rnewsome@coxdotnet. That’s our NE W facility. So 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 42:52
Terrific. Thank you. And 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 43:01
The cat just got a computer and reached over and was rubbing his face on the camera. Yes. That’s terrific. He likes some attention every once in a while. So

Aaron Moncur 43:14
as we all do, sure. Yeah. Yeah. 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 43:33
Thank you, Aaron. I certainly enjoyed the opportunity.

Aaron Moncur 43:35
I’m Aaron Moncur, founder of pipeline design and 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.