S7E11 Brad & Aaron | How To Accelerate The Speed of Engineering (Episode 1 of 3)

In this special kickoff to a three-part miniseries, Aaron Moncur and Brad Hirayama explore one of the most important—and often overlooked—skills in engineering: how to accelerate the speed of engineering work without sacrificing quality. Drawing insights from more than 300 episodes of the Being An Engineer podcast, Aaron has distilled recurring lessons from experienced engineers into 21 practical best practices. In this first episode, Aaron and Brad break down the first seven strategies that help engineers move faster, solve problems more effectively, and create more value for their teams and companies.  

The conversation focuses largely on what individual engineers can do today to work more efficiently—from choosing the right communication method and asking for help sooner, to troubleshooting systems more intelligently and leveraging off-the-shelf solutions instead of reinventing the wheel. Along the way, Aaron and Brad share real stories from engineering projects, lessons from early-career mistakes, and insights into how small improvements compound over time. 

They also discuss the broader impact of engineering speed: why moving faster doesn’t just benefit businesses—it helps bring better technologies and solutions to the world sooner. 

In this episode, you’ll learn: 

• Why picking up the phone can accelerate projects faster than email 
• How asking for help early prevents costly rabbit holes 
• A simple method for troubleshooting complex systems 
• Why basic experiments and data beat gut feelings in engineering decisions 
• When it’s smarter to buy components instead of designing them 
• How off-the-shelf products can dramatically speed up prototyping 
• Why intentional extra effort and continuous improvement compound over time 

This is Part 1 of a 3-part series on accelerating engineering speed. In the next episode, Aaron and Brad continue the conversation with seven more best practices to help engineers and teams move faster and deliver results more effectively. 

Subscribe to the show to get notified so you don't miss new episodes every Friday.

The Being An Engineer podcast is brought to you by Pipeline Design & Engineering. Pipeline partners with medical & other device engineering teams who need turnkey equipment like cycle test machines, custom test fixtures, automation equipment, assembly jigs, inspection stations and more. You can find us at www.teampipeline.us

Watch the show on YouTube: www.youtube.com/@TeamPipelineus 

Transcript

Brad Hirayama: 0:00

Right? It's not about getting another degree, right? That's like a big 20% you know, you know, part of the pie, right? If, in that time that that you spent getting your degree, if I just spent a bunch of time getting my one percents down, I've surpassed you already.

Aaron Moncur: 0:29

Hello and welcome to the being an engineer podcast. We've got a special edition for you today. In fact, it's a three part mini series, and today is episode one of three, and this mini series, Brad and I are going to focus on the topic of how to accelerate the speed of engineering. I'm excited for this because over the past five years and 300 plus episodes, I have heard recurring patterns emerge from different engineers at different companies in different work environments. But these, these best practices, have come up over and over again, and so we we've identified 21 of these best practices related to how to accelerate the speed of engineering. So today we are going to go over the first seven, and then in episode number two, we'll do numbers eight through 14. And episode number three, we'll do 15 through through 21 so today's focus, there's a light focus on the individual. How can the individual accelerate the speed of his or her engineering? So without further ado, let's, let's jump into that. Brad, is there anything that you want to share before we dive into these first seven best practices?

Brad Hirayama: 1:49

So for those that don't know, my first appearance on the being an engineer podcast was during Aaron's accelerate the speed to engineering series. And you know, he approached me and, you know, basically said, I think you kind of know what you're talking about, or maybe not, but let's, let's give it a shot to see what you have to you know, what you have to offer, what you have to share with everybody. And ever since then, you know, this topic has really been just percolating in my in my head. And why is it that good teams can move fast? You know, I read a lot, and you read these books about, you know, like the early days of Apple, and you read about skunk works and what they were able to do, to do at duet Lockheed. And you start to really think about, not just from the leadership standpoint of why they're able to move fast. But what did it take for each person to actually function in those types of environments? It takes a special person. And I think what I'm really excited about is that, you know, Aaron's had such a vast number of people from different backgrounds, from different life experiences on this podcast, and I'm really excited to hear and to really just narrow this down into these bullet points, just so that we can continue on our mission, which is to really to help disseminate this knowledge and help have people apply this, this this knowledge, to their actual work. So with that, with that being said, that's a lot of words, let's get started and let's jump right in.

Aaron Moncur: 3:27

Yeah, all right, just a little bit more background before we share best practice number one, as I have gone through these 300 plus episodes, one of the explicit questions that I have asked over and over is, what is one way that you have accelerated the speed of engineering to our guests? And like Brad mentioned, we actually did a series where that was the focus of the questions I asked to the guests. Think there were probably six or so episodes where we just talked about that with with six different guests, but outside of that, more generally, I would often ask that question. It's just one of the questions at the episode, what's one way that you have accelerated the speed of engineering? And throughout all of these episodes, whenever I heard something, even if we weren't explicitly talking about that topic, but whenever I heard something that was relevant to that topic of accelerating the speed of engineering. I'd write it down in OneNote. I just kept this list in OneNote. And over time, it grew, and I started noticing these patterns that I would have written down, maybe a few different things in slightly different words, but they were kind of the same thing. And so over you know, five plus years this, this list has grown and then condensed into these 21 best practices, and that's how I came up with them. So number one best practice, number one for how to accelerate the speed of engineering, is use the right communication medium for urgency. Now, a lot of engineers, myself included, don't naturally have the skill set of talking to other human beings. Maybe we prefer to be in a quiet room by ourselves just pounding away at a keyboard, but when it comes to human interaction, that can feel uncomfortable to some of us sometimes, and so I get it when an engineer wants to send an email instead of calling a person or walking over and talking to a person, but this is one of the biggest and lowest hanging fruit items that I have heard over and over, not just from guests on the podcast, but I see it in my own company, with my own team, I cannot tell you, and it makes me sad to say this, because I talk about it all the time, even with my own engineers, and I still see it happening when there is A sense of urgency, you need to get something done quickly, and you're relying on someone else, I'll ask an engineer, hey, can you what's the status of this part that we're waiting on from vendor, ABC? Oh, I'm not sure. I sent them an email. I'm waiting to hear back, and I just want to pull my hair out, because they know that there's this sense of urgency that we're waiting to get this part. It's a critical part for a build whatever, and they send an email instead of just picking up the phone and calling the vendor and saying, Hey, I need to get this part tomorrow. What can we do? You know, instead, it's sending an email and hoping that they get back to you, which usually does not work out well. So that's item number one, use the right communication medium for urgency, which if you can visit someone in person or just walk to someone's desk, that's the best way. A phone call is a good close second email is has no place in communication when you're trying to do something urgently, unless that's just the only, the only alternative. So that's item number one, Brad. Anything to add to that,

Brad Hirayama: 7:11

In this day and age, email is not the only, and really not the right communication medium for most tasks. I mean, you know, there's, there's so much to say about what email has unlocked for us, but there's also this kind of inundation of stuff, right? So you're, you're working for an eight hour day. I mean, even myself, right? I might get 50 emails in a day, some of them good, some of them I need to reply to. Some of them just are sales calls and or, you know, sales emails, and some of them are advertisements. And so it's like part of, you know, part of that meant spending the mental energy of shifting through what is actually relevant. What do I need to do? What do I can do? You know, what can I just ignore? You know, that side of it, it just is not efficient. It's not effective. And I think the point here of calling or walking over, having that in person conversation is, is is great, and I think both sides will appreciate it. I think that's the one thing that I want to point out is, you know, the thought of like, oh, you know, maybe this is urgent for me, but not urgent for you. Or, you know, I don't really want to bother you because I know that you're really busy. It's like, you know, if I'm able to get a question answered quickly, and that moves me forward, and that advances the project or the product or whatever I'm working on, that's going to make both people, both parties, appreciative that I actually took the time to walk over to your desk and ask you a question or to give you a call. So, you know, don't ever think that, oh, you know, this is I'm just a nobody. I can't, you know, I can't be calling this, this person, and asking them for stuff. It's that's not that's not true. You know, take the time to do it.

Aaron Moncur: 9:08

When you need to get something done quickly. Stop emailing. Don't email. Pick up the phone and call the person. All right, we beat that horse to death. Number two, ask for help early. Now, as engineers, we love solving problems, right? That's why we became an engineer, because we love solving technical problems. And so it can be tempting to go down this rabbit hole by yourself and keep digging further and further and to try and solve things on your own, but when you get stuck and you're just spinning your wheels and taking more time, you have to stop and you have to ask someone for help. There was a situation, this was a few years back, where one of our engineers was trying to bring up a picking place SCARA robot, and we. Had, you know, all the equipment in our office, and this engineer was out in our warehouse trying to bring this system up. And shame on us, the leaders of the project, for allowing this to happen. But the engineer probably spent a couple of weeks trying to get this working and this is a different topic of conversation altogether. Those who were in charge of leading the project didn't step in earlier and say, Hey, why is it, why is it taking so long, you know? And there was, there were some small check ins here and there, and the engineer, you know, I'm Yeah, trying to figure this out, but after several weeks, there really was hardly any progress made on this. And we're like, how does this happen? You know, 60 hours or whatever that's been working on this, and we're not much further along than we were in the beginning. And come to find out that this engineer had been, you know, dutifully looking through online forums and reading things and trying to figure out on it on his own. But he never done it before, and he just couldn't find the answers. And eventually we stuck stepped in and said, Okay, stop working on on this by yourself. Call the the support representatives, the manufacturers of this scare, and just ask them how to how to do this thing. And the engineer did that, and literally, like a 15 minute phone call had it up and running, you know, but it can be scary, I guess, to ask for help, because it makes us feel like, Oh, we're not good enough, or the team is relying on us to figure this out, and I have to be the one, but that's just not the case. I mean, from a leadership standpoint, I am far more appreciative of an engineer who understands when they have put enough of their own time into solving a problem and need to just ask someone else for help than I am the lone wolf who just wants to figure it out on their own, come hell or high water. So that's number two. Any any additions there, Brad,

Brad Hirayama: 12:09

This is a really big, I think, early career lesson that you need to recognize in yourself. This was that, that story that was me 10 years ago, when I first started, I had this feeling that I needed to beI needed to know, I needed to be that problem solver. I needed to figure out how to do things on my on my own, and then asking for help was almost like a sign of weakness. There was a lot of fear in that, right? What if I'm not competent? What if they think I'm not competent? But I think the really key learning for me was to very early on in whatever project that I'm that I'm starting, was to give myself a realistic time timeframe around this is my exploratory period. At the end of this exploratory period, I should either have it working, or I should know what the heck I don't know, or I can't get to work, or I I just can't seem to understand. And that's when I go and I ask for help, you know. And now that I'm further on into my career, and I'm, you know, I'm starting to lead younger engineers. What I'm telling them is, don't come to me and say, I don't know what to do. That doesn't help. Right? What I appreciate is, I want you to go and try to solve the problem and then come to me and say, this is, you know, these are the 123, things that I can't figure out, I can't get to work, right? This is what I've tried. This is what's not this is what's not working. That is so much more productive than spinning your wheels and spinning your wheels and spinning your wheels and trying to just figure something else out and then kind of throwing your heads up and going, I don't know what's going on, right? So this is a, this is a really great early career lesson. You are not weak for asking for help. Ask for help.

Aaron Moncur: 14:05

Absolutely, please. I am begging you. Ask for help. It's not a sign of weakness. And to Brad's point, I'm not suggesting that you just get help immediately, right? You shouldn't just go to your peers, your manager, whoever, and right away, just, how do I do this? You asked me to do this thing. I don't know how to do it. How should I do it? That's not what I'm suggesting. Again, what Brad was saying, give yourself a timeline, right? And this is going to vary depending on the task. If it's a relatively simple, maybe kind of low impact task that you've been given, maybe that timeline is an hour, and if you can't figure it out in an hour, then go ask someone if it's a much bigger problem that's probably more high impact on on the business, on your team. Then maybe that timeline is, you know, a few days, or even a week. And this is something that you can and should discuss with your manager. Manager, what's an appropriate amount of time for me to spend on this before I ask for help? And I promise you, your manager will be so grateful that that you had that conversation, versus you just spinning your wheels right and there. Now I want to make one more one more point here, you know,

Brad Hirayama: 15:17

I think you've heard of Tony Robbins. I think everybody's heard Tony Robbins, you know, and you can agree or disagree with what he has to say, but one of the one of the things that he really pushes, especially in some of his most recent conversations and podcasts and talks that he's been doing, is that your greatest asset is pattern recognition, and as you grow in your career, the reason you become more and more valuable is because your pattern recognition becomes greater and greater and greater. So it's not about solving the same problem over and over. Yes, there is some of that, but your ability to recognize we've already done that. We've already tried it. We've already gone down this path that led us nowhere, and then we had to kind of take a U turn and go down this other path that is your greatest asset. And the thing is, is that in early career, you know, really, anybody who's working on a team and working with other people, it's really, really important to leverage their patterns and leverage what they recognize has already been done in in their career. And like Aaron said, Have that conversation. Hey, this is a novel problem to me. Have you solved something like this before? And a lot of times they can say, I did something similar, and I tried X, Y and Z, and that really didn't, didn't work for me. But what I did find, found that worked was going down, 1123, you know. And that, you know, we talk about speed, right? You now have a jumping off point where you can start down that right path and understand where you're going, and then ask better, better questions in a in a faster way, you know. And the other thing I want to point out, Aaron, I'm sorry, I just so many thoughts on this, this pattern recognition portion, as you jump into leadership and as you have better patterns in your mind for how these things should be developed or done, when you start to delegate tasks out, whether you say it or not, there is always that thought in the back of your Mind that, okay, I'm giving this to you. Last time I did this, it took me about three weeks to do it. Okay? I kind of have an expectation. I'm going to kind of say, Okay, three to four weeks is what you should take to to come to that conclusion, that prediction came from somewhere. And so if you're being given a task, and it's, you know somebody saying to you should be done in four in four weeks, if you don't see what it's going to take to get that complete in that four weeks, ask, because they already have gone through it, and that's how they've gotten that, that prediction, or that, you know, that timeline in their in their head, and it'll just lead you down the right path, and then that gives you a pattern that you can then recognize for the next time that you do it.

Aaron Moncur: 18:06

Yep, it's not a sign of weakness, it's a tool for productivity. So just ask for help early.And you know, let's back up a second here and ask the question we're talking about, how to accelerate the speed of engineering. Why? Why do we even care if we accelerate the speed of engineering? What's the value in that? And this? I think there's two answers. There's kind of an altruistic answer, and then there's a commercial answer. The altruistic answer for me, anyway, is the faster we can do engineering, the more good we can bring to humanity. You know, you look around us and pretty much everything that we interact with on a day to day basis, outside of the people, was developed by engineers and all of these, these benefits that we have, you know, the phones that we use, the cars that we drive, how our food is delivered, plumbing, all of these things that came through engineering. So if we can accelerate that speed, we just improve the human experience by that much. The commercial point, which probably is the more salient one for just everyday life, here, is the fact that engineering is part of a business. And you might not like that answer, but it is true, and your value as an engineer is only as important as your ability to contribute to that business that you're a part of. So when, when you're trying to do something on your own and you're just spinning your wheels, you are not helping your business. You're it's a detriment to the business of what you're a part but when you can identify I need help, I'm going to go ask for help that helps you move things along, work quicker and meet business objectives more quickly. Again, it's probably a dirty word for some of you, right? You're engineers who cares about the business? Well, I'll tell you what, buddy you better care about. About the business, because when time gets, times get rough, and they do from time to time, you're the one who will be jettisoned if you don't have a keen eye on on how you specifically help the business, not just do the engineering work. Yep, it helped you in interviews for your next job. So Brad knows about that? Yeah, all right, so let's see number three, when. So this is within the context of troubleshooting troubleshooting a system. Specifically, when you are troubleshooting a system, don't troubleshoot the entire system in its entirety, troubleshoot individual components. So that means break the system down into its individual parts or subsystems and test those individual parts or subsystems by themselves. I'll give you a practical example of this. Years ago, I was working with a multi axis vision system. So there's a camera, and there were three different axes of motion, X, Y and Z axes, and the camera was not ending up where it was supposed to right. It would take a picture at the end of its travel, and that picture was not where it was supposed to be. That was very clear. Why it wasn't where it was supposed to be was far less clear. Was it a problem with the x axis of motion, the y axis, or the Z axis? And embarrassingly, I probably spent three or four hours troubleshooting the system. Could not untangle this mess of motion axes, and finally, it dawned on me that I'm such an idiot, I need to just break these down into their constituent components and test each one individually, which I did, after which it became painfully obvious where the problem was. It was so obvious. It was in I can't remember this point, but, you know, it was the Y axis. Something was wrong with the y axis. I It was a defective part. I remember coming to the conclusion ultimately, and as soon as I replaced that Y axis, everything worked great. But, you know, I spent hours trying to troubleshoot the entire system, couldn't figure it out because there's just too much going on at the same time. But as soon as I broke it down to the constituent parts and tested each axis by itself, it was just so, so clear, so easy. So when troubleshooting, break things down into their constituent components, don't try and troubleshoot the entire system at the same time. And this is a skill. This is something that you need to practice, because it's, it's so easy when you're, you know, looking at your your entire assembly, or something, to look at things as a system, because that's, that's where you're thinking, right where you're thinking is going.

Brad Hirayama: 22:38

You know, for me, the biggest example of this. I've got my first taste of doing, like a complex console assembly, lot of printed circuit boards, you know, everything kind of interact. You had wires going everywhere, plugging in and, you know, we had a day where we blew a fuse. And I, you know, in my world of things, I was looking at, okay, how do I, how do I figure? I couldn't even figure out how to figure this out there. It's so complex. There's so many things going everywhere. And, you know, I had a kind of my counterpart systems engineer that was working on this. And, you know, the first thing that he that he did was he pulled up a schematic, and he looked at, okay, well, the signal, I don't know where, I remember what it was, but the signal came from here, and it went to here, and it did this, and it did that. And, you know, in the time it took me to kind of freak out and say, Oh, my God, there's so much to do. And what by looking at, he had already diagnosed the problem. So exactly as you're saying, right? He took it down from this big to this big, and it was he was able to kind of get to that answer very, very quickly. Yeah, yep, great. All right. Number four, use simple experiments and basic instrumentation to guide decisions with measurable data. Data is so invaluable when it comes to making a decision. This could be part of troubleshooting. It could be part of just standard R D development, but, but use data, use instruments, acquire data, and then use that data to make decisions. Don't make decisions based on your your gut feel or I think this is the right approach. I couldn't come up with a great example, real world example for this one, just off the top of my head. But when we talk about basic instrumentation, we're talking about things like a force gage or a pressure transducer, maybe an oscilloscope, things like that, that you can use to acquire measurable data, and then you use that data to guide your decision. I think the most important part here is, is you said simple experiments and basic instrumentation, so simple and basic. And the thing is, is that the more complex you go, you add variables, right? And the that, in of itself, is just that complexity. Is, can, can muddy your your data, right? And at the end of the day, you have to ask yourself, Does, does my data actually tell me what I want it to tell me? Right? Numbers and arithmetic, they're great for understanding what's going on, but they're inherently dumb, right? You can get a bunch of numbers that aren't usable to you, right? So I think the key here is, is keep it simple, keep it basic, and then, if there is necessity after you can kind of get that first round going, then expand into something more complex, but simple and basic. That is, that is the key point here,

Aaron Moncur: 25:39

right? Yep. Okay, these next two are pretty closely related, but there is a kind of a nuanced difference. And instead of five and six, you One could say that this is more like five A and 5b But anyway, number five is is buy instead of build whenever possible, so you're not reinventing the wheel. We we built a fixture, I don't know, a year ago or something, for a company. It was just a simple metrology fixture needed to hold some parts stationary, and the whole fixture got mounted into a CMM, and then the CMM probe came down and touched off on these different parts to collect data and make measurements, and the most efficient way to hold these particular parts was using a three jaw chuck. And engineers, we love to design things right. That's part of why we became an engineer. It's fun to design something but it's also expensive to design something new, and so if you can just buy something off the shelf and use it instead of having to buy design something from from scratch, you should do that. Just a great way to accelerate the speed of engineering comes down to the business metrics, really. So we just bought some of these three jaw chucks off of McMaster and stuck them on top of our fixture, and boom, we had a great fixture that worked perfectly when, you know, we could have spent time to design our own three jaw chucks and just it wouldn't have made sense. It would have been a fine product in the end, but it would have taken us way longer. So whenever you can buy instead of designing something from scratch, yes, I had a mentor engineer who I've kept in close touch with. He, I guess he didn't really know it, but he subscribes to the IDEO style of thinking, where you think broadly and then bring everything inwards. And so he, when we were going through and thinking about fixturing, he would always tell me to start by being as imaginative as possible, you know, I want to solve this problem, you know, with the with the Rolls Royce of fixtures, right? I'm going to custom this. I'm going to custom that, and it's gonna move here, and there's gonna be sensors and this and that. And then he said, then start to think what can be replaced by off the shelf components. And that has always been a really good way of for me to think. I'll spend the first 30 minutes thinking about designing the nicest, beautiful thing out there, and then I'll bring it in. And eventually what I come down to is, you know, maybe I have two or three, three printed parts that are just holders for a bunch of stuff that I buy on McMaster, and it works perfectly fine, you know. And I think that's that's been

Brad Hirayama: 28:35

one of my greatest learning learning points is you don't have to be the most flashy, right to solve the actual

Aaron Moncur: 29:50

problem, if your company helps engineers design, build or manufacture better products, we should talk at PDX, the product development Expo. Companies don't just exhibit. They teach practical training right at their booth. Engineers walk away with new skills and companies build real relationships with the people who use their tools and services. The result is high quality connections built through real technical value. Pdx 2026. Is October, 20 and 21st in Phoenix and booth selection is first come first served. Many are already reserved to learn more about exhibiting. Email us at PDX, at Team pipeline.us, I recorded a podcast interview yesterday with one of our team members, Matt, and that'll come out in a few weeks. It was exciting because it was the first time we used our new pipeline, Media Lab, which is a fancy Media Studio that we recently built, to record a podcast. Anyway, Matt is brilliant. He's been doing this for 30 years, and he just has so. Much experience. And one of the things he said just matches exactly what you just mentioned. Brad, he he said he was talking about the importance of designing by subtraction, not addition. It can be so tempting for us to add things and add things and add things to our design, but what he always tries to do, like you said, come up with the rolls. Royce, right? What would the the ideal solution look like? And then, okay, what can I subtract or replace with something off the shelf? And keep doing that this? There's a lot of complexity there. How can I get rid of that complexity? So design by subtraction, not addition? Yeah, that's a great framework. I I'm going to use that from now on. All right, here we go with number six or 5b if you want to think about it like that. So this one is also about using off the shelf products, but it's specifically within the context of prototyping and R D, so you're not trying to build a final production unit of something. You're just trying to prototype, and you're going through development, right? And we had a great example of this recently, a pipeline. We're working on a medical device, and this medical device utilized some kind of, like soft cushions, like some soft goods materials, and we're not soft goods engineers at pipeline, we were great with metal and plastic, maybe some some rubber here and there, but we don't, we don't work with soft goods. So we could have messed around and maybe even hired someone to come in and, like, sew some of these soft goods, these cushions together for this device that we're working on, but it would have taken a long time and would have been really expensive. So instead, our engineer went on Amazon and found a similar product and just bought it. You know, it was like $60 or something, and it had these little soft cushion pads on it. And we just took those off and put them on our prototype. And now, boom, we had, like, a finished prototype, complete with these, these little pads, and it worked great. And, you know, $60 to buy something when, when you're talking about, you know, billing hundreds of dollars an hour for engineering time, and you can just buy something for 60 bucks and and reuse those parts. It's just a no brainer. So in the context of prototyping and Development, also buy something off the shelf and just tear it apart and reuse it, instead of trying to make something custom. Yeah, you know, and I'm, I'm starting to realize, too, that, you know, we're,

Brad Hirayama: 33:44

I think I'm I'm growing in my career in a very interesting day and age where there's not much left out there that is completely novel in some way or another. It's been done, maybe not for the exact application that that that you're using it for, but it's been done somewhere, and this is a great point where you don't need to always be the most inventive, the most innovative in your job. Sometimes it's going to take that, you know, in order to solve a really novel problem. But there's always a benefit to you to learning from what else is out there, or using parts that have already been developed and are being sold commercially. It's never going to hurt your process. In fact, there are entire businesses out there who their entire you know, business model is, take what's already out there, reinvent it, one for one, and then make a small tweak, patent it, because that's all you need, and then it goes out into the market, right? That's why you have so many of the same thing and so many options nowadays, right? So, you know, I think that this is a great point that you don't need to always, always be the most innovative you can use what else is out there. Somebody's probably already thought it, thought it through that has been, you know, that's has way more experience, or is way smarter than, than than you. So why not leverage their their experience in their time.

Aaron Moncur: 35:26

There's a quote, I can't remember exactly how this goes. I'm going to mess it up a little bit, but it's something like good artists create. Great artists steal, right? Just use what's out there. It's so much faster when you can Okay, number seven, so this is the last best practice that we will discuss today, and it is this one might be a little bit controversial. Actually, I could see some people maybe pushing back against this, so it'll be interesting to hear what kind of comments come out. But number seven is work. More, just don't overlook the value of working long hours. Now, obviously there needs to be some kind of balance right between like personal life and work life, and we don't want to work ourselves to the bone and burn out, right? That's not That's not productive for anyone. But there is something to be said for at least for specific periods of time. Maybe you're in a crunch and you need to work a few extra hours each week. Or going back to this interview I did with Matt yesterday, one of the things he talked about, and he is such a good engineer like he he's cream of the crop. This is the kind of engineer that any engineer should aspire to be. He knows so much. He's so good at what he does. And he talked about how he's just naturally curious, and he wants to learn about these things. And he regularly spends his own time reading books and just learning about different technologies out there, because he finds them fascinating. I worked with a young engineer years ago who was ambitious but also wanted to take shortcuts. And I remember him coming to me one day and saying, Aaron, how do I get better faster? How do I accelerate my progress? And my answer to him was, you probably just need to spend more time perfecting your craft. You just need to work more like there's something to be said for just getting those reps in, you know. So don't overlook the value of just working more. There's a balance. Don't push it too far. But, you know, 40 hour work week, maybe you spend an extra hour a day and you have a 45 hour work week like that, shouldn't kill anyone. And that extra hour a day, the cumulative compounding effect over time will be enormous.

Brad Hirayama: 38:00

And I'm going to add to this again, from personal experience, you have to have intentionality and focus if you're going to do this. So in in Aaron's example, you know that that young engineer, he wants to develop his craft so working more meaning, maybe taking an hour a day to do extra CAD practice, you know, to be a little bit more efficient in your style of CAD or, you know, if somebody is, is, you know, really wanting to be a leader, right? Maybe, maybe taking an extra hour a day to watch a TED talk or take a leadership course on online, right? There has to be intentionality. Where this fails is if you just think I'm going to put the hours in, but those extra hours don't really do anything for you. So you're thinking, Oh, I've worked 10 hour days for the last year, and I don't feel like I've done anything. Well, what did you do with those extra two hours? Right? Or, because you worked 10 hours, did you feel like you could take an hour and a half lunch and, you know, 515 minute breaks and you're on your phone and you know, is, was there no intentionality in in what you were doing? So this, I think, only works, and I'm not discrediting this point, but I think this only works if you are able to really focus in and be intentional with what this, more work, more time does for you, and as you get into different seasons of life, you know, things change. I've, you know, recently transitioned to being a being a dad. So I have a young, a young son, and, you know, I think that I spend probably seven hours of working time a day, but I think that that seven hours I've been more productive in the last couple of months that I've been working than in my last role where I was working 10 hours, right? Because I'm intentional. I know that this is my working time because I have family time coming up, right? And so that intentionality really makes a difference in your development and then how fast you can go.

Aaron Moncur: 40:53

Pipeline now offers procurement of custom machined parts at significantly lower costs without sacrificing speed or quality. We design and build custom machines ourselves, so we consume a lot of precision machined components. Over the past several years, we developed a proven overseas supply chain to support that work, and in 2025 we successfully piloted that capability with select customers. Now we're opening it up more broadly, if you'd like to see how our prices and lead times compare. Send us a drawing or two for quote, visit team pipeline.us, or message me directly on LinkedIn. Well, Said, I think that's a great point. The intentionality. It reminds me of a funny story. Way back when I was in high school, my friends and I, we started lifting weights. Of course, they all got big, and I never did because my genetics just aren't there. But anyway, we we started lifting weights. And there was this one guy who was part of the group, and after, after a few months, it was we all noticed that, like, he had gained some weight, like, put some weight on, not muscle weight, it was, it was mostly fat. And we're like, what's going on with you? Like, how are you just getting fat? And he says, Well, I've been taking this, this weight gainer, you know, this weight gainer shake. I've been drinking it every day. And we're like, okay, and, and, like, what else he was like, Well, that's it. I just take this weight gainer shake, and I thought it was supposed to make me stronger. This guy wasn't even working out. He was just drinking weight Gator every day. So, yeah, there needs to be intentionality and some kind of plan behind the extra time that you spend, the high school days, the high school days, yeah. All right. Well, there you have it, seven points. So quick recap here. Number one, use the right communication medium for urgency, which is generally in person conversation or a phone call. Number two, ask for help early and time box, those solo problem solving situations, so you avoid going down rabbit holes for too long. Number three, when you're troubleshooting a system, break that system down to its constituent components. Don't try and troubleshoot the entire system at once. Number four, use simple experiments and basic instrumentation to gather data that you can use to make decisions. Number five, buy instead of build whenever possible. And number six, you when you're prototyping something again, buy products and just use those in your prototypes. Ultimately, you'll probably have to design something yourself for production, but when you're just doing R D, buy what you can off the shelf, tear it apart and reuse it for your prototypes. And number seven, work more. Don't overlook the value of just putting in the extra time getting those reps in with with intentionality, like Brad said. So that concludes episode one of three for our mini series on the best practices of how to accelerate the speed of engineering. Thank you so much for being with us today. And Brad, any any final comments before we close here? Yeah, can I give them a bonus one, something that I please so I've been thinking about this a lot, and I I think a lot in sports terms. I love sports, and grew up playing sports my entire life. And one of my favorite books is called the inner game of tennis. Never been a tennis player, but if you if you've never read that book, it's just about how you know tennis is such a

Brad Hirayama: 44:46

it's a sport where you're one on one. Points come and go so quickly. I think Roger Federer is quoted in there saying that, you know, he the best tennis player arguably ever to play. He only won 53% of his points across his entire career, right? So how did he keep his mental game strong over that other 47% right of of his playing time. And one of the things that's really harped on in that book is all of the top athletes put a lot of focus into the small, boring, mundane things that a lot of people overlook, and that, in of itself, is what makes their game, in totality, so much greater than their competition. And I think when you apply this to a business sense, you apply this to your time being an engineer, or whatever you're you're doing currently, think about the small things that you've just been kind of let slide right? You know, for myself, I'm thinking about like I really wanted to, you know, get this part quoted out. And so when I made my when I made my drawing, I kind of half assed everything. I didn't put tolerances, I didn't finish my drawing. I didn't pull a part number, whatever it may, whatever it may be, right? And what did that, what did that? What did that lead to? That led to me sending the part out to the vendor, the vendor coming back with questions. Me having to answer the questions three, four days go later, or sorry, go by and I'm still not I don't have a quote, right? But if I spent that extra 1520, minutes completing that drawing, would have had the quote next day, right? So put your focus into those small things. Do the small things really well. And when you talk about acceleration, right? If you can continuously stack up point 1% improvement or efficiency gains, that point 1% over. Of the lifetime of a project, it's going to compound exponentially, right? And so if you can do that every single day and make it a habit, I'm going to continue to do these small things every single day, your your overall game, right, your overall result is going to be so much, so much better.

Aaron Moncur: 47:04

There was a I'm going to get some of the details wrong here, but the general high level message is accurate. There's a British Cycling Team. This is quite a while ago, I don't know, 2030, years ago, something like that. And within the world cycling circuit, this British team was pretty universally considered to be one of the worst teams in the world, and everyone knew it, and they hired a new coach to help improve this team. And the focus of this coach was not to make drastic overhaul changes to the team or how they trained. They focused on 1% better. How do we get 1% better here and then 1% better there, and then 1% better there? And I wish I could remember some of the specific things they did, but none of them were earth shattering, large changes. They were just really small tweaks. And over time, like you said, Brad, they compounded, and that British Cycling Team became a true contender. They were one of the top teams after, I don't remember what it is, a few years, but in a shockingly short period of time, they climbed from being one of the worst teams to one of the best teams because they focused on 1% better every day, just trying to make these small, little changes that compounded over time. There's so many stories like this in sports. You know, Bill Walsh with The 40 Niners back in the day. He has a he has a whole book that he wrote about how he took the 40 Niners to becoming that, that championship dynasty, right in the in the 80s and 90s.

Brad Hirayama: 48:45

You know, it's interesting to me, because in sports, this is so apparent, it's something that it's so tangible, that that can be seen, whereas in engineering, this is, this is a point that's not super tangible all the time, but it's one of the keys for yourself, if you can convince yourself that these 1% improvements are going to make you better, going to make you faster, more efficient over over time. You talk about, how can I get ahead? Or, you know, how can I be faster in my career? That's, that's what you need to focus on, right? It's not about getting another degree, right? That's like a big 20% you know, you know, part of the pie, right? If, in that time that that you spent getting your degree, if I just spent a bunch of time getting my one percents down, I've surpassed you already, right? And so I think it's really important that, you know, again, this is done so much in sports, to really take that lesson and apply it to your engineering time. And I think it's becoming more and more apparent that that's what is going to set you apart,

Aaron Moncur: 49:55

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