Being an Engineer
Being an Engineer
S5E43 David Malouf | How to Accelerate the Speed of Engineering, Episode 7
In the seventh episode of How to Accelerate the Speed of Engineering, host Aaron Moncur welcomes David Malouf. David shares insights on overcoming common engineering challenges, employing effective tools and techniques, fostering psychological safety, and experimenting with new technologies and unconventional approaches to streamline workflows.
Main Topics Covered:
- Introduction to RF engineering and David Malouf's background
- Challenges in defining objectives and managing stakeholder expectations
- Tools for failing fast and inexpensively, including the use of checklists and project management systems
- The importance of clear communication and technical writing skills
- Fostering psychological safety and encouraging participation from younger engineers
- Experiences with introducing new project management tools to improve efficiency
- Lessons learned from project backfires and the importance of following established processes
- Unconventional approaches to expedite engineering, such as rapid prototyping and 3D printing
About the guest: David Malouf is a highly skilled Senior RF Design Engineer with over 13 years of experience, currently at Corning Incorporated. He has an extensive background in project planning, mechanical and RF design, and process optimization. With multiple patents to his name, David is adept at translating complex technical concepts into accessible ideas for non-experts. His previous roles include engineering positions at Benchmark Automation and Atlas Material Testing Technology, where he led product innovations and testing for advanced industrial systems. David holds a BS in Electromechanical Engineering from Vermont Technical College.
Links:
David Malouf - LinkedIn
🚀 Join Us at PDX 2025! 🚀
PDX 2025 is the Product Development Expo designed for engineers who want hands-on training from industry experts. PDX focuses on practical skill-building, cutting-edge tools, and real-world solutions.
📅 October 21-22, 2025
📍 Mesa Convention Center, AZ
🔗 https://reg.eventmobi.com/product-development-expo-2025
Click here to learn more about simulation solutions from Simutech Group.
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
Do you want to automate but don't have time to develop the skill set, try our Easy Motion hardware and software bundle. It's like T slot extrusions or automation programming. The functional elements are already built for you. All you need to do is connect them together to create fast, easy and endlessly customizable motion solutions. Learn more at Team pipeline.us.
David Malouf:Being very specific about your goals is very important to preventing us from slowing down and having to go back and redo a lot of work in the first place you music.
Aaron Moncur:Hello and welcome to the being an engineer podcast. We are thrilled today to be speaking with David Malouf, a highly skilled senior RF design engineer with over 13 years of experience working in the aerospace industry. He has extensive background in project planning, mechanical and RF design and process optimization, with multiple patents to his name, David is adept at translating complex technical concepts into accessible ideas for non experts. His previous roles include engineering positions at benchmark automation and Atlas material testing technology, where he led product innovations and testing for advanced industrial systems. David holds a BS in Electromechanical Engineering from Vermont Technical College. David, thank you so much for being with us today.
David Malouf:Thank you so much for having me. I am so excited to be here. Thank you so much. Absolutely.
Aaron Moncur:So we are going to focus today's conference conversation on our ongoing series, which is how to accelerate the speed of engineering before we get into that. Can you tell us a little bit about RF engineering? What? What is RF engineering, and what does the day to day look like for an RF engineer? Oh,
David Malouf:yeah. So my role, where I work, is, I'm an RF design engineer, and a lot of that involves product design of different RF components that our company makes. You know, we specialize a lot in aircraft components, specifically, both for civilian and military applications. A lot of the daily grind for us probably looks a lot like everybody else's engineer experience. However, where you know, we go to the meetings we attend, the thing we see, the customer inputs as to what they're seeing. You know, we scratch our heads and bang our heads against the wall trying to figure out a problem that they present us, and just when we feel like it's impossible, we come up with a solution and sent it to the customer. And you know, then there's the whole engineering change orders, everything else. All of those different processes have the background. But you know, a lot of what makes being an RF design engineer, especially with the stuff that we work on, is most of our components are just super, super tiny. Many of the modern ones are sub millimeter, and it's, it's a sort of an art in designing the thing you can't see properly, which has always been a lot of fun. So, yeah, there's a lot of that. More recently, I've dove into process design, you know, where, just as much as we're developing products, those products sometimes are cutting on the edge of what is technological, technologically possible with existing, you know, machining hardware. So half of my job is product design. Half of it is also new process exploration. So it's been a really interesting ride for the past eight years now. So it's been a
Aaron Moncur:lot of fun. Very cool. Very cool. Okay, that anything electronic, and certainly getting into the the niche aspects of electronics, like RF design, has just been a black box of magic for me. I just, I never get it. So people like you who get those things, I think are so, so impressive. Well,
David Malouf:thank you. Thank you. You know a lot of I can only claim to know so much about our theory. You know, each of my I work in a team of a dozen people, and each one of my colleagues have different specialties. And, you know, I work with guys who, like, I say the same thing. Like, what they do is witchcraft, as far as I'm concerned. So I totally get I totally get
Aaron Moncur:it. Yes, witchcraft, that's an even better way this ad, all right. Well, moving into the main topic of our conversation today, how to accelerate the speed of engineering, let's, let's start by talking about, what are some of the ways that you have seen engineers slow down that process. Where? Where do we stumble? Commonly? Do. Well,
David Malouf:I can tell you where I have stumbled commonly and you know, just just thinking about the projects that I've had over the past couple of years, more than anything else, we trip right at the beginning. A lot of the times a project that I'll undertake is often derailed by me either not defining my objectives clearly enough, or not managing my either supervisors or stakeholders expectations about the outcome of project. It is. It's been very common where you know we'll be, when I say me, I mean, my department will be handed a project to say, Go fix this, and then we try to figure out what fix means. And so, so being very clear on our objectives, what we're actually trying to do is key to the success of a project, and where normally we fall down a lot. Also, like I said, managing the expectations of the stakeholders. If my stakeholder says, Go fix this thing, and I take fixed to mean one thing, and don't tell him what that means. Um, there's a good chance that that stakeholder is going to be somewhat disappointed when their expectation may have been something completely different as to what quote, unquote fixed means. Those are. Those are two of, like, the really easy, low hanging fruit stumbling blocks that, like, I think a lot of times, at least in my experience, we kind of gloss over because it's like, yeah, yeah, we know, fix the thing, but at the same time, it's like, yes, but does fixing mean we need to get yield rates up. Does fixing need? We need to improve the cleanliness of a process like being very specific about your goals is very important to preventing us from slowing down and having to go back and redo a lot of work in the first place. So
Aaron Moncur:I think, yeah, that's brilliant. That is so well said. I have a theory about why this is because, yes, I found the same to be true in our company, in my, you know, in my different histories of working on engineering projects. And at least this is true for me, and I think it's probably true for a lot of other engineers as well, the upfront work of defining the requirements and the objective is not, it's not fun. It's no it's not. It's it's paperwork, it's tedious. And one of the reasons I don't like leading projects is because I have to do those things. I have to make sure we have a very clear requirements, documentation, specifications defined upfront and, oh, it's just drudgery for me. I don't like doing it. I want to get into the fun stuff, the creative stuff, right? Let's jump into CAD and design something and go make a prototype and, like, test it on a bench top. That's the fun stuff, yeah? But the documentation of the upfront requirements. That's just, it's not fun, and so we don't always do it, even though we all know that we should. That's my theory on it.
David Malouf:I couldn't agree more. And like, we're all really good at the fun stuff too. Like, you know, I'm, I'm happy to dive into SolidWorks and just tinker endlessly until you get something perfect. I just may not have defined what perfect might be. No, absolutely, I totally agree.
Aaron Moncur:Yeah, okay, all right. Well, let's see. How about some tools that you have seen used effectively to fail fast and fail inexpensively?
David Malouf:Oh, yeah. So So fail fast has kind of been the theme of our department for the past couple of years. You know, they're, they're the company we work for is a rather large one, and so we have a lot of large moving parts that are often going on in our projects. And it has been so often where either we've not revisited a project or recalculated project that we end up wasting a lot of time getting halfway down the pipe just to figure out that, oh, this is not something we need to do. And so so really, again, it's that, it's that upfront, looking at the project, doing the boring stuff of being honest about, like, whether your project actually has a decent ROI like, we have internal metrics for what a project we would like to have a return on. You know, it really depends on what that project is, and basing your budget off of that, off of that projected return on investment is super, super important. You know, obviously, if I'm going to develop a multi billion dollar machining platform, and the ROI of that device turns up into be, like, 23 years like, that's probably not a project I should take on. And we should. Stop right now. But that also is a good benchmark for how to guide the project in maybe a different direction. If you realize that, like, your return on investment is very, very small, but like, it's still for whatever reason, for another reason might be value add to whatever you're working on, there might be a way to go about it, just in a different way. So being very honest and objective about what the return on a project is can save you a lot of headache down the line. And you know, just like I said earlier, that that whole project Chartering and planning thing that we all hate to do at the beginning, like one of the things that our group is really, really good at, is looking at an input to a project and saying, okay, is this insane? Is this something we want to take on? Is this something that we can work with, and oftentimes that project planning and chartering, we can decide very quickly is like, oh, no, this is actually something that we can do. There's value add to it, and then adding the ROI into it, you very quickly can assess whether a project's actually worth exploring. Now, what's important with that as well is that most large projects like that, they end up being, you know, depending on where you live and who you are, either a stage gate or a phase Gate process, one of the best things that you can, that we, that we can do, is actually, at the end of each one of those stages or eight, go back and look at that ROI in that charter again and see, are we still doing that, and does this still make sense? One of the, one of the common problems that we've had, you know, even five years ago, because we were so hell bent on a project that we just keep going and going and going and never actually stop and say, Is this project even relevant anymore? Does this make sense? And you know, I'm sure there were times where we probably should stop the project and just carried on anyway. But nowadays, it's actually like we kind of pat ourselves on the back when we kill a project early, because that means that we have just not expended a lot of resources that could have been spent elsewhere. So those two things of chartering and ROI are super, super important to do, both at the beginning and just throughout the project, to prevent anything from any, any real unnecessary expenditure of resources.
Aaron Moncur:I'm curious to hear how your teams have dealt with what I'm what I'm going to bring up next, really just a callback to what I said before, which is that I don't myself, and probably a lot of other engineers don't enjoy doing the defining requirements for a project and then being diligent throughout the course of a project to look at all right, what? What do we project that we're going to spend at this point? What are we actually spending? What are we trending? Are we going to be on budget? Are we going to blow the budget? How do we course correct these are, these are the things that most engineers don't, don't love doing. We can, yes, but we don't love to do them how, obviously, they're important. They're They're super important. Like, like you mentioned, have you found effective ways to ensure that these things get done? Is it just having the right person in that role?
David Malouf:I would like to say that I've had a perfect solution to this. I the way that we have found to do this is actually through a lot of our projects at a very high level of run through series of checklists. Like, like, I know that sounds super cliche, but like, you know, one of our checklists is talk to the plant Comptroller to see if this financially makes sense, or we're just doing engineering math right here, you know, because I absolutely agree, like the idea of sitting down and doing an ROI or an IRR or an NPV calculation for a whole project just sounds mind numbing. Some of it is definitely getting the right person. I have, you know, with how our projects are set up, we actually have for large scale, heavy lift work, dedicated project management groups that actually will come in and take over a project and do a lot of that. You know, I don't want to call it minutia, because that feels like an insult to their job. But the the the very important but very dry stuff that is required for a project to run effectively, and it leaves us engineers to run off and go do all the fun stuff then. But you know, for mid sized projects, like, honestly, having having other people in your organization, you can go to to bounce ideas like monetary information off of is super useful, whether it is if you're in a factory or your plant controller or, you know, some accountant, person you know my my supervisor, likes to joke that, you know, a lot of engineering is actually just accounting. And I would very. Much like that to not be the case, and so having those quick conversations with those experts actually forgoes a lot of that guesswork and everything that normally we'd have to
Aaron Moncur:take on. You mentioned something that is a perfect segue into that the next question. You mentioned checklists here. What kind of checklists you have seen to be effective in well, accelerating the speed of engineering projects.
David Malouf:Yeah, yeah, yeah. So checklists are a big hot button word in our factory right now. And you know the the one that immediately comes to mind is something we refer to as our transfer to manufacturing checklists and with how, with how organization is structured, like I work in the design and development group. We're dedicated to new product development, new process development, kind of weird, off the wall stuff, but at some point it's kind of become real. And so we've recognized, and this is, this is something we actually only taken on more recently, because we've recognized how difficult this process really is of handing a product to a factory. We have a dedicated checklist that makes sure that we talk to each of the department heads in the factory. You know, we talk to the machining group. Did you look at the drawings for this part? Is this something you can actually make, or are we kind of out in the middle of nowhere with this is this design, you know, bringing in the quality department and having their own separate checklist. We have this massive document that, in massive is probably an intimidating word to use. We have this document that is broken up into different sections, that has a lot of tiny little checklists that we hand off to the different sectors of our factory. And, you know, in practice, it's somewhat more muddy than how I'm describing it right now, but very loosely. We basically gather all the people into one room and say, This is the checklist for X project or x process we're trying to introduce. Does this make sense? Are there things that we need to add or remove to this list? And then, you know, by dividing up that labor, we can actually accomplish all those things and make sure that when we transfer a part to our manufacturing group, everybody has signed off on it, everybody has checked it, everybody has looked at it. Or, you know, the same thing with a process like we're introducing a process that has some concerns where safety is concerned, for example, so we have a dedicated safety officer in our factory who has their own checklist they go through, but that that big transfer to manufacturing omnibus checklist really helps us guide the process of making sure that all of the information gets where it needs to go in our manufacturing's hands without, at least without trying to forget anything or without losing anything in the process. You know, there's no such thing as a perfect process. But another thing that I found has actually been really useful about checklists, just speaking in abstract, is if you've got a process that you repeat over and over and over and over again, chances are it can be reduced to a checklist, but there is a fine line you kind of need to walk between reducing that to rote memorization checklist that is going to be the same every time and being so inflexible that you can't actually modify When something different comes to you. You know, our factory, by and large, makes coaxial RF components, but every once in a while we do something different, and our checklists have to take that into account when we get those weird, oddball requests that come through our group and then flow on to my poor manufacturing friends down the line. So, yeah, checklists are a huge, huge part of that. The, the, the, the only other thing I'll say to that is that checklists are only as good as the system you use to manage them. I have seen a lot of people manage checklists through sticky notes, you know, simulating a Kanban board with sticky notes. I've seen some people try to do it in Excel. A colleague of mine and I a couple years ago actually introduced a a like purpose built project management software to our system. And running our checklist through that, and our processes through that, has actually kept us more organized than, you know, Excel, or even, I would say MS project, for those of us who have, you know, had to suffer through that before. But, yeah, having your checklist in a place that is manageable is just as important as having the checklist
Aaron Moncur:itself. Yeah, as you're talking through all of this, a thought that has come to mind is that a lot of these factors that really do move the needle in terms of speeding up engineering projects, they're not rocket science. In fact, a lot of them are pretty basic. You know, having checklists, making sure that you're communicating with team members. They're defining a requirement. Experiments right at the beginning, looking at your budget and managing the budget over time. They're not rocket science. You just a, you need to have enough experience to know that they should be done. And then B, you just need to do them. Or, you know, have someone responsible for doing these things, and
David Malouf:that's, well, that's the crazy part about this is, you know, I've had, I've had multiple conversations. A cousin of mine is actually just graduating engineering school soon here, and you know, one of the things I encourage him to do is take an English course and take an engineering ethics course like those are going to be your more important courses, because I have no doubt that, you know, if you graduated engineering program, chances are it's because you survived it, and you're going to do okay. But if you can't communicate the knowledge that you have, your usefulness is going to be very limited. So you know, for for engineering students or Stewart in school, take the opportunity to take English courses, take technical writing courses. You know that that technical writing, especially is a skill that I think is massively undervalued in our industry. You know? I'm sure you've received emails that are supposed to be some sort of description of specifications, but end up being like this rambling description of pseudo nonsense I'm going to try to pull something out of never, never, ever have you seen that? But you know, just that ability to to communicate clearly and succinctly, hopefully, skill I'm learning will is something that I highly recommend everybody take up at some point, if they can. I agree 100%
Aaron Moncur:so much of this comes back to just good communication, which is, I feel like something that is not really well defined in our industry. Everyone talks about communication. We all know that it's important, but it's this nebulous, fluffy thing off in the ether somewhere that none of us can, can really like, nail down and define Well, well, some of us can, but most of us it's just this idea that's floating out there in the clouds. I remember taking a technical writing course in college, and I loved it. It was one of the most, the most enjoyable classes that I took. And over the years, I've learned that I'm actually a pretty good technical writer, and that's probably why I like that. I just happen to have clicks in your head. It does, it does. Yeah, I enjoy that. And honestly, I think that's one of the reasons that I've not that I'm some mega success or anything, but I think it's one of the reasons that I've been at least marginally successful in growing an engineering business, is because I'm, I think I'm fairly good at communicating with people, and that's that's such an important skill.
David Malouf:Undoubtedly it is. You know, like I said, it your ability to communicate your ideas, is a way to be able to be more useful. And if, if you know, I've got, I've got plenty of colleagues who, because I speak engineers, I know how to talk to them. But you know, for for translating something from what they know, this highly technical thing to, you know, even talking to supervisor groups or stakeholders, or even just a layman out on the street who has the unfortunate consequence of hearing me talk about engineering, you know, it, it's a skill unto itself, to be able to take that knowledge and Put it into something understandable, for sure.
Aaron Moncur:Yeah, there's an engineer that I worked with for a while, and he was one of the smartest engineers, one of the most technically gifted engineers I've ever worked with. To this day, he did things that I certainly can't do, and most other engineers I've worked with can't do, from a technical standpoint, he was just brilliant. When he talked to me, I understood the individual words he was using, I kid you not, half the time, I had no idea what he was trying to communicate to me, and it was it was so frustrating, and it held him back. It really, truly held him back in his career. He did not advance the way he should have given his his technical skills, because he just he couldn't communicate well
David Malouf:with others. Absolutely, absolutely, and it's a shame too, because I'm sure that that person has brilliant ideas that if only we could execute on would benefit whatever they happen to be doing. And, yeah, no, I can't emphasize enough, just just being able to communicate clearly is such a skill. Yeah, yep,
Aaron Moncur:absolutely okay. How about feeling safe? Psychologically safe. How does that affect a team's ability to make rapid progress? Versus, oh, I don't know if I want to say this, because what's he going to think about it, or what she's think about it, or what are the politics involved? Or the Bucha is talk a little bit about psychological safety and how that affects an engineering project,
David Malouf:yeah. So actually, this is, this is something we're just coming off of doing in our department. So the summer is ending here, hopefully in Arizona at some point, right? And we just had a cadre of interns, and one of the things that we really like to do with our internships is treat them as basically full fledged engineers. That's what we told them day one, when they joined up. We had I had one working directly for me, and when we took take on interns, they function as engineers for the summer. We don't assign them, like, got, like the stereotype, coffee, get coffee or whatever. And, you know, do all the minutiae stuff that we hate doing. I still did all the minutia, and they did more fun things, but one of the things we do every week is we have, you know, our staff meeting, and we drag them into it too, and because they're, they're part of our staff. And one of the things I find so often is, and I remember feeling this when I was a new engineer too. Is that very feeling of God, I'm surrounded by, like, centuries of experience, and I just graduated, I have no idea what I'm talking about, yeah, when really, you actually might, because those centuries of experience happened a long time ago in some degree. So you might have more information on a current topic, especially, you know, with the rate of technology and how it's advancing. I mean, when I graduated high school, cell phones weren't a thing yet. That's how recent that is. And so, you know, for a lot of modern factory equipment, for example, is using either blue suits technology or some sort of wireless protocol or something that that some of my more senior engineering folk may not have grown up in and around and may not know how to use even and so, especially with more relevant things like actually having the younger folks speak up in those situations is extremely helpful, I think, as as as somebody who's sort of mid career, the best thing that that somebody like me can do to encourage that behavior, especially if you're Looking to get that information out of the younger engineering staff is just start talking yourself. Just throw like I an idea we talk around, uh, throw around. A lot in our shop is a lot of people are scared of a blank piece of paper, but everybody can do edits. And so oftentimes, if I feel like either, either a group is stalling, or if, like, I get the sense that, like, man, that new grad wants to speak, but he's just, he's just keeping it in for whatever reason, I will throw out the worst idea I have and just say, let's start here and then make this better. And that often facilitates that discussion, because I've already looked pretty dumb, and so you can only go up from there, and I'm confident enough in my ability that I feel okay looking dumb in front of my colleagues, senior and younger. But it that's sort of a something that a mid career engineer can do, especially if they have an interest in fostering this sort of discussion and providing this sort of space where younger engineers can can have their ideas in a way that feels safe, for lack of a better term. I
Aaron Moncur:love that it those who have been listening to this series, are probably going to start rolling their eyes, because I keep bringing this up, it keeps coming up, and I love this term. A friend of mine uses the term McDonald's ideas to describe exactly what you're talking about. They'll go out to lunch, him and his team, and he's a leader in his team, and they'll say, well, where should we go for lunch? And everyone's like, Oh, I don't know. I don't know where you say, where should we go? And so him as the leader, he'll say, oh, let's go to McDonald's. And everyone looked at, I'm like, what I can do better than that? I mean, I'll give you a couple of ideas, okay, I don't want to go McDonald's because those McDonald's ideas exactly like you said, right? Just a great way to start some some communications of discussion in the group. Throw it
David Malouf:absolutely, I love that idea. I might steal that. This McDonald's ideas. I love that. No, it works. Yeah, I love the dollar menu. Don't get me wrong. Oh. But no, it's, it's absolutely true, like, like, just the the, sometimes just a kick start that brainstorming or creative process, you just going to have something on the piece of paper, even if it's just spilled milk.
Aaron Moncur:Yeah, right. I like your, your way of describing it as well. Everyone's scared of a blank piece of paper, but is able to make edits. That's a great way to think of it.
David Malouf:It's, it's something that, like, I, you know, not to, not to, you know, bragging myself at all, but like, I've always just sort of, you know, idea vomited, or word vomited on a piece of paper, just to get it out of my head so that I can work with it. And that is really driven this idea of, like, something's got to be there first before we can do anything with it in the first place. And, you know, I see, I see just a lot of people get frozen in that initial step. Just a little push is all you need.
Aaron Moncur:Yeah, this deviates a little bit from the question of psychological safety. But when I was in college, I remember getting stuck on some engineering problem or physics or math something, and I didn't know what to do from where I was, and I asked a roommate of mine for help, and he didn't know exactly where to go, either, but he had this great way about him of just trying something. You know, it didn't didn't even matter if he thought that something was necessarily going to lead directly to an answer, but he would identify. Well, here are three things we could do. I don't know that any of them are the right things, but we can try these things, so let's try them. And sure enough, we try a couple of things, and we'd figure out a path to the answer. And I've I always thought that was so clever. When you get stuck and you're not really sure where to go, just try something, even if you think to yourself, this more than likely is not directly going to lead to the answer, but I know it's something I can do, so I'm just going to try it and see where that leads.
David Malouf:Absolutely, absolutely, you know, in a especially, you know, just thinking about the concepts of problem solving, you know, if I'm staring at i i i very freely. My ability to program in any language whatsoever is suspect at best. But you know, I'm if I'm looking at something like a program, you know, I know I don't know everything, and I know that there are people who are going to know things that I don't, but even if it's something that like we're all staring at, and we know that this is not working properly, but we don't understand why. And at least trying something gets us data, and that data we can then use to guide the next step and get that iterative problem solving process going right. And it's just it comes right back to that just we need to jostle the system some way to tell it, get it to tell us something.
Aaron Moncur:Yep, little kickstart,
David Malouf:absolutely.
Aaron Moncur:Well, let me take a very short break and share with the listeners that the being an engineer podcast is brought to you by pipeline design and engineering, where we don't design pipelines, but we do help companies develop advanced manufacturing processes, automated machines and custom fixtures, complemented with product design and R D services. Learn more at Team pipeline.us The podcast is also sponsored by the wave, an online platform of free tools, education and community for engineers, Learn more at the wave. Dot engineer, and we have the privilege today of speaking with David Malouf. David, Have there ever been experiences where you've you've introduced a new technology or a tool that significantly reduced engineering time?
David Malouf:Yes, actually, so I mentioned earlier briefly that a colleague of mine and I had introduced project management system to At first our department, but then it's now grown and expanded uncontrollably. And you know, before that we we basically, when we were managing things like new product design or process improvements and such, we were one step away from handing a piece of paper around, checking check boxes off and doing that kind of thing, which is great. So long as you know where that piece of paper is we've lost that piece of paper a lot. The the I used to be very skeptical about project management systems, the extent of my experience had been an older copy of MS Project, and it's great at doing like a couple of things, but as soon as you start to introduce a lot more complexity, you can really get bogged down in the notion detail. So introducing, when we selected a project management system, we looked for one that was very flexible and we could get to do a lot of things, but was also very lightweight. One of the things we find more than anything else, and this is I've worked with companies of all different sizes, and worked for companies of all different sizes. This is definitely a problem on the larger corporate side, where we will get bogged down in all of the red tape that we have everywhere. And one of our objectives with putting the system into place, and my colleague has now run with this system and felt this fantastic platform. One of the things has been making sure that whatever interactions we have to have with the system is easy, quick, intuitive, and I don't have to spend a lot of time teaching, you know, my 40 plus year veteran engineer how to operate this system. Nor should I need to teach my brand new green horn engineer the system, either. And so. So by introducing the system, we now can actually measure the time accurately that we spend on things, and we're finding that it's actually picking up. One of the points of pride for our department, actually, with a lot of design turnaround, is we can now turn around design from customer reaching out to us, to, you know, getting ready to hand to manufacturing. Most of them turn around in under 30 days now. And that is something that you know, as far as I know, as far as I'm aware, is unheard of in the industry, and a lot of it has to do with the fact that, like we have a very well defined process, and that process is not managed through a piece of paper we hand around, but a system that is centralized, that we can go to pull the information from, input the information that we need, and we don't spend all day managing the system. The thing that we are terrified more than anything else, is that we then end up with a system to manage all the things we're trying to manage in the first place. That that is just management, stacking, nesting eggs, type of thing that we want to avoid
Aaron Moncur:absolutely this, this tool that you've that you're using and have grown throughout your team. Is this an off the shelf product that anyone can purchase, or is it something homegrown? Yeah,
David Malouf:so this is actually an off the shelf product. It's an open source piece actually called Open Project, and it happens to be the system that we found met all of our needs, and you know, we really like it, but we've we looked at, you know, a bunch of different types of project and project management and process management systems. And I think if in if an engineering group or team or even a manager were interested in looking at something like this, I think that the best thing you can do is just try it out. For a little bit, we did a lot of trials with a lot of different software, and we found a lot that kind of matched what we needed, but a lot that kind of didn't. And you know, if you are interested in implementing something like that, like the best thing I can say is just experiment with it and try it out. Get your hands dirty before you go full blast into putting into place.
Aaron Moncur:Yeah, definitely, open project. I've never heard of this before. I'm very curious now to check this out. Maya,
David Malouf:yeah, absolutely. You know, I, we, we've, we've been, we've had very good experiences with using it so far. I believe it's developed primarily out of a group in Germany, but, yeah, like, we really, really like that system. It's worked really well for us.
Aaron Moncur:Terrific. All right, I think we're, we are kind of in the market for a new project management system. We've used one for a while, and there are definitely opinions within the team about about moving to something else. So open project, I'm definitely going to take a look at that
David Malouf:great Absolutely, absolutely, I highly encourage that great,
Aaron Moncur:great. Thank you. All right. Have, have you ever, are there any experiences that you can share, or stories where an attempt to accelerate your engineering activities a project backfired? And what can what can we learn from that single experience that never happened more than once. Oh,
David Malouf:never happened more than once, whatsoever. You know, I could say that, God, I can think of a half dozen projects like that. The big thing I can say is, if you understand the size of your your project, treat it appropriately. Thus we we undergo a lot of things that we refer to as tasks that you know maybe, in some circumstances, might have qualified as a quote, unquote project. We're very we're very specific when we want to be about that word project. Um. And you know, a lot of times those, those tasks are, you know, what we think of it, like fix it task, or, you know, like minor change tasks that you know, maybe sometimes should have more interest in, not interest, but more rigor or evaluation to it than we we should have done at that time. You know, I find that that generally, if we try to skip steps that that are put in place for a reason, that often we have put in place, we end up fouling our own process. You know, there's, there are several products that that we have gone through the prototype stage, actually, one that we've developed very recently where, you know, we went back and forth with the customer a lot, and a lot of our time is spent in prototype. You know, I recommend any time an engineer is considering doing prototyping budget, like, three or four times as much time as you need for that, because you're going to be there a while. So we, we were, we were having a back and forth with with the with the customer, and normally we get a lot of information up front, but you know, we didn't ask all the questions we need to, and we made some assumptions about the thing that we were trying to build. And this is very fortunate why we put all these checks in and and checklists in place in our system to make sure that we check all these things. But we did get to the end of the development process and moving to prototype, when we turned around and handed the customer and said, Oh, but what about X, Y and Z? And it was something that we should have asked up front that is actually in our list of things to ask. And so just by not following our own checklist, we actually fouled ourselves. We were trying to go a little bit quicker, and ended up having to just redesign the entire thing, start to finish. So yeah, that's, that's a, that's a really common, I always say common. It's definitely less common now, but something that we do run into on occasion is just don't gather all the information in the beginning. So
Aaron Moncur:let me ask you this, because we have certainly done this as well. We've we've skipped a scab, skipped a step to try and move faster, and then it just, it bites us in the end, and we end up going slower overall. And I'm thinking to myself, why is it that we do this? And why is it that it happens again, like you said, not not frequently, but like on a recurring basis, there might be there might be years in between each recurrence, but it happens and then it happens again. And is it because we've had some good experiences doing this, there have been just enough experiences where we've skipped a few steps to speed things up, and it actually has sped things up. So then we think, well, maybe I should just do that again. Is that the case where we're winning just frequently enough to keep us coming back to that, that blackjack table. You know, I
David Malouf:think there's some truth to that for sure. You know, just thinking about my career and what we've taken on for different jobs and tasks and things like that, that there have been plenty of times where, you know, we've made whether we're pretty sure our safe assumptions, and we have been able to accelerate those things. I think that when we're thinking about doing those, you know, potentially skipping steps and things like that, they have the failures happen just often enough to have forgotten, really, the failure that we had last time is what I have found, right, you know. And for us just thinking back, like, sometimes there are years in between it. But like, if we have, if we take on two very different design projects, for example, you know, I can see a potential where we might repeat the same mistake very quickly twice, just because we're looking at an entirely different animal of a project. So that's why it's just so much more important that, like, the those checklists that you develop for your process, like, not that they're word of law, but, like, there's a reason you put those items there in the first place, yeah, and let's just, let's just check them all off, just to make sure. And you know, I say this out loud, and I say this to me, knowing that sometime a year from now, I'm going to have forgotten about saying all this and skipped another step.
Aaron Moncur:Yes, remembering history is a big point in preventing it from recurring, isn't it. We have a little project checklist that we go through every time we start a new project. You know, it's setting up the folders, and it's notifying the right people, things like that. And occasionally, we'll get just a tiny, tiny, micro project. We don't really do these very often, but every now and then, for whatever reason, we'll take on a project that's like, you know, a few 1000. Dollars, it's almost nothing. And I'll think to myself, Man, I really don't want to go through the process of setting up this $2,000 project in our system. It's just like, a total waste of time. And so I'll think, I'll just, I'll just skip it this time. And every time it bites me, every time we get to some point or like, oh shoot, we haven't tracked this. I don't know where we are with that. I didn't let this person know. It just bites me every time. So I have finally, at least in that specific instance, learned just, just follow the checklist, because it's gonna bite me no matter what. Absolutely,
David Malouf:absolutely a colleague of mine, he has a he has a really good saying he likes to go to, which is, automate the boring stuff and so to the best possible degree that we can. You know, folder generation is a great example where we actually will take even something as simple as like a folder structure template and just copy paste it, just so we have that, yeah, but even that, that little bit of structure helps remind us that, okay, we actually have to do all these other things in this list too. Yeah, but like, absolutely understand that that $2,000 project suddenly gets a lot more expensive as we miss more and more stuff. So I get it,
Aaron Moncur:it goes back to do not wanting to do boring things, not having the discipline to do the boring things. Yep, Yep,
David Malouf:absolutely, absolutely, I understand completely.
Aaron Moncur:Has there ever been an unconventional approach that you've taken to expedite engineering processes?
David Malouf:Unconventional is the nice word that people have used to describe it. So so a lot of times we are, especially in the group that I work in now, we are looking at either technologies that have not been, you know, fully evaluated in our particular application or, you know, and even more so as we dig into smaller and smaller machining practices, things that have just really never been done before. And there are, there are some guidelines for how to set up a project for stuff you've never done before, but you almost kind of have to accept the fact that at some point you're going to spend a lot of time kind of questioning reality. At some points you're going to spend a lot of time asking, like, Is this really a thing we can actually do? And what I have found is sometimes very, very useful, and I only recommend this within like, certain contexts and certain, I guess, latitudes, for lack of a better example, or lack of better term for that, just grab the thing you want to do and try experimenting with it. Just Just, just for a couple hours. You know, we, we there in our in our department, we have several printers now that we do a lot of rapid prototyping with and it used to be the case that, like we would have to wait for our manufacturing group to open up machines, we get a prototype and have them make it, and six weeks later, we knew we were wrong. And instead, we can take the idea, rather than set up this whole big thing where we've got to get budgets for taking machines down and everything like that, and just very quickly try something, even if it doesn't make any sense initially. And actually the the the rise of three purchase generally, has enabled a lot of this in a lot of different sectors, too, where it's encouraged a lot more experimentation up front. And what I've actually found is is, especially in product design, if you can do that, that little bit of experiment up upfront, just to understand whether something is even sane to take on, you can actually avert a lot of going through that ROI calculations that I talked about earlier, and everything, all the boring stuff that we don't want to do in the first place, just by doing that little bit of experiment first. Now I have several engineering professors I remember who would slap me for saying that. But, you know, sometimes, sometimes it just takes getting a wrench and or a hammer and just beating on something until you see whether it makes sense or not initially. I
Aaron Moncur:think that is such wise. What's the word? I'm looking for a recommendation such a it makes so much sense to spend those few hours just trying something really, really rough. We we have a whole bunch of 3d printers here as well. And there's one, I won't say the brand name, but there's we have a couple of this brand of printer, and they do a really nice job. It prints with carbon fiber, really nice parts. Part. Finish is great. The material is a little bit expensive, and whenever an engineer would print with those printers, we have a little form that gets filled out so that we know how much to Bill our cut. Customers for something we printed for their project. And so they fill out this form and they put the price in it, and they ended up noticing that our internal cost, or, well, what we charge the customer to print this part with a this internal 3d printer of ours, even though the real nice, really nice parts were often a little bit more expensive than what it would cost to just like, go out and buy it from a service provider, printing Bureau, Service Bureau and and psychologically, even though, you know, they would spend time if they went with a service bureau, they'd have to spend time, like, sending files and getting a quote and issuing a PO and all that stuff. And so really, it was probably still cheaper, just doing it internally, but psychologically, they'd see that price, and they'd compare it with what a service bureau would charge, and they'd be hesitant to do it, and it would take extra time, because they'd go back and forth. Oh, what should I do? Should I do it internally? Should I send it out? And so we identified this as one of the roadblocks that we were going through, and what we did was we bought a relatively inexpensive, about $1,000 Lyd printer that's really very reliable and actually produces great parts, not as good as this, this more expensive one that we had, but really pretty great parts for for what it is. And we just said, Okay, guys, from now on, if you use this new 3d printer, the parts are free. We don't charge the customer anything. It doesn't burden the project with any cost. It's just part of our overhead. And even though, I mean, the company's still incurring that cost, right? They don't see it added to the project, and they don't see that charge getting passed on to the customer. So it feels so much easier for them now to just use this Lyd printer. And you know, maybe in the past, they would have done two printed parts to prototype because it's kind of expensive. I don't want to spend the money. I don't want to burden the project. Now they'll do 10 because it's free and it doesn't cost them anything. And guess what? We actually do projects much faster and get better results. All of that just because we had this quote, unquote, free, three day printer in house now that. So
David Malouf:that is fantastic. And you know that that that mentality of standing in front of the more expensive printer and like second guessing whether this is value add or not, like one of the things I try to remind, you know, especially new engineers coming in is like, the cost of you standing there still adds somewhere too. And you know, the couple hours you have spent thinking about, should I print this or should I send it out, like probably was the cost of just printing it in the first place. Definitely, yeah, and, and so, like, having that, that, you know, I don't lesser is the wrong word. But like, like, quick and dirty 3d printer, and, you know, we do, we have something, something similar, and we spent maybe 1000 bucks to get a printer to do mostly fixturing work. But like, it's actually, I'm always amazed at how rapid the 3d print industry has actually come. I remember, you know, when I moved to Arizona in like, 2012 ref wraps were just coming out and being a thing. And now we've got these printers that, like, are, you know, sub millimeter accuracy. And it's kind of crazy what we can get out of them. Yeah, but absolutely, just that ability to rapidly iterate, rapidly prototype, and not have to worry about whether the thing I'm making, if it's wrong, there's a huge consequence to it failing fast, and the freedom to fail is so critical in any project. Agreed,
Aaron Moncur:Agreed. Well, David, what a marvelous conversation this has been. Thank you again. So much for you. So much of your time, absolutely. Yeah, what a treat. How can people get in touch with you?
David Malouf:Yeah, so you can find me on LinkedIn pretty easily. That's most of where I find myself these days. You know, I have an not just an interest in RF theory, but, you know, a lot of my time has been taken up now through the concepts of like, how do we make engineering better, and how do we make it better for the people that are coming up behind us? So, yeah, more than happy to talk to anybody who's willing to listen to me batter on for a while about that type of stuff over LinkedIn, please reach out. Awesome.
Aaron Moncur:Thank you so much. David,
David Malouf:Absolutely. Thank you.
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 advanced manufacturing processes, automated machines and custom fixtures, complemented with product design and r&d services. Visit us at Team pipeline.us. To join a vibrant community of engineers online. Visit the wave. Dot engineer, thank you for listening. You.
