Being an Engineer
Being an Engineer
S7E13 Brad & Aaron | How To Accelerate The Speed of Engineering (Episode 2 of 3)
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
In part two of this three-part series on accelerating the speed of engineering, Aaron Moncur and Brad Hirayama shift the focus from individual habits to team workflows. Drawing from patterns that have surfaced across 300+ Being An Engineer interviews, they explore how better systems can help teams move faster from idea to hardware to validation.
Brad and Aaron dig into practical ways to reduce wasted time and avoid preventable mistakes: defining requirements clearly, validating what actually matters, prototyping early, running strong design reviews, using checklists, testing options in parallel, involving manufacturing sooner, and centralizing project data so engineers can spend less time searching and more time building. Along the way, they share real stories from quoting automated equipment, catching costly design flaws, improving drawing quality, and avoiding production headaches.
This episode is packed with actionable insight for engineers, engineering leaders, and product teams who want to streamline development without sacrificing quality. If you care about building better products faster, this conversation offers a clear playbook for improving the workflow behind the work.
Aaron Moncur, host
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
Just because you have the greatest design, it doesn't mean that you're going to be able to actually make it.
Aaron Moncur:Hello and welcome to another episode of The being an engineer podcast. I've got Brad here with me again today, and this is episode two of three of our mini series about how to accelerate the speed of engineering. So last time we talked a little bit about how the individual contributor can directly contribute to accelerating the speed of Engineering. Today, we're going to lightly focus on the theme of how to focus on workflows going from idea to hardware to validation. So without further delay, let's jump into this. All right, let's go. I'm super pumped for this errand, like this is my life right now. This is what I live every day. These are a lot of the questions that I have to fight for when I'm in meetings and talking to people. So this is, this is a fun topic for me, so hopefully that gets conveyed in my stories. I can already hear the excitement in your voice. Yeah, it's gonna be a good episode. All right. Well, Brad, since you're feeling so pumped up about this, do you want to read through these? And I'll chime in where I have examples.
Brad Hirayama:Yeah, let's go. So number one on this list, and just a reminder. Aaron, so these, these are topics and points that have been compiled over the last 300 plus episodes of The being an engineer podcast. And we've pulled these because they keep coming up, maybe in different words, but the themes keep coming up over and over again. When Aaron goes and talks to these different high level engineers, business owners, what have you when they're talking about how they are trying to speed up engineering and speed up engineering for their for their team. So talking about workflows, let's look at the first one. So the first one that we have today is to define your requirements early and define how they will be verified. Now this is crucial for the sole purpose that you don't want to build something that the market doesn't want. So you don't want to over engineer something. And I think this is one of the most important things and one of the most important steps that that you can take just, you know, taking that extra week to really define out your problem, because you don't want to get all the way to an actual product and find out nobody wants to buy this, right?
Aaron Moncur:Yeah, I I've got a good example for this. This one still makes me a little a little furious inside. I spend a lot of my time quoting projects, and when we're quoting something, it's a big, automated machine, sophisticated. It's not something that takes an hour to quote. It'll take us 20, 3040, hours to put a quote together for these machines, because there's just a lot that goes into a lot of complexity. And so we had a customer, this is a few years back, who brought a project to us and said, Can you give me a quote for this machine? And one of the requirements, which they emphasized several times when we spoke to them in person, was that the OEE had to be 95% or greater. Now for those of you who aren't familiar with the term OEE, it's basically a measurement of how, if not efficient, how reliable a piece of machinery operates. And 95% is actually quite high. And so we saw that and said, Oh, wow, that okay. They're they're serious about this thing. It really needs to be operating it at a high level of reliability. So when we put our quote together, we spent a long time thinking about and focusing on, how do we make sure we hit that 95% OEE level, and as a result of that, we put a lot of process development time into our quote to test and validate that our solution was actually going to work. So we presented the quote to this customer, and they said, Oh, this is way too high. We love the concept that you came up with, like the conceptual design, excellent. We love it, but the cost is way too high, and we're going with someone else because we got another quote that was just a lot less, and their concept, arguably not quite as good, but we think it's good enough, so we're just going to go with this, this other company. And I was so disappointed, because we're so excited about this project. It was going to be a challenging, super fun project. And we asked them afterwards, we said, hey, can you give us some feedback? You know, what? What can we do next time to be more competitive? In this kind of quote. And they said, well, the you know, your cost just needs to be a lot lower. And we said, I get it, you know, thanks for that feedback. The reason our cost was what it was was because we put in all this time to make sure we hit that 95% OEE and our customer kind of stopped and looked at us, and they said, Actually, I said to them, you know, is there any room to relax on that number? I know you were pretty firm when we talked earlier about it. And they said, Yeah, I mean, 75 or 80% would probably be good enough. And I just, I wanted to wring their neck, you know, like we spent all this time making sure we hit that 95% number, all to find out at the end that it's not really that important, and we're gonna go with someone less expensive, who didn't put all that time into hitting this this high value. So anyway, we would have saved a ton of time, and the customer would have saved a ton of time. We probably would have got the project if we had known that requirement, and, like, how stringent it was or was not at the time, so that, that's my example of making sure requirements are not just defined, but like, really verified before moving forward.
Brad Hirayama:And you're, you sit in a very interesting position, Aaron, I you know, I've never worked on the contract design or contract manufacturing side of things, but a lot of what I find sitting more on the OEM side is the better you can give your vendors. Really, not what you're necessarily looking for, but what you need, right? Like, I'm going to look for the world, right? I want the perfect thing. But what do I really need? That's how you speed up conversations, you know. And I was just having a conversation with the vendor the other day, and, you know, it actually came down to kind of the same thing. They had all these great ideas. And we could do this, we could do that, you know, we could quote this, we could bring this machine, and we could do all of this stuff, you know. And really, it's like, you know, they had spent multiple weeks probably looking into this stuff, ideating. And really, what it came down to is, guys, you didn't, you didn't really listen to what I was saying. You know, I don't need the Rolls Royce of fixtures. I need to machine parts put together, you know, with really, really high repeatability, and, you know, precision on the on the machining, yada yada. So I think that it's really important to understand this from both sides of the coin, on the side where you just need to make sure that you're communicating not just what you're looking for, but exactly what you need, right? And that's where being clear on what the end goals of your project, or whatever you're working on is, it's, it's, it's turmoil to your to your success.
Aaron Moncur:I'm glad you brought up the the context of looking at it from the customer side, because one more piece I need to say here, but this, this is a my Achilles heel, a thorn in my side. And oftentimes, when we start talking to a customer about a piece of equipment that they need, they we ask them, what's your budget? We might not say it exactly like that so directly, but we effectively ask them, like, what? What's the ROI that you need to have on this piece of equipment to make it make sense to the for the the business to justify purchasing this thing. And so I would say nine times out of 10. The answer we get is either I don't know or Well, you tell us what it's going to cost, and then we'll let you know if we can afford that. And like, I get it right, what they're worried about is they're going to give us a number, and what if we could actually do it for far less than that number? But then we hear that number, and we come, oh, well, yeah, that's exactly what it's going to cost, right? So, you know, customers are leery, probably because they've had bad experiences before that we're just going to maximize the cost and overcharge them. But a, that's not how we operate. And B, talking about speeding up engineering. Well, there's more to it than just, you know, doing r, d more quickly or CAD more quickly. There's like, you the position you're in, Brad, right? You're dealing with vendors, and time is money. The sooner you can get a quote back that you can actually get approved, the sooner you can move forward and get the tooling, the fixture, whatever you need. And you know, realize revenue, ultimately, is what this comes down to. So giving your, if you're in a position like that, like Brad is in, giving your your your vendors, like a target, is actually. Going to speed the process up, because then we can get into this, and if, early on, we realize, oh, it's going to be 2x what they want to spend, we can just stop and go back to the customer. Hey, thanks so much for giving us that target, because we're going to be at least 2x and we either need to stop right now and give you some time back, and give ourselves some time back, or realign somehow figure out a refined scope of work here, so that that anyway, that's thorn in my side, like I deal with this constantly, and it is absolutely a way to speed up engineering.
Brad Hirayama:Yeah, no, and that's a, that's a great point. I'm glad that you brought it up. You know, it's, it's definitely something that's a learning experience and that everybody needs to learn. And so moving moving forward, whether, whatever side of the table that that you're on clear communication, right? Be clear about what you need before you go into these conversations. Okay, moving on to number two. So number two, so this one. This is a great a point that I, that I love. So the point here is to fail early and inexpensively by getting to hardware fast and prototyping soon and often. So it's really easy, I think, for us to say here that 3d printing, 3d printing, is just the perfect medium to iterate fast, to get from idea to something in your head, right? The new form labs printers that you could have something in in like an hour, right? So you could be designing in the morning and have a prototype by the afternoon. I think that's really powerful when it comes to how quickly you can validate your your ideas. But let me give you a tell you a quick story. This is just a little, little anecdote, something I've been reading about and and researching. Have you ever heard the story of James Dyson, the Dyson vacuum cleaners?
Aaron Moncur:Some I've heard some of the story about him.
Brad Hirayama:Okay, so James Dyson, right in the 70s in the UK, he had a problem, right? He was selling vacuums. They weren't great. They were losing suction. The bag design was not so was not so good. And so he set out on this quest journey in order to better the vacuum. And it depends on where you read. But it took about 15 years and over 5000 different prototypes for him to land on the Dyson vacuum that that we know today, using the cyclone technology, and it's bagless. And you know, all of those things that you think about, that kind of premium brand, of what Bryce of, what Dyson brings. His mantra was, he didn't iterate on paper. Everything was was physically done, and every time that he failed, that was considered data in his process. It took 5000 prototypes for him to get where he needed to go. Now, granted, I I'm just making some assumptions here because I wasn't alive in the 70s, but I'm assuming that prototyping in the 70s, 80s, 90s, are a lot different than what we're talking about today. However, I really do believe that in this story, the things that the key fundamental principles here remain the same. You need to fail first. You need to fail fast, and you need to fail often, and failure sometimes is kind of a taboo word, right? People think of failure as being super negative, but if you can switch your mindset, especially when you're developing, doing some type of product development to failure is great because failure taught me something. You then kind of gain this momentum behind you, and you're able to get to your end goal that much faster because you've learned every single step of
Aaron Moncur: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. Yeah, that's a great example, the James Dyson example. There are people that I've talked to who I'll talk about fail fast. And little bit like, Whoa, I don't like that word fail fast. Well, why don't we even say that? And, yeah, I get it right, like we're not really talking about failing though. We're talking about learning and iterating and developing. And fail fast is just a fun, kitschy way to say it.
Brad Hirayama:Yeah. So this one, I think, is near and dear to my heart. It's something that I've, I've always been very adamant about. I like physically building and physically being, not just, you know, on the computer, on paper, designing something I like to show and tell and so, you know, there's a, just a quick another story, just, you know, this is something that I preach in every company and every team that I'm, that I'm a part of, that it's great if you have an idea, but don't tell me about it until you've tried it, you know. And every time I tell you know, I have junior engineers. I'm volunteering and mentoring college level engineers with their design projects. You know, if you're going to come to me and give me a presentation with this idea, and it's still in CAD and you don't have any real time pictures, and you haven't told me you've touched the part, I don't, I don't need to hear it, you know, I'll give you another week, because it's just there's something valuable being about being very tactile with what you're doing as a product development engineer. So get off my high horse, but prototype fail first,
Aaron Moncur:and you mentioned 3d printing, which is a phenomenal way to prototype. It doesn't even need to be that sophisticated. We're doing a project, or recently did a project where we needed to develop a fixture to erect these cartons, long, pretty stiff boxes. And initially we thought about, okay, well, we could use pneumatics to do this, and we could design a little kinematic linkage here. Ultimately, our engineer literally used some duct tape and some spare plastic scraps that were lying around the office to kludge together a very crude proof of concept prototype. And it worked great. And we showed the customer, and we're a little nervous to show them, because it was very crude. I mean, literally, duct tape and some plastic scraps. And they saw it, and they're like, this is great. We love that you guys MacGyvered this thing together. That's it's perfect for this the stage where we are right now. So doesn't, it doesn't even need to be 3d printed. Find some cardboard and duct tape around and start there.
Brad Hirayama:And it really shows your level of engineering talent that you have, if you can think in that way. Okay, you good? Moving on to number three. Let's do it. Let's move on to number three. So Number Number three is a really interesting so number three is to hold regular design and drawing reviews before ordering parts, and be sure that you're including more senior engineers, and I'm going to add a little piece to this, but more senior engineers that may not be directly a part of the project. What's really interesting about this point is that, especially as you get further and further into your career, engineering becomes about patterns. We talked about pattern recognition last time. And what a more senior engineer who hasn't been in the weeds trying to design this, this fixture or this entire system, what they're going to be able to do is they're going to be able to notice patterns that are outside kind of the realm of your vision, not that you missed it, but they're going to be able to ask you questions that will make you think through things in a in a different way. This is a, I have a really powerful example of this. So I was working with, I was consulting with, with the company, and they were quite far along in their design process. And one of the first things that I was, I was asked to do was, hey, just come in. You know, we're going to start kind of reviewing designs, very briefly, you know, with everybody there, but just come in so you can learn the product, right? And it was very apparent that, you know, they had a very, very strong. Long engineering team, a lot of them more senior than myself. But what the really, what they wanted me to do was just come in and ask questions, right? To give them a different point of view. This team was really, really good at early development, right? They could really, they were the true 00, to one team. They were a true team of we're going to throw you out into no man's land, and you're going to come back with something. What they didn't have is they didn't have the manufactured mind. And so they had developed this product all the way through, and it was great, and they had built a few of them. And it was, it was a it was a really cool product. But as I kind of sat in these meetings and started to ask questions, what came out was, how were you going to make this like, Have you even thought about how this part and this part were going to come together? You know, it's not just as simple as putting them together, there were so many steps in between that that they didn't think of. And I think this is one thing where I was an outside point of view. I came in at a very pivotal point of the project, not questioning their designs or why or how they did something, but just giving another point of view of like, hey, maybe we should rethink the way that you've done this, not to lose the design intent, but to make sure that down the line, we're not, we're not, we're not forced to redesign, because these parts really aren't many manufacturer and this, you know, this even, even for myself, it was a it was just A huge eye opener. I was had such bad imposter syndrome coming into this. I knew the players at the table. I knew them by reputation. When I was entering the room, I knew who the manager was. I mean, I had met him, you know, he had, he had brought me on board. And so, you know, I came into this like, what can I even offer like I don't understand right? These guys are so senior to me, but really it was that outside perspective that I think is really going to be the catalyst to push that project forward, not just on the innovation side, but then on the manufacturing, manufacturing scale side.
Aaron Moncur:The 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. Great example. It makes me think of an experience I had probably six years ago, something like that. We were building this machine, and I was in charge of designing a little housing for one of the products that was being tested in this machine. So I designed it all up. I used my CAD best practices. I've always loved CAD, and frankly, I feel like I've always been very good. I've strong CAD mechanical design skills, and I've prided myself on that. So anyway, you used all my best practices. Got the design ready to go, and we were about ready to send it off for to get to get machined at a shop, and one of our brand new engineers asked if we'd done a design review. And I thought to myself, well, good point. We haven't done a design review on this one item that I had designed, and part of me was like, I'm a Senior Design Engineer. I own the company. I mean, do I really need someone to review my design? Obviously, it's going to work and it's going to be great. But I swallowed my pride and said, Yeah, okay, let's, let's do a design review. So this junior engineer looked at my design. He'd probably been full time, like outside of school for maybe two years, maybe, and he found a critical flaw in my design, like the door wouldn't open when, when a piece of hardware was installed in there. And, yeah, obviously that's a problem, the door to the housing doesn't open. So I very, you know, I thanked him. Said, Oh my gosh, great. Catch you know. Way to go, and we made a simple design change and sent it out, and it was great, but just goes to show you, it doesn't matter how senior you are. You get tunnel vision on your design, and it blinds you to certain possibilities. So having that design review, it's just critical. I mean, it's like a deal breaker. Must have no way around you.
Brad Hirayama:Just, you just have to do that. Yeah, you know. And this is, you know, again, for teams, I think this may play more into the next episodes. I'll just touch on it. But this is why there is so much value in having a breadth of breadth of experience on your team. And when you build a team, it's not just about, you know, having the best people, always only the best. You know, you need those diverse perspectives of the more junior folks that are still learning, that have different upbringings, that you know have learned different skills or software's. It's just, it's one of the paramount, most important things for teams to realize. Awesome. Okay, ready to move on. Let's do it. So the next one, the next one, I believe you've written about, you've talked about, I've heard you talk about this one more than more than once. So the next one is to use checklists to error proof human tendencies. And I think that this is, this is something that's, that's funny, because it's, I've done this my entire life, even before I was an engineer, right? This was part of my personal life, I always have checklists. You know, if I'm traveling, I have a checklist of what's going to go in my bags. And I really think that it's important to bring this up, because this is what streamlines the whole process. You're not trying to pull, you know, pull thoughts out of thin air all the time. You've done the thinking once and you moved in, and then you're able to execute.
Aaron Moncur:Checklists are shockingly powerful. They're such a simple tool, but they literally have the power to make or break a project. There's a wonderful book called The Checklist Manifesto that if you haven't read, I highly recommend picking up. It is well worth your time. It's by Atul Gawande, who is a physician, physician author, and he's written several books, and they're all wonderful, but this one in particular really hits home for me at The Checklist Manifesto. I remember just one of many examples probably 810, years ago. We We had this customer that we did a lot of work for over the space of probably six years, and I don't know, maybe a year into that six years, of course, we didn't know what the time is going to be a six year engagement, but maybe a year into it, we delivered a drawing package, and this customer was pretty particular about how their drawings were created. And to that point, it was all tribal knowledge. You know, we delivered some drawing packages in the past, and they'd give us some feedback. Oh, do it this way, not that way, but it was all tribal knowledge, right? It wasn't written down anywhere. And so we delivered this drawing package, and they kind of got, not angry, but like a little huffy with this. Hey guys, we've told you multiple times now, do it this way, not that way. And there were a lot of different elements to it, right? It wasn't just one thing. There were probably, like a dozen different, very specific things that needed to be done in a certain way. And we realized, man, why haven't we created a checklist for this? And so we did that. We created a checklist, not just with their best practices that they wanted to see, but with our best practices that we knew occasionally get missed on a regular basis. And we came up with, like, it was pretty long. I think we had, like 40 items on this checklist, and we started using it, and it was great. Don't get me wrong, like those 40 items, made sure that we caught everything. After we used it a few times, we realized, you know, there's probably a subset of this that is the sweet spot, yeah, the Goldilocks of Goldilocks zone of checklist, where it's not so long, but we still get the most critical thing. So we paired it down to think it were like eight or 10 items. And we used that for years, and it worked so well, we just had a little Excel spreadsheet with this checklist built in. And you go through, you know, one item at a time, and especially when you have, you know, 100 drawings that you're checking for a large piece of equipment, you have different team members, and they, you know, take one, they take 20 rows each, or whatever it is, and they just go through check. And as you're going through the process, it's pretty easy to see how far you are through that process of creating all these drawings and how. Close you are to being done. So that was huge for us. And the customer never had to complain again, because we finally got it right.
Brad Hirayama:Yeah, consistency is key, you know, it's I've worked in startups my entire career, so I haven't had a chance to be a part of a team that's like, you know, this team has been together for 15 years, or they've worked on a single project for half a decade, or, really, yeah, half a decade. But I'm finding that, you know these checklists, you're talking about it kind of at the product level. But even for myself, I have a little notion page that I that I keep, that I keep my design frameworks and my design checklists on that, on that page. And, you know, kind of similar to you, I have my my drawings checklist that I've added to in pretty much every role that I have, I've added something. Yeah, I'm gonna have to remember to do this, or I really like the way this company does that, and added it to my own checklist, so that again, you're just streamlining and you're creating this consistency, right? And you know that's what you want to be known for. You want to be known for somebody who's been consistent, who can consistently deliver not just high quality, quality work, but consistently put up with, right? That's, right, yeah, awesome. What a great story. I'm, I'm, I would love to work for a company that you know thinks about it at that high level. And I think that that's, that's something that's, you know, really what's unique about about pipeline so thank you. Free plug for pipeline design and engineering. Now about why their product development process is streamlined. They are going to make you something great. Free ad here, here in the middle of this episode,
Aaron Moncur:thank you, Brad, your Venmo payment will show up tomorrow. I Yeah, all
Brad Hirayama:right, so let's move to the next one. The The next one is, is, is a fun little experiment that a lot of people actually play with here, especially in the startup world, but it's to test multiple options in in parallel. So for example, you have an idea, this idea could be designed, you know, an A, B and C way, and you're really not sure which way is going to be the best. Like you think it's going to be a, but it might be B, it might be C. Why not just order all three at once, get them all in and then just try them, right? So this, this goes back to, what was it? Point number two, right, fail early and fail inexpensively. Here, if you're not really you know the cost that you incur to just buy that one extra prototype fixture or whatever it is is going to just speed everything up, whereas if you had just stuck to your gun and said, No, it's definitely a, and then that fails, then you have to go to B, you know, you're, you're, you know, just kind of building in speed, right by, by bringing everything in together.
Aaron Moncur:I remember really, like viscerally identifying this best practice when I interviewed Joe Moke, who is just an awesome, phenomenal engineer, he's been on the podcast a few times now. He used to work at Apple, and he was telling me a story about parallel development paths that they took. I can't remember what the product was, but, but it wasn't just a part, like a single component that they wanted to test in multiple configurations. It was like a full development path. And they they identified two, or even three, I can't remember now, but at least two different development paths for this, this product, and they had different teams that were going down both paths because they didn't know which one was going to be the right path. Now we're not all Apple and we can't all afford to do that, but the point is, you can do this, this parallel development at many different levels, right? Maybe you can't develop effectively two products at the same time in parallel. But I had a great example. Just last week. We had a prototype that we were trying to finish on a pretty tight timeline so that we could present to a customer, and we needed to 3d print some parts. I generally don't do the 3d printing, but in this case, people were tied up, and I stepped in just to do some 3d printing and help out in that way. And I wasn't sure which orientation was going to produce the better part for this prototype, and we really didn't have time to, like reprint things. So the additional cost of just printing. This part in multiple orientations, was like$2 right? It was nothing. So of course, we're going to do that, whereas if we had been pinching pennies, I don't want to waste, you know, extra material on this. Let's just do it serially. It would have cost us an extra day, which we didn't really have at that time. So, I mean, this can be done at completely different levels, right? Whether it's 3d printing the same part in multiple orientations for a few extra dollars to see which one turns out correctly, or literally developing the same product in different paths, like Apple has done and everything in between.
Brad Hirayama:Yeah, that's a, that's a great story. I've heard stories about the culture at these, you know, very large companies where it's, it's almost like you you have your end goal, and then all of these teams come out, kind of like, Shark Tank, and it's like, this is how, this is what we're doing, and this is how we're going to do it. And you know, it's so interesting to me that they do it that way. But you look at the products that a company like Apple is putting out, yeah, and it makes sense, yeah.
Aaron Moncur:I mean, for companies like them, not just for Apple, but for a lot of companies, the speed is a lot more important than the money that would be spent to attain that speed, right?
Brad Hirayama:Yep, and that's a, that's a, that's a great point. I think that cost is not just about dollars, right? Yes, cost can mean a lot of different a lot of different things. Yep, great. So the next one, the next one, ties back into a little bit of the story that I was talking about for design reviews. But the next one, you know, even I've heard multiple times in the in the episodes that I've listened to, and I strongly believe, because of my background, but you really need manufacturing's feedback early on in the design process, so that you don't have nightmares in production down down the line. And I think this is important for all engineers to realize that just because you have the greatest design, it doesn't mean that you're going to be able to actually make it. Yeah, I did really quick story though. I my in my first job, I created what I thought was the best fixture ever. It was so beautifully designed, and it did everything that it needed to do, and it was going to be so great. It was so I was so proud of it. And the first thing that the principal engineer that I was working under said was, how are you going to make that so he said, Go ahead, tell me how you would machine this. Okay, and so I went through, and I started to make a plan, okay, I would start it here. This is my orientation. I take this mill, I do this. And then I got to the point where I had, and I was looking at the part, and I was trying to figure out, how do I get to the other parts? And he was sitting there and listening to me right? This young, overzealous engineer gets so excited about this beautifully designed fixture and then hit the undercuts and deflate.
Aaron Moncur:I love that he used a question to teach you right? Because he could have just said, you can't make that. It's not machinable. It's not manufacturable. But he gave you the the privilege and the opportunity of teaching and convincing yourself by using a question as opposed to a directive,
Brad Hirayama:and that's where the biggest learning came from. It was drilled into my mind, and that that specific moment is drilled into my mind, not just because of undercuts, which are still the bane of my existence, but just the keeping manufacturing at the forefront of your mind is always going to make you a better designer, and it's always going to make it so that Your design process is faster.
Aaron Moncur:There is a large global pharmaceutical company that I am aware of, without naming any names or getting too specific on the details, who purchased a design, basically from a third party, a different company, and this design, you know, again, I'm not going to mention names, but you would think that a company like this, their size, their experience, their their breadth, they would have enough foresight to ensure. DFM had already been done all this design before purchasing it, but apparently this company who did the development had only ever produced prototypes, and they really hadn't gone through full DFM like it was a plastic part assembly with multiple plastic parts, and the only way they had prototyped these had been no draft, no, no. I think that was the big one. They had no draft in their parts. And they just threed printed these things. So tolerances were, you know, plus or minus, whatever they were, five thou or something, but no draft in these. And everyone said, Oh, draft is not going to change things that much. You know, it's minor. So anyway, this, this large pharmaceutical company purchased the design from this third party, and they went into production with it, and lo and behold, they started having problems. It didn't fit together quite right. It didn't function quite right. Once the draft was in there, once the tolerances were, you know, production, injection molded tolerances. And they spent, I think they spent a year trying to fix production, and ultimately came to the conclusion that we can't fix this in production. We need to go back to the design and, like, really, just redesign this for production. So, you know, big experienced companies, they have this same problem. And if they had just designed this thing with manufacturers feedback, put the draft in there, made sure tolerances weren't going to cause problems, they would have avoided couple of years of delay on this product. Yeah, what an absolute nightmare. Yeah, totally, like, that is the worst case situation, right there,
Brad Hirayama:yeah, you know. And it's, I'm, I'm, I'm guilty of this. And so, you know this, this is why I'm going to say it. But you know, manufacturing doesn't get the glitz and glamor of development or, you know, being in R and D, or being in that, you know, so forward thinking advancement of technology, but manufacturing is, that is true reality. That is where the biggest impact is made, you know, and I didn't really understand that until going through the second startup post acquisition and hearing kind of how the big company that that acquired us shut down our site, the last person to close the door was manufacturer. And that's because from start to finish, the biggest impact was manufacturing. So, you know, there's a little bit of nuance to this topic, but manufacturing really is where a lot of the learning comes in. And I am a huge advocate and very glad that I started my career in manufacturing, giving me that kind of, you know, Nikki in the back of my head that always says, Is this manufacturable? Is this manufacturable? But you know, really, you know, to kind of bring it back to this manufacturing should be the first team member that sees your new design before you even show it to the rest of your R D team, somebody in manufacturing should be a part of your first review, because they have a good gut to understand, can we actually make this?
Aaron Moncur:That is where the rubber meets the road, for sure. And most shops out there, most factories, machine shops, they're happy to spend, you know, 20 minutes with you looking at a design, because ultimately, it's going to make their lives easier.
Brad Hirayama:And I think people don't, don't realize that, you know, I've had my fair share of conversations with machinists where, you know, they want to give you feedback, and they want to say things like, Hey, can we open this tolerance? Or, you know, hey, this this wall. What's the purpose of this, of this wall here? Can we just get rid of it? And yes, it's going to make their life easier, and it'll make your part a little cheaper, or something like that. But they're really just, just there to help. So never, never hurt to ask Absolutely. All right, so let's move on. So this is going to be the last piece that we talk about today, when we're talking about speeding up the, sorry, accelerating the speed of engineering for teams. And, you know, really focusing here on workflows, and how do we make workflows flow better? And so the last piece here is to centralize access to data. And you know, talking about CAD you know, we're talking about your drawings, we're talking about your quotations. Your documents. But I'll expand this into things like lead times are so important, things like schedule timelines. If you can eliminate your engineers need to search and spend the time searching. They can focus their energy on on somewhere else, like building or designing, right or innovating what whatever it is. And, you know, there's a really simple example that I have for this. A lot of my work that I've been doing over the last few years uses a lot of outside vendors, where I'm quoting, getting prototypes and samples and trying to kind of piece together what is the next iteration of the device that I'm that I'm working on? I think one of the key things that I learned was I started to keep a very centralized repository for this vendor. We place the PO on this date. This is the lead time. This is the expected delivery date. And I would put just all of my vendor lead times onto its own Gantt chart, where, if I'm sitting in a meeting and somebody says, Oh, when are we going to get that? Pardon because that's going to feed into X, Y and Z activity. It's an instant answer. I have a little dashboard. It's, it's right there in front of me, versus, oh, I don't know. I need to go and look at my look at my emails. I'll get back to you later on today. You know, I spent 20 minutes looking through my emails and trying to find this, and I ended up having to call the guy because I can't find it, and I need to get whatever that lead time is, you know, now I just wasted an hour of time trying to find information that if I had just written it down from the start, it would have been just right there and right there in front of me. So, yeah, I think that this is something that I believe strongly, that you take the time to do little things like centralizing all of your information, you are going to see that these little things that you do really compound to accelerate your yourself and your development process.
Aaron Moncur:Yeah, and I'll add just a little bit of color to to centralizing access, also organizing that data. And this can be as simple as just having a standard set of folders that you use in your project directory. So when an engineer needs to open up the CAD, he or she knows exactly what folder to go to to open that CAD doesn't have to search through a dozen folders before fine again. I've got a non engineering example, but the principle applies nonetheless. So we've got, you know, all these different folders at pipeline or libraries. We've got our engineering, we've got our customers, we've got our marketing, we've got our sales, we've got finance, administrative, leadership, etc, etc. And initially, you know, long ago, the engineers did not have access to like, the marketing folder or the sales folder, because with that one, the engineers don't need access to those folders, so why overload them? Well, didn't take us long to realize that we're we had a quote that we needed an engineer to give their input on, or some marketing initiative that we wanted an engineer's help with, and, oh, shoot, I don't have access to that folder, and it just throws a wrench in the process. Right now we have to stop. Okay, well, who can grant you access to that, or I check in with it, and they'll give you access to that folder. And now it's like a day later, right? The conversation is stalled. So now everyone just has access to everything. I mean, obviously there's some sensitive data, like we don't publish people's paychecks or anything like that. But outside of sensitive information, everyone on the team has access to every folder, every library, and it just makes things so much easier to Yeah, progress is just much faster.
Brad Hirayama:Yeah, I wholeheartedly agree. You know, giving everybody access to the data that or kind of the ecosystem that they are operating in makes them understand the total picture. And I think that's the only way to get an entire team moving into that. Yeah, it's awesome. That's a That's a great story. Again, just another reason why pipeline decided a great company
Aaron Moncur:not just to work for, but to work with. I love it. I love it. Brad, you're the best.
Brad Hirayama:All right, we went through there's seven points. So let's go ahead and recap these, these seven points. So just a reminder, we're talking about accelerating the speed of engineering for teams, and we're focusing on how workflows are. To do the acceleration for you from idea to hardware to validation. So, number one, define requirements early and define how they will be verified to avoid unnecessary over engineering. Number two, fail early and inexpensively by getting to hardware fast and prototyping soon and often. Number three, hold regular design reviews before ordering parts, including senior engineers. Number four, use checklists to error proof human tendencies tendencies. Number five, test multiple options in parallel. Number six get manufacturing feedback early so designs that prototype easily don't become production nightmares. And finally, number seven centralize access to data so engineers spend time building not searching.
Aaron Moncur:Wonderful Brad. I'm super excited about this little series that we've put together. I think these are going to be three of the best podcast episodes that we have produced here, just in terms of, like, pure value. I mean, oftentimes the the general interviews that we do are great, right? And I always learned something, and I hope our audience always learns something. But like you mentioned at the beginning of this episode, we have distilled hundreds of interviews with senior level engineers down into these 21 points for how to accelerate the speed of engineering. And I just, I feel like this is so valuable, like there's just so much actionable information in these episodes. So this is number two of three. The next one coming up is, well, you guessed it, three of three, our last one, and we've got seven more points to share with you all that we have distilled over 300 plus interviews with talented, high performing engineers out there. So we will see you all next time for that third and final episode in this accelerate series, until next time, see everybody. 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 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.
